大石蔵人之助の雲をつかむような話

株式会社サーバーワークス 代表取締役社長 大石良

DevOps vs ダムOps

記事タイトルとURLをコピーする

こんにちは、大石です。

先週、翔泳社主催のソフトウェア開発者向けカンファレンス「Developers Summit 2013 Summer」(夏サミ2013)で「DevOpsって本当のところどうなのよ?」と題したセッションのモデレータを仰せつかり、はてなでCTO、GREEソーシャルメディア統括を歴任された伊藤直也さん、Sansan株式会社でEightの開発指揮を執られている宍倉功一さんと3人でパネルディスカッションを行いました。

パネルはバーチャルバトル仕立てで、「DevOpsをやりたいと思っている開発者が、どうやってBiz側(いわゆるスーツ)をどうやって説得するのか」そして「スーツを纏った人々がどういう懸念を示し、それに対してどうやって説得・対抗していくのか」というテーマに対して、問答の中から自分たちで使えるヒントを得て頂こうというものです。

 

 

詳しい内容は上のスライドをご覧頂くとして、私が特に印象に残ったのが以下の2点でした。

(1)DevOpsは開発者をいつまでもプロジェクトに貼り付けるという話では無く、開発・運用担当者の頭にしかなかった暗黙知をコード化し、属人性を排除する取り組み

(2)DevOpsが実行できる組織をつくることはマネジメントの責任

(1)について私が「Gmailの話」を引き合いに出して「DevとOpsがシームレスになっていくと、エンジニアがプロジェクトにへばりつきになって属人性リスクが高くなるのでは無いか?」という問いを発したのですが、伊藤直也さん曰く「DevOpsで運用がコード化できれば、だれがやっても同じサーバーの状態をつくることができ属人性は減る」とのこと。

確かに、私たちもプロジェクトでよく

「このサーバーはどういう状態になっているのかよく分かりません」

という話をよく耳にします。

これがChefのrecipeとかで「誰がやってもこの状態になる」ことが担保されていれば、別な環境で再現もできるしテストもやりやすい。わざわざツーマンオペレーションなどをやらなくても、コードレビューや(ユニット)テストといった、プログラミングの世界では当たり前になっているメソッドを使ってインフラ運用の品質を高めていくことができるわけです。

この話には続きがあって、翌日伊藤直也さんがJAWS-UGでDevOpsの話をされていたのですが、serverspecを使って「サーバーのあるべき状態をJenkinsで継続的にインテグレーションする」といったアイディアを披露されていました。

(当社はそんなことはしませんが!)現場で運用をされている方が、なんかの都合でsshd_configをいじって、一時的に

PasswordAuthentication yes

なんてやってしまうことは、あってもおかしくないと思うのです。
で、ちゃんと元に戻しておけばいいのですが、忘れたままターミナルを閉じてしまったら、もう侵入されるまで知りようが無くなってしまいます。

こんな時でも、serverspecでsshdのあるべき姿(この場合はパスワード認証がnoになっていること)を継続的にチェックしたり、ftpdが間違って立ち上がったりしていないかを確かめたりといった「サーバーのあるべき姿を継続的かつ自動的に確認する」という点で、実効性の高いすばらしいアイディアだと思いました。

 

もう一点、「DevOpsを実現する組織はマネジメントの責任」

のところは、仰る通りなんだろうと思います。

見聞きするプロジェクトでは

「運用でカバー」

という言葉がさも魔法の呪文の様に唱えられていますが、実際には「運用までの工程で漏れた仕様や要件を、人手でむりやり実現する」のが実態で、むしろ運用の現場で起きていることが設計・開発といった上流にフィードバックされていない悪しき現状を表現していると思います。

設計のミスが開発に、設計と開発のミスが運用に流れ、でもダムの決壊は沢山のヒトが必至でせき止める。流れは水のように上から下に向いており、決して上に戻ることは無い。そんな修羅場が目に浮かぶようです。これを水の流れにたとえて「ダムOps」と勝手に呼んでみました。

DamOps

悲惨ですね・・・。

Sansanの宍倉さんも、DevOpsをうまく回すために「設計段階から運用メンバーも参加させる」と仰っていましたが、ダムの様に一方通行では無く、ちゃんと運用から設計・開発へフィードバックを生み出せる組織と文化が必要で、それらはマネジメントの責任だということを(マネジメントに携わる一人として)痛感しました。

 

「じゃあどこからやるのか?」

という問いに対して、お二人とも「まずできるところから」という点で一致していました。

私たちのビジネスであればserverspecなどが始めやすそうです。開発チームは日常的にCloudFormation, Capistrano, Jenkinsといったツールを駆使しているので、インフラチームへのノウハウ伝播も難しくなさそうです。
プログラミングの世界で培われてきたメソッドが、運用やインフラエンジニアの仕事もガラッと変えてしまう未来をつまみ食いすることができ、私も参加者の一人としてとても勉強になった1時間でした。

伊藤直也さん、宍倉功一さん、ありがとうございました!