たとえ障害の根本原因であっても“変化”を起こせることが大事　DevOps実現のための6つの方法と4つの文化

DevとOpsの対立

川口恭伸氏（以下、川口）：2009年からDevOpsが出てきます。

DevOpsの話、これは源流の「10+ Deploys per Day」というものがあって、ビデオを見ながら私が書き起こしたので紹介したいんですけれど。2009年に何が起きたか、どんな話だったかです。

「10+ Deploys per Day」は、1日に10回デプロイするというタイトルです。これはたぶん彼らの中で使っていたクラウドの話だと思うんですが、効率的なデータセンターを使い、デベロッパーと運用者が協調しながらガンガン10回デプロイできるようにするみたいな。それでも品質が壊れないようにするみたいな話が出ていて。

その時に、「じゃあどうやってみなさんは協調するのか」という技術論や文化の話が非常におもしろくて、DevOpsに興味がない方もぜひこれは1回見てもらいたい。特に、AWSとかインフラとかに近いところをやられている方は、ぜひこれを読んでほしいです。

Flickrは今でもありますよね。写真共有の大手です。当時、ヤフーに買収されていました。

（社内の）人数がちょっと増えてきちゃったんですよ。人数が増えてきた会社の中で開発担当と運用担当が分かれていると、やはり対立関係になりがちだと。

なんでかというと、開発者が新しい機能を出すとサイトがこける（笑）。だから、運用者からすると（新機能は）出してくるなと。

福井厚氏（以下、福井）：（笑）。

川口：「なにしてくれんねん」みたいな話になるわけですよ。

そうすると、批判ばかりだから「運用の人がまた怒ってんな～」とビクビクしながらリリースするみたいな感じで。

伝統的に、DevとOpsの人はどっちもあまり仲が良くないというか、安定性をやるのがOpsで、安定性を壊しちゃうけどラディカルに新しいものをやるのがDevみたいな感じ。

でも「そうじゃないよね」と。実はOpsの仕事は非常に重要で。しかも、Devのほうがちょっとかっこいいみたいなのあるじゃないですか。新しいものを作るって。

福井：そうですね（笑）。

川口：Opsは保守派みたいな感じになってしまうんだけれど、Opsがまさにビジネスを可能にしていて、ここが収益の源泉なんだという定義をまず明らかにする。

だけど、ビジネスって変わらなきゃいけない。ビジネスである以上、変化が必要なわけですよ。

だけど、ほとんどの障害の根本原因はその変化なんですよね（笑）。

だから、ビジネスに必要な変化が障害を起こす。我々には選択肢がありますが、安定性を重視して変化をやめるか、それとも変化を起こせるようなツールや文化でなんとか変化できるように持っていくか。「どっちにしますか？」という問いが最初にくるんですね。もちろん後者なわけですよ。

変化を起こせる組織にするための6つ方法

川口：じゃあ後者でどんなツールを使っていくかというのがこのトークで。

ツールについて語っていきますが、6つあります。

1つは自動化されたインフラです。

2番目が共有したリビジョン管理。自動化インフラはもうみなさんやっているのでわかりやすいですね。共有したリビジョン管理は、みんなで見える化して、壊れたらみんなが直せるようにしましょう。どこが壊れているかわかるようにしようと。

それからビルドも自動化する。前は本番期に入って誰かがリリースしていた。今もやっている人はいるのかもしれませんが、とりあえず自動化しましょうという話です。

そうすると、小さく頻繁に変更をデプロイできるようになるので、ビジネスの変化に対応できますよねと。

そうしたらただリリースするのではなくて、フィーチャーフラグを使うことによって、ブランチを切る（という旧来の方法ではなく）。

旧来のソフトウェアではやっていましたが、Webアプリって結局、Webサーバーの観点でいくと一面しかないので。

トランクをデプロイしておいて、中でその分岐をできるようにしたらいい。

ソフトウェアで入ってからブランチしましょうと。バージョン管理システムでブランチするのではなくて、動くソフトウェアでブランチするというのがフィーチャーフラグです。一部をブロックしておいて、使えないものを分けるみたいなことがフィーチャーフラグという話ですね。

一部の方にプライベートβが渡せたり、バケットテストなど、徐々に利用者を増やしていくようなテストができます。これはAWSの方はみんなやっていると思いますがそんな話です。

表示をせず、裏側で動かしておいて、だめなら戻すようなこともできる。これを2009年に言っています。

それから「メトリクスを共有しましょう」ということで、「KPIをみんなに見えるようにしてしまって、ダッシュボードを作りましょう」みたいなことを言っています。

ソフトウェアの人ではなくて、経営の方も見えるようにするというのが最近の流れかなという感じはします。

それからみなさん大好き、IRC（Internet Relay Chat）、IMロボット。SlackやDiscordでやっていることかなと。

これは何がいいかというと、ログ、アラートが全部IRCに集まっているので、やっているログだけではなくて、アラートの追っかけもできるのでうまくやりましょうと。

>変化を起こせる組織にするために必要な文化

川口：ここから文化について（の話）です。

文化の1個目はリスペクトです。お互い人々はみんな違うので、ステレオタイプで捉えないで、専門性とかそれぞれ持っている責任感とか意見を尊重してやりましょうと。

先ほどのOpsの話で、「だめ、無理！」と言うのではなくて、建設的に議論をしましょう。

だから早めに言って、自分ができる専門知識はオープンにして、対話のきっかけにしましょうという話です。

2番目が信頼。

勝手にやっちまう前に相談しよう。当たり前の話ですが、そういうことですよね。いきなり本番（環境）を壊すなという話です。

作戦と、あとさらにエスカレーションプランで、不測の事態の作戦を一緒になって考えましょうという感じですね。

なので逆に言うとOps側、AWSとか使われている方は今はOpsの方がもしかしたらいないかもしれないが、ちゃんとroot権限をある程度見えるようにしましょうという話がされています。

で、失敗をすることももちろんある。

失敗は必ず起こります。

失敗が起こらないように考える時間と、失敗が起きた時の回復策を考える時間、人間の時間なんて同じなんですよ。

だから、間違いをしないように考える時間をガッと取ってしまうと、起きちゃった時の回復策を考える時間が削られていくことになるんですね。時間は同じだから。

だから、あなたしかいない時に問題が起きたらどう対応するかの回復策を、みんなで訓練しましょうという話。

最後、非難を避けましょうと。

役割分担をはっきり決めてしまうと問題の解決を遅らせてしまうので、「いや、見つけたら自分で直そうよ」と。ソースコードは共有されているし、メトリクスも共有されているので、今はあなたしかそこにいないんだと。夜中に叩き起こして誰かに「やってくれ」じゃなくて、「今あなたしかいないとしたらどうしますか」ということをちゃんとやる。

その担当が夜中に起こされないように、自分事としてどうやってうまくやっていくかを（意識）することがすごく大事だという話です。

まあ、言ってみたら簡単なことではないと言って、最後は終わる。

これがDevOpsの源流の話です。話はここまでですが、非常に刺さるじゃないですか。2009年にこれ（らの話）が出ていて、この後やっとDevOpsの話が出てくるんですよ。これはヤバいですよね。

福井：ヤバい（笑）。

川口：話としては以上です。

福井：ありがとうございます。

川口：（スライドを示して）もう1回だけ最後に。歴史はこんなんでした。“先アジャイル期”と“アジャイル期”。2009年から“DevOps期”と。こんな動きがありました。（この先が）どうなるかはわかりません。

（次回につづく）