いまさら聞けない「DevOps」：特集 DevOps時代の必須知識（1/2 ページ）

最近さまざまなイベントやブログエントリで見かける「DevOps」。この言葉をひもとき、なぜ「Dev」と「Ops」が衝突するのか、その解決に必要な要素とは何かを分かりやすく解説します。

[千葉則行（エクシード），＠IT]

DevOpsとは

　2009年にオライリーが開催した「Velocity 2009」というイベントにおいて、Flickrのエンジニアが、“開発と運用が協力することで、1日に10回以上のペースでリリースが可能になること”を紹介しました。いまさまざまなシーンで見かける「DevOps」という言葉は、このプレゼンの中で登場したものです。

　DevOpsとは、開発（Development）と運用（Operations）が協力し、ビジネス要求に対して、より柔軟に、スピーディに対応できるシステムを作り上げるためのプラクティスです。多くの人々により議論は続けられていますが、ITILとは異なり、現時点においては、DevOpsに厳密な定義はありません。

　DevOpsの関心事は、それぞれの役割の違いから衝突することが多い開発と運用の双方が協力し、同じゴールに向かう環境を作ることであり、そのような環境を作るためにはツールとカルチャーが重要だと考えます。「DevOps」と聞くとOpscodeの「Chef」やPuppet labの「Puppet」などのツールを思い浮かべるかもしれませんが、実は、これらツールはDevOpsの一部分ということになります。

　本稿ではDevとOpsの衝突を例にして、どこに問題があるのか、そしてDevOpsには何が必要なのかを考えていきます。また、理解を深めるためにDevOpsの周辺についても併せてまとめていきます。

DevとOpsの衝突

　それでは、DevとOpsが衝突する理由から見ていきましょう。

役割の違い、ミッションの相違

　DevとOpsの衝突は、主にそのミッションの違いに起因しています。

　開発者のミッションは「より良いものを作ること」です。通常は時間的な制約があり、最初から完璧なものを作ることはできません。また、取り巻くビジネス環境の変化もあるため、必然的に変更・修正・追加を継続的に続けていく必要があります。

　一方、運用者のミッションは「安定的にシステムを稼働させること」です。運用の世界に「患者には触らない」という言葉がありますが、安定的に動いているシステムは変更・修正・追加を加えなければ問題なく動き続けるため、基本的に運用者はシステムに手を入れることを嫌います。

DevとOpsが衝突する例

　両者の衝突は、システムに対し、何らかの操作が必要になる場面で発生します。

　通常、不慮の操作によるシステム障害を避けるため、開発者にはシステムを触る権限を与えられていません。この制限のため、たとえ不具合を調査するためであっても、開発者は運用者に対して、アプリケーションのログの取得を依頼しなければなりません。

　一方、多くの場合運用部門は、少人数で複数のシステムを一括して受け持っています。開発者からすると運用部門は1つですが、運用部門からすると開発者は複数である、ということです。このため運用部門は、定常的な運用保守業務に加え、常に多くの開発者からの同様な依頼に追われており、依頼にタイムリーに対応することができません。

図1　DevとOpsの衝突

　そして、開発者は「ログさえも満足に見ることができない」と罵り、運用者は「もっと時間に余裕をもって依頼してほしい」と怒ります。このような状況下では、リリースの頻度を増やすことは、DevとOpsが衝突する頻度を増加させることになるため、とても現実的ではありません。

DevOpsに必要なこと

　このDevとOpsの衝突を解消するには、測定、共有、自動化、コラボレーション、そしてカルチャーが必要です。DevとOpsの衝突の原因について考察しながら、この5つが必要である理由を説明します。

図2　DevOpsに必要なこと

測定、共有、自動化

　この衝突は、開発者はシステムの操作について全く自由がないこと、運用者は細かく大量な依頼をタイムリーに処理する余裕がないことに由来しています。開発者からの依頼内容の大半は、ログの取得などの比較的定型的で容易な作業です（それがゆえに、開発者の不満がより募るのです）。問題はそれが大量にあるため、さばくには運用者の人手が足りないということなのです。

　「どんな簡易な作業であっても常に人の手を介す必要がある」ことが問題であれば、解決方法は、人手を増やすか、もしくは手作業を減らすことになります。コスト面を考えると、実際は後者を選ぶことになるでしょう。

　開発者からの要求は、システムに関する情報の提供、ミドルウェアの設定などに関するものが多いと思います。これらの要求を人を介さずに行うには、システムに関する情報を「測定」し、それをポータルなどにより「共有」する仕組みと、ミドルウェアの設定などに関してはChefやPuppetなどを用い設定・管理を「自動化」することが必要となります。

コラボレーションとカルチャー

　しかし、「測定」「共有」「自動化」だけでは、まだDevとOpsは分かれたままです。DevとOpsのコミュニケーションを潤滑にし、抜けやモレを減らすために、「コラボレーション」の仕組みが必要です。この仕組みにはBTS（バグ・トラッキング・システム）やIRCなどがよく利用されているようです。

　このコラボレーションの仕組みは、作業を確実にこなしていくという点においては、必要な取り組みではありますが、どんなシステムやツールであっても、人と人の間の根本的な問題解決については無力です（もし、この問題を解決できるツールがあるのであれば、あなたが感じているストレスの大半は既に存在しないはずです）。

　企業には、目指すゴールがあります。しかし、そのゴールを支えるシステムは、過去のそれとは異なり、非常に複雑かつ巨大です。とても1人で全てを把握し、コントロールできるものではありません。そのため、そのゴールに向かうには、それぞれの人が、それぞれの専門性（スペシャリティ）を持ち寄り、協力するという「カルチャー」が欠かせません。

　「測定」「共有」「自動化」「コラボレーション」「カルチャー」。DevOpsは、テクニカルなことだけでなく、組織やカルチャーをも包含する、大きなものなのです。