Our DevOps Journey
マイクロソフトではクラウド & エンタープライズ エンジニアリング グループを中心に、
ソフトウェアの公開サイクルをスピードアップするための取り組みを推進しています。
.png)
.png)
クラウド & エンタープライズ エンジニアリング グループは、SQL、Power BI、Azure、Visual Studio、Visual Studio Online、Windows Server、System Center といった製品とサービスを統括している部門です。私たちの部門では各チームで長年アジャイル手法を実践してきました。この手法で開発段階における開発者とテスト担当者の作業はかなり効率化されましたが、リリース期間をさらに短くするには、運用プロセスに改善の余地が残されていることに気付きました。私たち自身が運用チームの業務にボトルネックを作り出していたのです。今こそアジャイル開発を成功させた経験を活かし、DevOps の世界に移行する必要があります。
ソフトウェア業界を見渡しても、私たちが味わった苦い経験から考えても、サービス提供の全体的な品質向上に決定的に足りなかったのは DevOps 手法や DevOps 的習慣でした。また、こうした手法を受け入れる組織再編や意識改革も同じくらい重要だということもわかりました。ここでは DevOps に移行する取り組みを通じて私たちが何を学び、それぞれのチームでどのような改革を実施したかをご紹介したいと思います。
"アジャイル計画での経験を
DevOps の世界でも活かす必要がありました。"
役割と責任範囲の変革
.gif)
サービス提供体制を刷新するにあたっては、サービスの計画、開発、ユーザーへのリリース、運用というソフトウェア ライフサイクル全体のバリュー チェーンをいかに最適化するか、その方法を見出さなければなりませんでした。この体制変更では、開発、テスト、運用の各段階に割り当てられていた役割と責任範囲を大幅に組み換えることが、ベストなサービスをユーザーに届けるために必要でした。 これまで私たちは、「機能チーム」の役割をプログラム マネージャー、開発者、テスト担当者の 3 つに分けていましたが、開発者とテスト担当者の間の引き継ぎの遅れをなくしたかったのと、すべてのソフトウェア開発の品質を向上させる目的から、従来の開発者とテスト担当者という役割を「ソフトウェア エンジニア」という 1 つの役割にまとめました。現在では、機能の実装と運用環境での正常稼働に関するあらゆる面の責任をソフトウェア エンジニアが担っています。
ベストなサービスをユーザーに届けるためには、設計から運用環境へのデプロイに至る開発ライフサイクル全体でエンジニアリング チームと運用チームが緊密に連携する必要があります。私たちは、チームどうしを隔てていた壁をさらに低くすることが必要でした。最初に着手したのは、運用チームに同じ土俵に立ってもらうことでした。これまでの運用チームは組織編成上エンジニアリング チームとの距離がありましたが、ベストなサービスを提供するためには両者を 1 つのチームにまとめることが必要と判断し、実行に移しました。これまでコーディングに専念していた人々とサービス運用に専念していた人々がタッグを組むことで、さまざまな機能の運用開始がさらにスピードアップしました。
"エンジニアの権限がさらに広がり、ソフトウェア開発プロセスのあらゆる面が彼らの管理下に移行されています。
開発、テスト、運用をエンジニアが担当することで、不具合があっても彼らの判断で必要な修正をかけることができます。"
.gif)
このことは私たちに大きな変化をもたらしました。ソフトウェア エンジニアの責任範囲がこれまでのように開発とテストだけに限定されず、正常な運用を維持することにまで広がったのです。この責任範囲の拡大には 2 つの意味があります。1 つは、機能チームのメンバーに、「ユーザーを理解すること、ユーザーが抱える問題を独自に分析すること、チームが生み出すエクスペリエンスでユーザーを魅了すること」について、今まで以上に自分のこととして意識してほしいということです。また、もう 1 つは、機能チームや 1 人ひとりのエンジニアに、運用環境に提供しているもの自体に責任を持ってかかわってほしいということでした。その結果、現在ではエンジニアの権限がさらに広がり、ソフトウェア開発プロセスのあらゆる面が彼らの管理下に移行されています。開発、テスト、運用をエンジニアが担当することで、不具合があっても彼らの判断で必要な修正をかけることができます。
運用チームのスタッフの意識と責任範囲も、これまでとは大きく様変わりしました。運用チームは現在「サービス エンジニア」という名前で呼ばれ、効率的なトラブルシューティングのためのアプリケーション アーキテクチャに対する理解、インフラストラクチャのアーキテクチャ変更の提案、Infrastructure as Code や自動化スクリプトなどの開発とテスト、サービスの設計や管理を分担するための協力が求められています。以下の表のとおり、運用チームが従来担当してきた業務の大部分は完全自動化または一部自動化され、エンジニア チームと運用チームが共に担当しています。自動化は重要なテーマです。マイクロソフトではソフトウェア ライフサイクルのあらゆる要素を次々と改善することで、規模を拡大しつつ、ユーザーに向けスピーディに価値を提供しています。また、稼働領域が増加し、それに伴いエラーの発生する可能性も増えたため、サービス エンジニアの持つスキルはチームにとって欠かせないものとなっています。
| 運用に関連する業務 | DevOps 移行以前の 割り当て先 |
DevOps 移行後の 割り当て先 |
|---|---|---|
| 容量管理 アプリケーションを実行するインフラストラクチャの容量を可視化し共有。自動スケーリングはコードで定義される。 |
運用チーム (Ops) | DevOps* |
| リアルタイムのサイト管理 個人の責任を追求しないという方針のもと、インシデント検証を共同で実施し、未処理作業の改善に活かす。監視を通じてインシデントが自動的に明確化されない場合も、アプリを開発チームが担当し、プラットフォームを運用チームが担当して、両者が緊密に協力しながら解決を図る。 |
運用チーム (Ops) | DevOps* |
| 監視 機能の詳細な可用性監視、自動化されたカスタムのテレメトリ/ログ/ダンプ監視、アプリケーション パフォーマンス監視を運用前環境と運用環境で実施。警告は開発チームと運用チームに送信される。 |
運用チーム (Ops) | DevOps** |
| 問題管理 運用環境の傾向および頻発する問題を運用チームが特定し、その結果に基づいて開発チームがサービスを強化。 |
運用チーム (Ops) | DevOps* |
| 変更管理 新しいサービスと修正プログラムを運用環境に自動でデプロイ。ピア レビューの体制を完備し、DevOps 手法を実践することにより、自動テストと運用環境でのテストをデプロイする際のリスクも低減。 |
運用チーム (Ops) | 開発チーム (Dev)** |
| サービス設計 操作要件とアーキテクチャの共通のベースラインを運用チームが定義。開発チームと運用チームが成熟度を定期的にレビュー。 |
開発チーム (Dev) と運用チーム (Ops) | DevOps |
| サービス管理 共通のプロセスと SLA に基づいてサービスを公開し、一部自動化されたサービスのレビューを実施。コストと予算の計画は運用チームが担当し、推奨事項は開発ライフサイクルにフィードバックされる。 |
運用チーム (Ops) | DevOps |
* 一部が自動化
** 大部分または全部が自動化
いずれの変革についても抵抗感がまったくなかったわけではありませんが、結局わからないのであれば、チームの 1 人ひとりに求められている役割がスムーズに伝わることが大切だという結論に達しました。後から振り返ると、これは社内文化の大きな変革を決定付けた判断でした。
"お客様に影響が生じる前に問題を把握する必要があります。
サービスの状況を可視化でき、問題を診断でき、
その問題をスピーディに解決できることは非常に重要なのです。
その鍵となるのがテレメトリです。"
部門の統括チームは、導入する DevOps 手法の影響力を強化、測定するにあたり、ソフトウェア エンジニアリングとサービス エンジニアリングに共通の指標を設定しました。責任範囲を共有することによって開発チームと運用チーム間の緊密なコラボレーションとシナジー効果が促進され、結果的にお客様の利益につながっています。
DevOps 的習慣
クラウドの世界のペースにうまく移行するには、DevOps に有効な習慣をチームに根付かせ、洗練させる必要がありました。この目標を達成するために新たに取り入れた手法を一部紹介します。
リリース期間の短縮 - エンジニアリング チームではさまざまな DevOps 手法を導入し、開発チームと運用チーム両方のコラボレーション基盤を確立し、煩雑な手作業の無駄をなくしました。たとえば、「Infrastructure as Code」を導入したことで、全世界の運用環境にデプロイされるスケール ユニットのプロビジョニングと管理が効率化され、サービス ライフサイクル全体に恩恵がもたらされました。ほかにも、「継続的デプロイメント」と「リリース管理」の導入によって、運用環境で発生する変更の自動化、調整、視覚化、測定を促進しています。
お客様の運用環境から情報を収集 -
Application Insights と Power BI サービスを利用して豊富なユーザー テレメトリと統計情報を収集し、お客様が使用するサービスとその使用状況を分析して、ユーザー エクスペリエンスと顧客満足度の向上に活かしています。DevOps 手法の「運用環境でのテスト」を導入し、新機能を世界中のお客様にロールアウトする前に、既に運用を開始している一部のお客様からデータを収集し、改善、修正できるようにしました。
お客様よりも先に問題を検出 -
マイクロソフトの DevOps の取り組みでは、フィードバックをできるだけ早く入手するという方針をソフトウェア ライフサイクルのあらゆる段階で徹底しています。たとえば、「継続的インテグレーション」の手法を導入し、毎回のチェックイン時に単体テストを実施し、1 つのスプリントをデプロイする前に大規模な自動テストを実施することで、そこから得られるフィードバックを高品質なコードと運用環境での不具合削減に活かしています。さらに、「高度な可用性監視」と「アプリケーション パフォーマンス監視」を導入したことで、データの収集と問題の特定、診断、解決までをスピーディに処理し、お客様への影響をほとんど発生させていません。
.gif)
.gif)
.gif)
.gif)
今後の展望
アジャイルへの移行がそうであったように、DevOps への移行は一瞬で終わるものではなく、時間をかけた取り組みになることを認識する必要があります。どのツール、どの製品を選ぶかではなく、どのような DevOps 手法を取り入れ、それらをいかに改善していくかを考えることが大切です。私たちのこれまでの DevOps の取り組みで学んだ重要項目を以下に紹介しますので、ぜひ参考にしてください。
開発チームと運用チームの従来の役割と責任範囲から脱却する - 組織で DevOps に取り組むにはまず「システム思考」が必要になります。お客様に対する最も効率的な価値提供の方法を、ソフトウェアの構想、運用、バックエンドに携わるあらゆる担当者で分析することが求められます。その結果、多くの場合はそれまでの組織構造、責任範囲、仕事のやり方を開発チーム、運用チーム、さらにはビジネス全体で見直す必要が出てきますが、チーム全体で共通の指標を導入することで、組織改革の進捗を確認しながら変革を推進していくことができます。
自動化は欠かせない要素 - ソフトウェア ライフサイクルのあらゆる領域について自動化を検討し、可能な限り実現する必要があります。これは、役割と責任範囲の再編に取り組む場合は特に重要になります。手作業によるプロセスは、テスト、環境構築、リリース管理といった領域では特に、顧客への価値提供を大幅に遅らせる原因となります。
スプリントの達成度を 100% にする - リリース候補を蓄積するのではなく、毎回のスプリントがすぐに運用環境へのリリースにつながるようなプロセスを構築するには、スプリントをクローズする時点で、すぐにデプロイできる状態の成果物が完成しているようにする必要があります。その他のさまざまなアジャイル手法を活用した経験からも、新しいビルドがお客様にすぐにリリースできる状態であれば、スピーディなフィードバック ループを構築し、本当に求められる製品を完成させることができます。
テレメトリとアナリティクスを導入する - テレメトリとアナリティクスはサービスの運用に絶対に欠かせない機能です。私たちは、1 つの完結した製品を開発するやり方から、DevOps 手法を導入してサービスとして運用するやり方に移行したことで、テレメトリを収集することの大切さを痛感しました。テレメトリにより、お客様が求めている製品を開発できているかを常に確認できるだけでなく、エクスペリエンスの構築にあたり実験的な取り組みや仮説の検証を行う際も、いつでも必要なデータを収集することができます。
マイクロソフト エキスパートから皆様へ
JAMES PHILLIPS
Power BI を支える「リリース トレイン」
BUCK HODGES
経験からおすすめすること
MADHU KAVIKONDALA
運用チームの将来とは
LORI LAMKIN
スコア カード
SAM GUCKENHEIMER
マイクロソフトの DevOps
MUNIL SHAH
リアルタイムのサイト監視
※本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。
.gif){kind=icon}
ページのトップへ