Microsoft は、商用インターネットの最初の時代から複雑なオンライン プラットフォームを運用してきました。 その過程で、システムを利用可能で正常で安全な状態に保つための一連のプラクティスが大幅に進化しました。 これらのプラクティスは、 ライブ サイト文化を維持および改善するためのより大きなイニシアチブの一部です。
ライブ サイトカルチャ
ライブ サイトカルチャは、他のすべてのものよりもライブ サイトのエクスペリエンスと信頼性に優先順位を付ける組織の焦点です。 結局のところ、顧客はクラウドとインターネットベースのサービスを使用して今日かなり簡単にサービス プロバイダー間を移動でき、顧客の信頼の重要性が大幅に増幅されます。 ライブ サイトは常に利用可能であり、顧客に対して約束どおりに実行する必要があります。
ライブ サイト文化の成功に貢献するさまざまな要因があります。
最初のライブ サイト
ライブ サイトエクスペリエンスを第一にすることは、成功するプラットフォームにとって不可欠です。 Teams は、新しい光沢のある機能にすべての焦点を当て、それらの機能がユーザーに提示される手段を無視することはできません。 Microsoft は、お客様が継続的なプラットフォーム アクセスを確実に利用できるように、 安全なデプロイ プラクティス に依存しています。 ダウンタイムなしでバージョン管理されたサービス更新プログラムをリリースする場合、これは特に複雑になる可能性があります。
機能フラグを使用して露出を制御する
階層とステージを通じてデプロイし、機能フラグを使用して露出を制御すると、運用環境で問題が見つかる場合があります。 すべての自動化とレビューにもかかわらず、状況は引き続き発生することがあります。 彼らが言っているように、 生産のような場所はありません!
通常、正常性の監視とテレメトリは、何かが正しくない場合にアラートを送信します。 開発者は、 mainからブランチを作成し、修正を行い、 mainに要求をプルできます。 同じ一般的なワークフローを維持することは、開発者が別のコード変更に対して別のプロセスをコンテキスト切り替えたり、学習したりする必要がないことを意味します。
修正プログラムの展開に対処するには、もう 1 つの手順が必要です。これは、リリース ブランチに変更を選択することです。 平日の朝に現在のリリース ブランチから修正プログラムの展開を実行しますが、緊急の修正を必要に応じて実行することもできます。 この修正プログラムは、実際には最初にリリース ブランチから運用環境にヒットします。 しかし、最初 main 開発するため、 mainから新しいリリース ブランチが作成されたときに、次のスプリントが後退しないことがわかります。
オンプレミス製品のリリースはほとんど同じですが、デプロイレベルとステージはありません。 また、さまざまな構成やデータ形状に対してより多くの手動テストを行うため、リリース ブランチを切断して製品を顧客の手に渡すことの間には、より長いテールがあります。
セキュリティは個人的に取る必要がある
脆弱性を現実的かつ個人的なものにすることに焦点を当てています。 これにより、人々は本当に気にすることを保証します。 また、コードに関係なく、システム全体のセキュリティリスクを見つけて対処するために、 戦争ゲーム を幅広く使用しています。 赤いチームは、ダイアログ ボックスを逆さまにしてコードに入ったと示すことができるとき、コード所有者が問題に対処し、他の場所で再び発生しないようにする動機を本当に高めます。 このような競争は、潜在的な XSS リスクに関する静的分析の警告よりもはるかに現実的で個人的です。 私たちは、戦争ゲームやその他のセキュリティ演習を通じて、このような文化とダイナミックを作成します。 人々は、お互いのコードをハッキングしたり、試みをブロックしたりすることに誇りを持っています。 これにより、セキュリティで保護されたコード カルチャが提供されます。
すべての攻撃ベクトルを計画することはできませんが、何ができるかは、侵害が発生すると想定し、その侵害に対応できる速度を計画することです。 セキュリティ作業の多くは、私たちのチームのためにその周りにされています。
最後に、人間は間違いを犯します。 時には怠け者になり、ファイル共有にパスワードを保存するなどの操作を行います。 私たちは彼らにそうしないことを伝えることができますし、セキュリティトレーニングにそれらを送ることができ、私たちは他のすべての種類を行うことができます。 ほとんどの人は学びますが、システムを壊すのに 1 人しかかかりません。 ベスト プラクティスのすべての種類のリストを持つことができますが、それが実際に行われる場合を除き、ユーザーが間違いを犯す可能性があると想定する必要があります。 これには、重要なプロセスに確実に従うために、特定のレベルの監視が必要です。
エンジニアリングは運用パートナー以上のもの
早い段階で、ライブ サイトをエンジニアリング チームの責任の重要な部分にすることを学びました。 これは、過去に 1 人のユーザーが何かを展開し、週末に出発し、月曜日に戻って、カスタマー サポートチームと ops チームが週末に対処していた 900 件の顧客問題を見つけたためです。 エンジニアリングは、ライブ サイトの問題に対して料金を支払う必要があります。 そうしないと、これらの問題を回避するシステムを構築するインセンティブはありません。 午前 2 時に呼び出され、壊れた問題を修正すると、覚えています。
私たちがこの責任を進化させたので、 ライブサイトは私たちが チーム全体のマントラになった最も重要なことです。 それは彼らが今持っているカスタマー エクスペリエンスであり、単なる税金ではありません。 それは実際に人々が私たちから頼りにしているものであり、私たちはそれに誇りを持っています。 それは私たちの製品の差別化機能である必要があります。
運用テレメトリはサービスのハートビートです
何も問題が発生する可能性のあるペースの速い世界で生き残るには、優れたアラート システムが必要です。 対応できないアラート、冗長なアラート、または大量のアラートを使用すると、すべてのアラートが無視されます。 非常に多くのアラートを作成するのは簡単なので、このプロセスは本当に単純な質問に絞り込まれます。 このアラートは実用的ですか? これにより、適切な顧客の問題に取り組み、可能な限り迅速に対応することができます。
エンジニアリング チームが実用的なアラートをゼロにしたので、特に深夜に発生する多くの問題が、少なくとも一時的に同様の修正を行う傾向があることに気付きました。 その結果、フェールオーバーと自己復旧の方が優れたシステムに焦点が当てられます。 問題が発生したら、アラートを生成し、エンジニアリング チームが午前まで修正するまで十分に修正します。 これは、エンジニアリング チームが夜に他の人を維持するビットを押し出しただけでは起こらなかったでしょう。 現在は、機能の速度だけでなく、エンジニアリングの改善速度の一部として、これらの改善のバランスを取るために取り組みます。
概要
ライブ サイト カルチャを採用することは、Microsoft がソフトウェアを構築して提供する方法に影響を与えました。 エンジニアリング チームをセキュリティと運用の重要な部分にすることで、コードとエンド ユーザー エクスペリエンスの品質が大幅に向上しました。 運用に完全に参加することにより、エンジニアリングは主要な利害関係者になり、その結果、より優れた運用用に設計されたシステムが生まれています。