開発と運用の新しい関係、「DevOps」とは何か？

このところ海外のIT系の記事で「DevOps」という言葉を見る機会が増えてきました。スペルからすると、開発＝Developmentと、運用＝Operationを組み合わせた言葉らしい、という程度の認識でしたが、どうやらアジャイル開発やソフトウェアの品質にかかわる新たなムーブメントとして認識しなければならないかも、と感じはじめています。

そこで「DevOps」とは何か？ について調べてみました。

DevOpsとは開発と運用が協力し、ビジネスリスクを軽減する

まずはWikipediaの「DevOps」の項目から冒頭の部分を読んでみましょう（2011年3月8日現在の記述）。

DevOps is a set of processes, methods and systems for communication, collaboration and integration between departments for Development (Applications/Software Engineering), Technology Operations and Quality Assurance (QA). It relates to the emerging understanding of the interdependence of development and operations in meeting a business' goal to producing timely software products and services.

DevOpsとは、開発部門、運用部門、品質管理部門のあいだの、統合、コミュニケーション、コラボレーションを行うための一連のメソッドとシステムである。これはまた、適切なソフトウェアとサービスによってビジネスゴールを実現するためのミーティングにおいて、開発と運用の相互依存として理解されつつある。

説明が少し固いですが、開発、運用、品質管理の新たな相互依存関係なんだな、ということが分かります。そして、新たな開発方法論であると続いています。

It is an important topic where new development methodologies (such as agile software development) occur in a traditional organization with separate departments for Dev, IT Operations and QA.

これは新たな開発方法論（アジャイル開発のような）として重要である。特に開発部門、運用部門、品質管理部門が分かれているような伝統的な組織において。

Publickeyではアジャイル開発や開発における品質の作り込みなど、ソフトウェア開発における新たなムーブメントを大事なトピックとして追い続けていますが、「DevOps」もその1つであると。

しかしなぜ開発と運用を一体化しなければならないのでしょうか？ Wikipediaにはこれを説明する優れた図もあります。たまにしか新たなリリースをしない場合にはそのたびにいっぺんに大きな変更がシステムに生じるため変更のリスクが大きくなるのに対し、頻繁に小さなリリースを繰り返す方が変更の度合いが小さく、リスクが少なくなる、という理由です。

こうした頻繁なリリースのために開発部門と運用部門が協力していかなくてはならない、というのがDevOpsの根底に流れる考え方のようです。

DevOpsの実現には「ツール」と「文化」が重要

さて、DevOpsについて調べていくと、DevOpsの原点と言われているスライドにたどり着きました。2009年に行われた「Velocity 2009」というイベントでFlickrのスタッフが行ったプレゼンテーション「10 deploys per day : Dev&Ops cooperation at Flickr」です。スライドのポイントを見ていきましょう。

伝統的な組織では、開発部門と運用部門は対立しています。

開発部門は新しい機能を追加していきたいのですが、運用部門は安定したシステムに手を加えたくないためです。両部門の利害が対立しているわけです。

しかし運用も目的はシステムの安定稼働ではなく、ビジネスの実現ではないか。

そしてビジネスを進めて行くには変化が必要である（だから開発部門は新機能を作り続けている）。

しかし変化・変更はシステムダウンの原因でもある。どうすればよいか？ 変化・変更によるリスクを、ツールと社内文化によって低くすればよいのだ。

そのためには開発部門と運用部門は愛し合わなければならない。

スライドはさらに、Flickrがいかにして1日に10回も新しい機能をリリースしているのか、そのツールや企業文化を紹介しています。全部で78枚もある長いスライドですが、ぜひ見ていただきたいスライドです（この記事末に埋め込んであります）。

スライドでは「こうしたツールと企業文化の実現は簡単ではない」としつつ、その実現に必要なツールと文化の要素を次のように紹介しています。

自動化されたインフラとバージョン管理、ビルドツールといったツール群、そしてお互いを尊敬し、信頼しあう文化が大事であると。

クラウドによってNoOps＝運用部門は不要になるのか？

DevOpsについては、すでに日本語のブログでもいくつか情報を見いだすことができます。さきほどのFlickrのスライドを教えてくれたのは、ブログすでにそこにある雲のエントリ「DevOps」です。DevOpsに関する資料へのリンクが豊富で参考になります。ちなみにこのエントリによると、Flickrのプレゼンテーションを行った2人はもう辞めてしまっているのだとか。

ZDNet Japanの記事「クラウドと「DevOps」を理解する」もDevOpsとインフラ管理の関連について読むことができます。

そのクラウドと開発・運用の関係について興味深い考察を書いたのが、米調査会社Forrester ResearchのアナリストMike Gualtieri氏によるエントリ「I Don't Want DevOps. I Want NoOps.」。彼はクラウドを想定すればDevOpsどころか運用部門そのものがいらない（NoOps）と言っています。その主張を見ていきましょう。

The goal of DevOps to make the process of deploying applications faster and smoother. DevOps is a loosely defined set of emerging practices to get developers and operations pros to work together.

DevOpsの目的は、アプリケーションのデプロイを迅速かつスムーズに行うプロセスの実現だ。DevOpsは開発部門と運用部門の協力を実現するために登場しつつあるゆるやかなプラクティスの組み合わせである。

DevOpsとはどういうものか、認識はこの記事で紹介してきたものと一致しています。しかし、開発者と運用者が協力し共にお互いのことを考えるというDevOpsは、開発者にとって後退ではないか？ というのです。

developers should look to spend more of their time getting closer to the business, not getting closer to the hardware. I fully acknowledge that there is a need for quicker and less-rickety deployment processes. But, I think DevOps is a step backward. Instead I propose NoOps.

開発者はよりビジネスについて注力するべきで、ハードウェアのことについて時間をかけるべきではない。私は迅速でガタのないデプロイメントプロセスの必要性については認めるが、DevOpsとは、私が提案するNoOpsと比べると後退ではないかと思う。

さて、NoOpsとは何でしょうか？ NoOpsもDevOps同様に優れたデプロイメントプロセスの追求であるとしたうえで、彼は次のように説明しています。

But, NoOps means that application developers will never have to speak with an operations professional again. NoOps will achieve this nirvana, by using cloud infrastructure-as-a-service and platform-as-a-service to get the resources they need when they need them.

NoOpsとは、デベロッパーは運用部門とまったく口をきく必要はないのだ。NoOpsとは、IaaSとPaaSによっていつでも必要なリソースを必要なときに獲得できるという楽園の実現である。

どうでしょうか。IaaSとPaaSによってデプロイメントプロセスが開発者にとって理想化される、というのは少し楽観的すぎると思います。さまざまなアプリケーションごとにデプロイメントプロセスは全く異なるため、それほど単純化できないと考えるからです。

例えば、セールスフォース・ドットコムのForce.comはNoOpsに近いといえます。しかしそれが成立するのは、開発言語やデータベースの機能があらかじめ決められており、利用できるメモリやデータベースなどのリソースも「ガバナ制限」という形で範囲が設けられているという制約があるために成立しているはずです。

開発と運用を統合して実現する柔軟性の代わりに、ある程度の制約があるからこそ自動化を実現できていると見るべきと考えます。もちろん、この制限のなかでもかなりの柔軟性があり、工夫によって多くのビジネスアプリケーションが実現できていることも事実。

ビジネスからの要求を可能な限り実現するという柔軟性のためにはDevOpsを、ある程度の制限があってもいいから運用をアウトソースしたい、という場合にはIaaS/PaaSでNoOpsを、ということになるはずです（IaaSではNoOpsというわけにはいかないように思いますが）。

自社にとって運用の重要性はどれくらいか、というのは当然ながら企業ごとに事情が大きく異なるでしょう。それをDevOpsのように考えて自社の強味にするのか、それともNoOpsのように考えて、制限があってもいいからアウトソースしてしまったほうがいいのか、サービスが重要になってきたクラウド時代だからこそ考えなければならないテーマです。

関連記事

開発と運用の連係については、以下の記事でTwitterやFacebookの例を詳しく紹介しています。あわせてお読みください。

• Twitterの大規模システム運用技術、あるいはクジラの腹の中（前編）～ログの科学的な分析と、Twitterの「ダークモード」
• Twitterの大規模システム運用技術、あるいはクジラの腹の中（後編）～Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」
• Facebook、memcachedに300TB以上のライブデータを置く大規模運用の内側