Microsoft が DevOps で信頼性の高いシステムを運用する方法
Microsoft は、商用インターネットの初期の頃から複雑なオンライン プラットフォームを運営してきました。 その過程で、私たちはシステムの可用性、健全性、安全性を維持するための実質的な一連の実践を進化させてきました。 これらの実践は、ライブ サイト文化を維持および改善するためのより大きな取り組みの一部です。
ライブ・サイト文化
組織はライブ サイトの文化に重点を置き、ライブ サイトのエクスペリエンスと信頼性を何よりも優先します。 結局のところ、今日ではクラウドやインターネットベースのサービスにより、顧客はサービス プロバイダー間をかなり簡単に移動できるため、顧客の信頼の重要性が大幅に高まっています。 ライブ サイトは常に利用可能であり、顧客への約束どおりに機能する必要があります。
ライブ サイト文化の成功にはさまざまな要因があります。
まずはライブサイト
プラットフォームの成功には、ライブ サイトのエクスペリエンスを最優先することが不可欠です。 チームは、新しい輝かしい機能にすべての焦点を当てて、それらの機能をユーザーに提供する手段を無視することはできません。 当社は、お客様が中断のないプラットフォーム アクセスを確実に享受できるよう、安全な導入慣行を重視しています。 ダウンタイムなしでバージョン管理されたサービス更新をリリースする場合、これは特に複雑になる可能性があります。
機能フラグによる露出の制御
リングとステージを通じて展開し、機能フラグで露出を制御すると、運用環境で問題が発見されることがあります。 あらゆる自動化とレビューにもかかわらず、依然として問題が発生することがあります。 よく言われるように、生産に勝る場所はありません!
通常、ヘルスモニタリングとテレメトリは、何か問題が発生した場合に警告を発します。 開発者は mainからブランチを作成し、修正を行って、それを main にプルリクエストできます。 同じ一般的なワークフローを維持するということは、開発者がコンテキストを切り替えたり、別のコード変更に対して別のプロセスを学習したりする必要がないことを意味します。
ホットフィックスの展開に対処するには、リリース ブランチに変更を厳選するという、もう 1 つの手順が必要です。 現在のリリース ブランチからホットフィックスのデプロイメントを平日の毎朝実行していますが、緊急の修正の場合はオンデマンドで実行することもできます。 この修正は実際には、リリース ブランチから最初に本番環境に適用されます。 ただし、最初に main で開発するため、main から新しいリリース ブランチが作成されたときに次のスプリントで後退しないことがわかっています。
オンプレミス製品のリリースはほぼ同じですが、展開リングとステージは異なります。 また、さまざまな構成やデータ形式に対してより多くの手動テストを行うため、リリース ブランチをカットしてから製品を顧客の手に渡すまでに長い時間がかかります。
セキュリティは個人的に考える必要があります
焦点は、脆弱性を現実的かつ個人的なものにすることです。 これにより、人々は本当に気にかけてくれるようになります。 また、コードかどうかに関係なく、システム全体のセキュリティ リスクを見つけて対処するために、戦争ゲームを広範囲に利用しています。 レッド チームがダイアログ ボックスを上下逆さまにしてコードに侵入したことを示すことができれば、コード所有者は問題に対処し、他の場所で同じ問題が二度と起こらないようにしようという意欲が高まります。 この種の競争は、潜在的な XSS リスクについて警告する静的分析よりもはるかに現実的で個人的なものです。 私たちは戦争ゲームやその他の安全保障演習を通じて、この種の文化とダイナミクスを生み出します。 人々は、お互いのコードをハッキングしたり、その試みをブロックしたりできることに誇りを持っています。 これにより、安全なコード文化が浸透します。
すべての攻撃ベクトルに対して計画を立てることはできませんが、私たちにできることは、侵害が起こることを想定し、その侵害にどれだけ早く対応できるかを計画することです。 私たちのチームでは、多くのセキュリティ作業がこれに関連して行われてきました。
最後に、人間は間違いを犯します。 彼らは時々怠け者になり、ファイル共有にパスワードを保存するなどのことをします。 私たちは彼らにそうしないように指示することもできますし、セキュリティトレーニングに参加させることもでき、その他あらゆる種類のことを行うことができます。 ほとんどの人は学びますが、システムを壊すのに必要なのはたった 1 人だけです。 あらゆる種類のベスト プラクティスのリストを作成することはできますが、それを現実のものにしない限り、人は間違いを犯すものだと想定する必要があります。 これには、重要なプロセスが確実に守られるようにするために、一定レベルの監視が必要です。
エンジニアリングは単なる運用パートナーではありません
私たちは、ライブ サイトをエンジニアリング チームの責任の重要な部分にすることを早い段階で学びました。 これは私たちにとって非常に大きなことでした。なぜなら、これまでは 1 人が何かをデプロイし、週末に出発し、月曜に戻ってカスタマー サポートと運用チームが週末を通して対応していた 900 件の顧客の問題を見つけることができたからです。 エンジニアリングが実際のサイトの問題に対して代償を払うことが重要です。 そうでなければ、それらの問題を回避するシステムを構築する動機がありません。 自分が壊したものを直すために午前2時に呼ばれたとき、あなたは思い出します。
この責任を進化させるにつれて、ライブ サイトは私たちが行う最も重要なことであるがチーム全体の合言葉になりました。 それは彼らが現在得ている顧客体験であり、単なる税金ではありません。 実際、それは人々が私たちに期待していることであり、私たちはそれを誇りに思っています。 それは当社の製品の差別化機能である必要があります。
実稼働テレメトリはサービスの心臓部です
事実上あらゆる問題が発生する可能性がある、ペースの速い世界で生き残るためには、優れた警報システムが必要です。 対処できないアラート、冗長なアラート、または膨大な量のアラートがあると、すべてのアラートを無視することになります。 あまりにも多くのアラートを作成するのは簡単です。そのため、このプロセスは次のような単純な質問に集約されます。このアラートは対処可能ですか? これにより、お客様の問題に適切に対処し、できるだけ早く処理できるようになります。
エンジニアリング チームが実用的なアラートに焦点を当てたとき、特に深夜に発生する多くの問題は、少なくとも一時的には同様の修正が行われる傾向があることに気づきました。 その結果、フェイルオーバーと自己修復に優れたシステムに焦点が当てられるようになりました。 ここで問題が発生し、アラートが発せられ、エンジニアリング チームが朝まで修正を待つことができる程度に自動的に修正されます。 もしエンジニアリングチームが他の人を夜眠れなくさせるような部分をただ押し出していたなら、こんなことは起こらなかったでしょう。 現在、彼らは機能の速度だけでなく、エンジニアリングの改善の速度の一部として、これらの改善のバランスをとることに取り組んでいます。
まとめ
ライブ サイト文化の採用は、Microsoft のソフトウェアの構築と提供の方法に影響を与えています。 エンジニアリング チームをセキュリティと運用の重要な部分にすることで、コードの品質とエンドユーザー エクスペリエンスが大幅に向上しました。 運用に全面的に参加することで、エンジニアリングが主要な利害関係者となり、その結果、運用が改善されるように設計されたシステムが実現します。