「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（後編）。Regional SCRUM GATHERING Tokyo 2016

2016年1月20日

アジャイル開発手法の1つであるスクラムをテーマにしたイベント「Regional SCRUM GATHERING Tokyo 2016」が1月19日と20日の2日間、都内で開催されました。

そこでマイクロソフトが行ったセッション「マイクロソフトが実践したScrum導入7年間の旅。そしてDevOpsへの進化」は、アジャイル開発からクラウドサービスの提供へと進んだマイクロソフトが、サービス開発の過程で学んださまざまな知見を共有するものとなりました。

（本記事は「「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016」の続きです）

バックログはあくまで仮説である

次は「学びにより整理整頓されたバックログ」です。

第一世代のアジャイル開発と第二世代のアジャイル開発（これがDevOps）の違いは、仮説駆動のバックログだと言われています。

これまでバックログはプロダクトオーナーが決めていました。しかし第二世代のアジャイルでは、このバックログはあくまで仮説であり、それが合っているかどうかは分からないと考えるものになっています。

すべてのバックログは仮説であり、仮説を検証するために実装し、本番にデプロイしてみて検証データをとって、間違っていたら別の考え方にすると。

「Visual Studio Team Services」の例でいうと、この製品はプロジェクト管理のための製品なので、ユーザーはアカウントを作ったあとでプロジェクトを作るはずです。

ところがデータをとってみると、ログインのあとでプロジェクトを作らない人がすごく多かった。おかしいなと。

そこで、最初の画面のアクションが多すぎるので、ユーザーが次のステップに進めていないのではないかと仮説を立てました。

それによってアクションを少なくしていったりしました。

それを検証してみたところ、最初の画面だけでなく、開発画面からもプロジェクトを作れるようにしたら、プロジェクト作成が3％から20％に改善しました。7倍です。

こんな感じで仮説を立てて本番にデプロイし、データをとって学んで方向修正していく。本番環境から学びを得るのはすごく重要ですねという話です。

アクション可能なアラートだけを通知する

次は「プロダクションファーストマインドセット」

「ライブサイト」とは、いま運用中のサイトです。いま運用中のサイトの文化はどうあるべきか。

まず、ライブサイトのステータスはつねに最優先。それはそうですね。落ちていたらどうにもなりません。

次はマイクロソフトの原則なのですが、グローバルレスポンスチームというのがあって、ライブサイトに問題があるとレスポンスしてくれるチームが5つくらいのタイムゾーンに分散してあって、24時間つねにすばやく対応できるようになっています。

面白いのは「コミュニケーションの自動化」です。障害が起こると、テンプレートがあって自動的にブログやツイッターにポストできるようになっています。

お客さんにインシデントを早く通知できるだけでなく、チームにとっても次に何をするのか、どうしなくちゃいけないのかがそこに書かれているので分かると。

インシデントの早期検出は、的確で性格で注意深いアラートが大事。お粗末なアラートがDevOpsを不幸にすると。

例えば、なにか障害が起きたときに、閾値だけでアラートが発生すると、影響が及ぶはんいのこっちのアラートもあっちのアラートも発生してノイズになり、訳が分からなくなってしまう。

そこでマイクロソフトはどうしたかというと、アクション可能なアラートだけを通知するようにした。

それからもう1つは、ヘルスモデルに基づいて根本原因の分析を自動で行うようにしました。

これはマイクロソフト内部で動いているシステムなので僕も見たことはないのですが、障害のアラートがアクション可能なものだけに絞られます。さらにそこから原因を解析して、関係のある人だけにアラートが飛ぶようになっています。

例えば、メモリとパフォーマンに3つのエラーが発見されて、原因が同じコードベースだと判断されると、そのコードベースに関係のあるチームにアラートが飛ぶと。

これによってアラームノイズが週あたり928から22へ減少し、グローバルレスポンスチームへのエスカレーションも56％減ったという効果がありました。

これによって頻繁にデプロイできるようになりましたと。

インフラを柔軟なリソースとして扱う

ここで面白いのはフューチャーフラグとカナリアテストですね。

デプロイしてなにか起きたときのためにロールバックできるようにするのは重要ですが、グローバルな規模でのデプロイはロールバックするのが大変。そこでフューチャフラグがあります。

これは、機能がアプリの中に組み込まれていて、なにかのフラグをオンにするとユーザーに公開される、というもの。

Azureや今回のソフトウェアではユーザー単位でフューチャーフラグが操作できるようになっています。だから僕が「あの機能使わせてよ」とリクエストすると、僕の環境で使えるようになる。

こうすることで、再デプロイすることなく機能をオンオフできる。

カナリアテストは、いきなり全部の地域でデプロイするのではなく、1つの地域だけでデプロイしてみて、そのあとグローバルにデプロイするやり方。最新のツールだと、こういうことも簡単にできるようになっている。