- マイクロソフトコーポレーション
- シニアテクニカルエバンジェリスト DevOps ITPro
- 牛尾 剛
「DevOpsは地道な改善活動」 エバンジェリストが語る、DevOpsの始め方(後編)
〜小さなリリースサイクルの見直しから始まるDevOpsの実践により、障害の発生率が1/60に、デプロイまでのリードタイムが1/200になることも 〜
「DevOpsは技術だけでは成り立たない」 エバンジェリストが語る、本当のDevOps(前編)では、DevOpsが誕生した経緯から、その本質までを伺った。DevOpsは技術的側面、組織的側面の両面から語られる必要があり、単純にツールを導入するだけでは実践しているとは言えないと、米Microsoftの牛尾 剛さんは語る。
しかし、ツールの導入だけでは解決しないとしたら何から始めていけばいいのだろうか。海外では既に大企業の多くがDevOpsを実践し始めており、日本企業との間には大きな差が開いてしまっている。後編の今回は、大企業でもDevOpsを実施できている理由、そしてDevOpsを始めるためのコツについてお伺いした。
海外では大企業もDevOpsを実践
海外の環境は確実に日本より進んでいて、相当固い会社までDevOpsを実践しているんですよ。以前、DevOps Enterprise Summitという海外のイベントに行ったことがあるのですが、その中に生保や銀行といったところがガンガンにDevOpsを実践しているという話がありました。凄くないですか?
なぜ大企業なのにそういったことが出来るのかというと、スモールチームで構成されているんですね。マイクロサービスという疎結合なサービスを連携させるアーキテクチャを採用することで、大規模なサービスでもスモールチームを組めるんです。
今まで大企業というのは、スピードの面でスタートアップに負け続けていました。その状況が変わりつつあり、どんな企業でもスモールチームを構成し、1日10回のデプロイが実現できるようになっているというのが最近の流れです。
日本ではまだまだDevOpsは発展途上
一方で、日本の会社を見てみるとDevOpsを実践しているところはごく少数です。クックパッドさんの取り組みは未来を感じるのですが、そうでない会社に行くとツールを導入しただけでDevOpsと言っていたり、バージョン管理程度しか出来ていないとか、差が激しいと感じています。
そういう現場をみると、まだDevOpsというものが正確に伝わってないんだなと感じます。数年前に技術の部分だけが注目されてバズワードになってしまっていることも原因です。
なので、もっと本質的なところを理解して「リリースサイクルを改善するにはどのように組織構造を変えるべきか」とか、「どの部分に作業の無駄が発生しているか」といったように、技術面以外の要素も含めたプロセス全体の改善施策を試していけると良いのかなと思います。
DevOps初心者にオススメの「バリューストリームマッピング」
DevOpsを実践できていない会社にまずオススメするのは、バリューストリームマッピングという手法です。リリースまでのプロセスの中を、ペインポイント、待ち時間とバリュータイム(実際に価値を生み出している時間)を加えて分析して見える化するんですよ。
そうすると「ここは今3営業日かかっているけど、実は自動化できるんじゃないか」というのが見えてきます。それをエンジニアだけじゃなく、ビジネスサイドの人も加えて行うといいと思います。
結構よくある話なのが、エンジニアが(この運用ルールは変えることは出来ないな・・)と思っていたものが、ビジネスサイドに聞いてみると「いやそんなの全然変えちゃって大丈夫だよ」ということがあるんですよ。「じゃあこのルールは今後ナシで」となって効率化できたりする。
そういう所を起点にして、少しずつ改善していくことが重要だと思います。一気にDevOpsをやろうぜ、というよりも分かりやすさを重視して「10 deploys per day」をまずは最初の指標にして、それを実現するために今するべきことを地道に実践していく。
例えば、CIでテストを回したり、本番環境に自動でデプロイされるようなリリースマネジメントを実施したり、KANBANで情報共有をしたり、Infrastructure as Code を実践したり…というステップを踏んでいくんです。
(※DevOps のゴールは、「リードタイムの短縮」「デプロイ後にそこからフィードバックを得ること」「継続的に実験して学んでいくこと」の3つがあります。「10 deploys per day」 はこのうち1つ目の指標を直感的にわかりやすく、インパクトのある表現として表したものです。 )
手痛い失敗がDevOpsの重要性を認識させた
実はMicrosoftも一度、DevOpsが実現できていなかった事でひどい目にあってるんですよ。Team Foundation Serverという評判のいいオンプレの製品をクラウド化しようという話があり、Visual Studio Team Serviceというサービスを作りましたと。
それをリリース当日、フィーチャーフラグをオンにして一斉に100万人に公開したんですけど、一気に落ちてしまいまして(笑)。その後も断続的にひどい目にあって、凄く恥ずかしい思いをしました。モニタリングも真面目にやっていなかったので原因の特定にも時間がかかったわけです。
そういう経緯もあり、社内でもDevOpsをしっかりやる必要があるなという認識が生まれました。そしてエンジニアとQA、Ops、仕様を決める人を合わせてフィーチャーチームというものを作り、小さいチームに強い権限を与えて、カスタマーと直接コラボレーションして進めていく形に変わりました。
そうやって作っていった文化やノウハウを整理をして、DevOpsを広めていこうとしています。
リードタイムが200分の1になることも
日本人って何でも完璧にこなそうとするじゃないですか。ただ、どれだけ完璧を目指しても、サービスというものは実際にプロダクションにリリースしてみないと分からないことも多いんですよ。
なので、高度なDevOpsを実践している会社では、Canary Releaseという一部のお客様にだけ限定的に公開するような仕組みを構築していることもあります。
世界的な規模で展開しているサービスで、一気に全世界にサービスを公開するのは危険です。そうせずにまずは限定されたユーザ様にだけ公開して、本当に新しい機能がうまく動いているかを確認して、全世界に徐々に公開していったりします。Microsoftもこの手法を用いています。
ある調査結果では、DevOpsを実践することで障害の発生率が1/60になるとか、デプロイまでのリードタイムが1/200になるという結果も出ています。衝撃的な数字ですよね。でも大げさではなくて、今まで3ヶ月に1回しかリリースが出来なかったものが、一日に何回もリリースできるようになるわけですから。
インフラが自動化されていれば障害が発生しても、その問題が発生したサーバーを調査して、パッチを当てなくても、1から新しいサーバーインスタンスの払い出しもすぐにできるので障害からの回復が非常にはやくなります。このようなメリットは非常に大きいと思います。
日本に衝撃を与えるため、DevOpsの認知度を上げていく
僕は、日本に衝撃を与えたいんですよ。海外では相当固い会社までDevOpsを実践しているのに、日本人は偉い人のハンコ待ちなんでやって生産性を落としている場合じゃないだろうと。その世界をぶち壊して、エンジニアの人がいきいき働きながら、企業がどんどん利益をあげているという世界を作るお手伝いが出来ればいいなと思っています。
そのためには、必ずしもMicrosoftのツールを入れてもらう必要はないんです。まずはお客様にDevOpsというものを理解してもらったり、プラクティスを理解してもらって 、お客様でも「10 Deploys per day」を実現できる能力を身につけて欲しいんですよ。
日本人は事例が好きなので、そこで衝撃的な事例を1つ作れば、認知度は上がっていくと思います。そうして、まずは本当のDevOpsを皆さんにインストールするお手伝いをしていきたいですね。(了)