本番環境の「聖域化」を再考する - DevOps の「リードタイムの短縮」の次に来るもの
DevOps という言葉は2009年のVelocity conference でFlickerが発表した 10 deploys per day という発表が起源になっています。
www.slideshare.net
残念ながらアジャイル開発宣言のような公式の定義がないため、多くの人がその定義をしようと頑張っています。私はその起源や、インターネットでいろんな人が定義している内容を総括して次のように「DevOps のエレベータピッチとは」という問いに答えてきました。
ビジネス・Dev・Ops が協力し、ソフトウェアのライフサイクルと価値の創出を改善する活動
これはこれで特に悪くないとは思うのですが、正直若干「ふわっ」としているのは否めません、また、私が個人的に、Microsoft で一番の DevOps チームと呼ばれる Visual Studio Team Services のチームの事例を研究していく中で、「現在形」の DevOps の形について考えがまとまってきたのでシェアしたいと思います。
リードタイムと10 deploys per day
DevOps の定義を掘り下げる前に、メリットについて考えてみましょう。DevOps のメリットとその本質として最初に言及されるのが、「リードタイムの短縮」です。DevOps の起源のプレゼンテーションにもあったとおり、「１日１０回以上も本番に安全にデプロイできるほどの、自動化と仕組み作りをできるようにする」ということはイメージとしてわかりやすいかもしれません。
注：10 deploys per day に対する私の意見とディスカッションはこちら*1
実際には改善活動なので、いままでアイデアを思いついてから、それを本番にリリースできるまでの時間が「６ヶ月」「３ヶ月」だったのが、冗談抜きで「３時間」とかになったりします。
私も「1日に10回以上デプロイ」は「起源」で使われていますし、大変わかりやすいものなのでDevOpsの「エレベータピッチ」的に使っています。実際は１０回以上リリースできても、「価値」が伴っていないければ意味がないのですが、わかりやすさのためそれをつかうことが多いです。
私にとってこの基準はとてもしっくりきていたのですが、先で述べたVisual Studio Team Services のチームのDevOps 実践の事例を見ていくと、実際には、「リードタイムの改善」に関して言及しており、リリースサイクルの短縮は語られていますが、本当に小さな扱いです。なんでだろうと思っていたのですが、その理由はこのチームは「リードタイムの短縮」の先に進んでいるからそっちの方が素晴らしい成果だからということが言えます。実際に強調されているのは、「本番からのフィードバック」「フィーチャーチーム」そして、「仮説駆動のバックログ」「アラートルーティング」「テレメトリ」などです。
リードタイムの次に来るもの - Gene Kim の 3way
私が考えるまでもなく、既に有名な概念があります。 DevOps の世界で著名な Gene Kim 氏がまとめた「DevOps の 3 ways」です。3 ways は私の別のブログで言及をしていますので、詳細はそちらをごらんください。私は最近はGene Kim 氏の 3 waysで DevOps を考えるのが非常にしっくりきています。
上記の図のようにDevOps の達成するゴールを３つの段階に分けています。
1 way: リードタイムの短縮
2 way: 本番環境やユーザからの学び
3 way: 継続的な実験と検証
それぞれについてご説明したいと思います。
1 way: リードタイムの短縮
これはリードタイムの短縮です。これは 10 deploys per day などのキャッチフレーズの背景にあるリードタイムを自動化や組織変更、フィーチャーチームを構成して、短くしていこうというのが最初のゴールです。これは、アイデアを思いついてから本番にデプロイするまでを高速化することにあります。
これのために使われる DevOps プラクティスの例は次のようなものです。
自動テスト
継続的インテグレーション
継続的デプロイ
Infrastructure as Code
リリースマネジメント
ロードテストと自動スケーリング
フィーチャスイッチ
フィーチャーチーム / Kanban
ChatOps
:
注; DevOpsプラクティスの参考 DevOps Practices | IT Pro Guy & Tesar.info
まずはここを目指すだけでも相当ビジネス的にインパクトがあります。
この辺りは、アジャイルや、Continuous Delivery、アジャイルテスティングの考えを元に、クラウド・インフラ自動化技術、Web Operation あたりのアイデアが元になっていると思われます。
2 way: 本番環境やユーザからの学び
1 way が達成できたら、次の段階に進みましょう。
2つめは本番にデプロイした後に、そこから如何に学んでいくかという、本番から次のバックログへのフィードバックループを指します。本番からの学びを如何に効率良く行っていくかという視点です。
この目的のために使われるプラクティスは
アプリケーションパフォーマンスの監視
可用性監視
自動回復（ロールバックとロールフォワード）
これも、Web Operationやインフラの自動化技術、クラウドの自動化技術の影響を受けていますがこのような技術で本番環境からの学びを高速に反映することができるようになります。
3 way: 継続的な実験と学び
DevOps の最終形態です。 今までは本番環境は「聖域」と考えて、失敗しないように準備や計画をしまくって慎重にデプロイするものでした。ところが今は「本番環境」は聖域ではなく、「仮説を検証する場所」という考え方に変わってきています。結局のところ、デプロイしてみないと、全て卓上の空論です。実際に本番にデプロイして、要求的にもアーキテクチャ的にも学びを得て、早く失敗して、早く方向修正して、資金が尽きる前に自分のビジネス的に「正しい方向性」を見出していく実験をします。 このサイクルを如何に高速に回して、「正しい方向性」を見つけていくか？のゲームです。
ここで使われるプラクティスは
仮説に基づく開発
・運用環境でのテスト
・フォールトインジェクション
・使用状況監視 / ユーザテレメトリ
・仮説駆動のバックログ
：
このあたりは、リーンスタートアップのムーヴメントに非常に影響を受けていると思います。リーン系の考えを学んだことがある人は、この辺りはスッキリ受け入れられるかもしれません。 ただ、今の DevOps ムーヴメントがリーンスタートアップの盛り上がっていた頃と違うことは、エンタープライズ系企業でもこれらの「実験」の考えを採用して、高度な自動化、コラボレーションを実現できるようになってきたことです。
たんにリリースサイクルの短縮だけを考えると見えてこない、DevOps の次の一歩がようやく見えてきました。こういった実践が日本でもガンガンに増えてくるのを少しでもお手伝いしたいなと思っています。
参考
この記事と一緒に、Visual Studio Team Services のDevOps Journey の記事を読まれるとより一層よくわかるかもしれません。
