「本番環境などという場所はない」マイクロソフトが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」の続きです)

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

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

fig

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

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

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

fig

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

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

fig

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

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

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

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

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

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

fig

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

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

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

fig

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

fig

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

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

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

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

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

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

fig

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

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

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

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

fig

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

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

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

fig

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

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

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

本番環境などという場所はない

Samが言っていたのは、「本番環境などという場所はない」ということ。

fig

いままで本番環境には壁があって、そこは神聖な場所という感じでした。しかしお客さんへのサービスを向上するには本番環境からしか学べない。ここでも僕らは実験をしてフィードバックをもらって、お客さんと一緒に成長していくという場所。

だから本番環境から学ぶために、そこへデプロイすることを恐れず、ライフサイクルを早く回せるほど、よりよいプロダクトが届けられるようになる。

そういうところで僕らマイクロソフトはやっていますと。

Microsoftが実践したScrum導入7年間の旅そしてDevOpsTsuyoshi Ushio

基となったSam Guckenheimer氏の講演の動画「DOES15 - Sam Guckenheimer - Visual Studio Online: The Inside Story from COTS to Cloud

Regional SCRUM GATHERING Tokyo 2016

関連記事

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : DevOps , Microsoft , アジャイル開発



≫次の記事
マイクロソフト、オープンソース版.NETのバージョン番号を1.0に。「ASP.NET Core 1.0」「.NET Core 1.0」にすると発表
≪前の記事
「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化(前編)。Regional SCRUM GATHERING Tokyo 2016

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus