DevOps～Webサービスの開発と運用の一体化という再パッケージングの概念

DevOpsという言葉を最近よく聞く。
DevOpsとは、Webサービスにおける開発と運用の一体化という意味で理解している。
感想をラフなメモ書き。

【元ネタ】
開発と運用の新しい関係、「DevOps」とは何か？ － Publickey

DevOpsを実践する企業に共通すること。DevOps Day Tokyo 2012 － Publickey

DevOpsによるビジネスの改善をメトリクスとして計測する方法。DevOps Day Tokyo 2012 － Publickey

[資料公開]Chefの下準備 (#DevLove Chef de DevOps) | Ryuzee.com

リーン・スタートアップが生む価値――「Just do it！」の無駄を省く

リーン・スタートアップが示す「5つの原則」

リーン・スタートアップの実践――ソニックガーデンは2度ピボットした

about DevOps… ≪ すでにそこにある雲

サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 － Publickey

Twitter / akipii: 「カバレッジは収穫逓減モデル」。メトリクスも同じ。ソフトウェアメトリクスは役立つがそれ以上ではないという指摘。右手に感情、左手に数値 - カバレッジを味方にしよう - t-wadaの日記 http://d.hatena.ne.jp/t-wada/2011120 …

Twitter / akipii: 開発＝Developmentと、運用＝Operationを組み合わせた言葉。開発と運用の新しい関係、「DevOps」とは何か？ － Publickey http://www.publickey1.jp/blog/11/devops …

Twitter / daipresents: システムの計測として「Ticket system」というのが面白い StoryはPivotalで生産性として計測してTicketはムダの数って感じかな / “DevOpsによるビジネスの改善をメトリクスとして計測する方法。DevOps…” http://htn.to/ydZBxw

Twitter / akipii: クラウドとはアジャイルインフラストラクチャの考え方から来た。DevOpsとはどんなもので、何が議論されているのか（後編） － Publickey http://www.publickey1.jp/blog/12/devops …

Twitter / akipii: Metrics Driven Developmentという考え方。チケット駆動開発もメトリクス収集ツールを基盤とするから適用できるはず。クラウドの登場でDevOpsは変わっていく、メトリクス主導へ － Publickey http://www.publickey1.jp/blog/12/devops …

システムの開発と運用の一体化という考え方は、業務システムの開発でも同様だ。
特にSIならば、苦労して新規開発した後、運用で定期的に保守料という形で現金を受け取り、売上を確保するビジネスが多いだろう。
では、従来のソフトウェア保守とDevOpsでは何が違うのか？

上記のpublickeyの記事を読むと、特にWebサービスの分野で、アジャイル開発やリーンソフトウェア開発、リーンスタートアップの概念を取り入れて、Webシステムを小刻みに開発しながら即運用していくビジネスモデルをサポートしているようだ。
DevOpsとは、Webサービスの開発と運用の一体化のアイデアであり、従来のソフトウェア保守の再パッケージングの概念とも言える。

僕が注目する内容は二つある。
一つは、信頼性の要件のうち、MTTR(障害修復時間)を重視すること。

DevOpsを実践する企業に共通すること。DevOps Day Tokyo 2012 － Publickeyには下記が書かれている。

(引用開始)
運用については、MTTR（Mean Time to Repair）つまりどれだけ早く復旧できるかが大事になっている。壊れることを予期しておくことが大事だ。
(引用終了)

つまり、HDDやネットワーク機器などは定期的に壊れることを前提として、復旧時間を短くできるように運用体制を整えておくこと。
また、ソフトウェアの障害修正や機能追加を定期的にアップデートできるような仕組みを取り入れておくことで、頻繁なVerUpができるアーキテクチャに設計しておくこと。
すなわち、壊れないシステムを作る発想よりも、素早く修復できるシステムの方が価値があるという考え方へ根本的に変わっている事実がある。

アジャイル開発のアイデアを製品開発、Webサービスへ発展させる: プログラマの思索

障害を故意に起こさせるツールで耐障害性を高める: プログラマの思索

アジャイル開発が問題点をすり替えた品質特性～機能性と信頼性: プログラマの思索

特に最近は例えば、iPhoneや携帯のソフトウェアアップデート機能のように、ソフトウェアのアップデートだけでなく、OSそのもののアップデートも可能になったため、MTTRを短くするという考え方を実現しやすくなった状況がある。
また、たとえ壊れたとしても、信号機が壊れた時に必ず赤信号に倒すという例のフェイルセーフ、子供が誤ってシステムを誤動作させても怪我をさせないという例のフールプルーフ(チャイルドプループ)、システムを冗長化して稼働率を維持するという例のフォールトトレランスなどのような耐障害性を持つアーキテクチャ設計が重要になってきている。

現代は、ハードウェアは所詮は箱物であり、その中にあるソフトウェアやデータに価値があるのだ。
だからこそ、壊れないハードウェアを作るよりも、定期的に進化し続けるソフトウェアの方が重要になってきている。

もう一つは、DevOpsを支えるためのツールが揃ってくると、メトリクスが重要になってくるという話。
ここでは、従来のソフトウェアメトリクスではなく、リーンソフトウェア開発やリーン生産のアイデアを用いて、サイクルタイムやフィードバック時間、デリバリ効率などのメトリクスを収集して、開発チームにフィードバックし、運用を改善していくことを目指している。

DevOpsによるビジネスの改善をメトリクスとして計測する方法。DevOps Day Tokyo 2012 － Publickeyの記事を読むと、リーン生産のアイデアを用いるだけでなく、メトリクスに上限と下限を用いる管理図も使っているようなので、色々アレンジしているように見える。
そして、ここからMetrics Driven Developmentのような考え方が出てくる。
つまり、改善のヒントになるようなメトリクスを収集していくことによって、ノウハウを蓄積し、継続的イノベーションが行えるような環境を整えていくこと。

多分、チケット駆動開発もこの流れの上で運用することも可能だろう。
例えば、運用中に発生した障害やインシデント、問合せを全てチケットに記録して定期的に集計することで、直近の傾向やリスクを分析でき、そこから運用を改善していくこともできるだろう。

DevOpsについても色々探してみる。