Microsoft が DevOps でソフトウェアを提供する方法

  • [アーティクル]

Microsoft には、運用環境に拡張性の高いサービスを提供する数十年の経験があります。 Microsoft のサービスと環境が拡大するにつれて、その提供方法も時間の経過とともに進化してきました。 多くの Microsoft 顧客も、これらの効率的な配信手法を採用し、その恩恵を受けています。 次の DevOps の中核原則とプロセスは、最新のソフトウェア配信の取り組みに適用できます。

DevOps 配信プロセスを実装するために、Microsoft は次の取り組みを採用しました。

  • 組織の考え方と配信のリズムに焦点を当てます。
  • 機能を所有、テスト、提供する自律的で責任あるチームを形成します。
  • 実稼働環境でのシステムのテストと監視に右シフトします。

配達に重点を置く

より速く発送できることは、組織やチームが簡単に測定し、評価できる明白な利点です。 一般的な DevOps のサイクルには、運用環境への定期的なデプロイメントを伴う短いスプリント サイクルが含まれます。

一部のチームは、短いスプリントでは製品の安定性が欠如することを恐れ、スプリント サイクルの終わりに安定化期間を設けて補っていました。 エンジニアはスプリント中にできるだけ多くの機能をリリースしたいと考えていたため、安定化中に返済しなければならないテスト負債が発生しました。 スプリント中に借金を管理したチームは、借金が増えたチームをサポートする必要がありました。 追加コストは、配信パイプラインを通じて本番環境に影響を及ぼしました。

安定期間を削除すると、チームの借金管理方法がすぐに改善されました。 負債が蓄積したチームは、主要なメンテナンス作業を安定化期間に先送りするのではなく、次のスプリントをかけて負債目標を達成するために費やす必要がありました。 チームはスプリント中にテスト負債を管理する方法をすぐに学びました。 機能は、実証され、導入コストに見合う価値がある場合に提供されます。

パイプラインを完全に自動化する

改善チームがすぐに得られる効果の多くは、コード リポジトリから本番環境までのパイプラインを完全に自動化することです。 自動化には、継続的インテグレーション (CI)、自動テスト、継続的デリバリー (CD) を備えたリリース パイプラインが含まれます。

チームは、デプロイが難しいため、デプロイを避けるかもしれませんが、デプロイの頻度が低いほど、デプロイは難しくなります。 導入間の時間が長くなるほど、より多くの問題が山積します。 コードが新しくないと、デプロイメントの負債が生じます。

頻繁にデプロイすることで、より小さな単位で作業する方が簡単になります。 このアイデアは後から考えると明白に思えるかもしれませんが、当時は直観に反するように思えるかもしれません。 また、頻繁なデプロイメントにより、チームはより効率的で信頼性の高いデプロイメント ツールとパイプラインの作成を優先するようになります。

社内ツールを使用する

Microsoft は自社が構築したリリース管理システムを使用し、それを顧客に出荷します。 1 回の投資で、チームの生産性と Microsoft 製品の両方が向上します。 セカンダリ システムを使用すると、開発と配信の速度が吸い取られてしまいます。

チームの自主性と説明責任

チームの生産性やパフォーマンス、あるいは機能が順調に進んでいるかどうかを測定する特定の重要な進捗指標 (KPI) はありません。 チームは、組織の目標と一致する方法を見つけながら、独自の計画とバックログを管理できる必要があります。

進捗状況を追跡するには、チームと直接コミュニケーションをとることが重要です。 ツールはコミュニケーションを促進する必要がありますが、会話はコミュニケーションの最も透明な方法です。

機能に優先順位を付ける

重要な目標は、機能の提供に重点を置くことです。 スケジュールでは、チームや個人が一定期間内にどれだけの作業を合理的に完了できるかを評価できますが、一部の機能はより早く提供され、一部の機能はより遅く提供されます。 チームは作業に優先順位を付けて、最も重要な機能を本番環境に導入することができます。

マイクロサービスを使用する

マイクロサービス は、配信を改善および簡素化するさまざまな技術的利点を提供します。 マイクロサービスは、チームの所有権に自然な境界線も提供します。 チームがマイクロサービスへの投資について自主性を持っている場合、機能の実装方法と負債の管理方法に優先順位を付けることができます。 チームは、マイクロサービスに依存するサービス全体とは独立して、バージョン管理などの要素の計画に集中できます。

メインでの作業

エンジニアは以前は別々の支店で働いていました。 各ブランチのマージ負債は、エンジニアがブランチをメイン ブランチに統合しようとするまで増加しました。 チームとエンジニアの数が増えれば増えるほど、統合はより大規模になります。

統合をより迅速に、より継続的に、そしてより小さな単位で行うために、エンジニアは現在メイン ブランチで作業しています。 Git に移行する大きな理由の 1 つは、Git が提供する軽量の分岐でした。 内部エンジニアリングにとっての利点は、深いブランチ階層とその無駄を排除することでした。 これまで統合に費やされていた時間はすべて、配信に費やされるようになりました。

機能フラグの使用

一部の機能はスプリント デプロイ向けに完全には完成していませんが、実稼働環境でのテストからメリットを得ることができます。 チームは、このコードを機能フラグとマージしてデプロイし、開発チームや一部の早期採用者などの特定のユーザーに対して機能を有効にすることができます。 機能フラグは、ユーザー ベース全体に問題を引き起こす危険を冒さずに露出を制御し、チームが機能を完了するかどうか、またその方法を決定するのに役立ちます。

運用環境でのテスト

実稼働環境でのテストへの移行は、実稼働前テストが有効であることを確認し、常に変化する実稼働環境で展開に対応できるようにするのに役立ちます。

機器のテストと測定基準

アプリをどこにデプロイするかに関係なく、すべてを計測することが重要です。 インストルメンテーションは、問題の特定と修正に役立つだけでなく、使用方法や次に何を追加するかについての貴重な調査を提供します。

回復力パターンをテストする

複雑な展開のリスクはカスケード障害です。この障害では、1 つのコンポーネントの障害が依存コンポーネントの障害を引き起こし、システム全体が故障するまで続きます。 単一障害点 (SPOF) がどこにあるのか、どのように軽減されるのかを理解し、特に運用環境で軽減プロセスをテストすることが重要です。

適切なメトリクスを選択する

メトリクスの設計は難しい場合があります。 よくある間違いは、何かを見落とさないようにするために、あまりにも多くのメトリクスを含めることです。 しかし、これは、特定のニーズを満たさない指標の値を無視したり、不信感を抱いたりすることにつながる可能性があります。 その代わりに、Microsoft チームは時間をかけて、成功を測定するために必要なデータを決定します。 チームは指標を追加または変更する可能性がありますが、最初から目的を理解していれば、そのプロセスが容易になります。

チームは、メトリクスの基礎に加えて、測定するメトリクスが何を必要とするかを検討します。 たとえば、ユーザーの増加の速度または加速度は、ユーザーの総数よりも有用な指標となる可能性があります。 指標はプロジェクトごとに異なりますが、最も役立つのは、ビジネス上の意思決定を促進する可能性のある指標です。

メトリクスを使用して作業をガイドする

Microsoft には、最高のリーダー レベルでのレビューを含むメトリクスが含まれています。 組織は 6 週間ごとに、健康、ビジネス、シナリオ、顧客テレメトリーに関する自社の状況を発表します。 組織は、経営幹部やチームと指標について話し合います。

組織全体のチームが、エンゲージメント ユーザーの指標を調査して、機能の意味を判断します。 チームは機能を出荷するだけでなく、ユーザーがそれらを使用しているかどうか、またどのように使用しているかを確認することに重点を置いています。 チームはこれらの指標を使用してバックログを調整し、目標を達成するために機能にさらに作業が必要かどうかを判断します。

配送ガイドライン

  • A から B に到達するのは決して直線ではありませんし、B が終わりでもありません。
  • 挫折や間違いは必ずあります。
  • 挫折を、プロセスの特定の部分を完了するための戦術を変更するための学習の機会として捉えます。
  • 時間の経過とともに、各チームは経験を積み上げ、変化するニーズに合わせて調整することで、DevOps プラクティスを進化させます。
  • 重要なのは、エンドユーザーと配信プロセス自体の両方に価値を提供することに重点を置くことです。