オペレーショナル エクセレンス成熟度モデル

問題解決におけるチームワークと一貫性を強調し、後の段階で一貫した安定した運用を生み出す強力な基盤を確立します。

将来の戦略を確実に成功させるために、レベル 1 で DevOps の考え方を確立します。 プロセス効率を向上させるために、確立された DevOps 手法を実装します。 安定した運用のために、不可欠で一般的なボキャブラリ、プロセス、ツールの構築に重点を置きます。

主な戦略

✓コラボレーションを奨励し、非難のない文化を育む

チームの取り組みをビジネス ニーズに合わせ、コラボレーション文化を育てます。

一元化されたチームのメンバー、ワークロード機能専用のフルタイム スタッフ、パートナー、またはベンダーは、多くの場合、ワークロード操作を管理します。 これらの個人は、互いの専門知識を尊重し、認め合い、集団的な力として機能する必要があります。 チームが独立したパーツとして動作すると、複雑さと摩擦が発生する可能性があります。 独立したチームは、ビジネス成果を推進する単一の効率的なシステムとして機能するという目標を損ないます。

分離された所有権の感覚を減らすには、問題解決のための統一されたアプローチを推奨します。 すべての努力は、ビジネスのニーズに対応する必要があります。 成功と失敗の両方を共有結果として表示します。

✓ 標準的なコラボレーション手法とツールを採用する

ワークロードに合わせて開発効率を向上させる、業界で実証済みのツールとソフトウェア開発ライフサイクル (SDLC) プロセスから始めます。 多くの場合、高い摩擦が発生するため、実証済みの方法から逸脱し、カスタム手法を回避しないでください。

アジャイル、スクラム、かんばんボードなど、一般的な選択肢があります。 ほとんどの経験豊富な開発者、DevOps エンジニア、製品所有者は、これらのツールに精通しているため、新入社員の学習曲線が最小限に抑えられます。

最初は、確立された業界標準を使用して標準化を組み込みます。 後でプロセスを最適化します。 選択したツールが、最先端のソリューションへの切り替えを途中で必要とせずに、ニーズに合わせて成長できることを確認します。

✓ ソース管理プロセスを設定する

アプリケーションの規模に基づいて、ソース コードの構造を決定します。 大規模なシステムの場合、各チームには、担当するコンポーネントを構築および展開するための独自のプロセスが必要です。 コンポーネントの検出可能性とシステムの他の部分との共有を可能にするインターフェイスが明確に定義されている必要があります。 ソース管理テクノロジを選択し、チーム メンバーが互いの作業に干渉しないようにプロセスを設定します。

同様に、小規模なアプリケーションでは、1 つのデプロイ パイプラインの方が効果的な場合があります。 これにより、調整が簡略化され、信頼性も向上する可能性があります。 ただし、システムの特定の部分を更新または移行するのは困難な場合があります。

✓ コードとしてのインフラストラクチャ (IaC) をプライマリ デプロイ アプローチとして使用する

デプロイの標準として宣言型アプローチを使用して、一貫性、再現性、および自動化、自己文書化、変更履歴などの長期的な利点を確保します。

一貫性のない構成やテストの欠如によるリスクを回避するには、ポータルのデプロイよりも IaC デプロイを優先します。 特定のプログラムに制限されているコンパイル済みの言語または独自の形式は使用しないでください。

Bicep や Terraform など、Azure がネイティブにサポートするツールを使用して、適切な基盤から始めます。 ツールを評価して、将来の作業を簡略化します。 テクノロジ プロバイダーに適切なドキュメントと信頼性の高いサービス サポート プログラムがあることを確認します。

リスク： 最新化の機会を逃したことをリスクと考えてください。 たとえば、オンプレミス ソリューションで使用するツールとプロセスを最新化する必要があります。 クラウドに移行する場合、多くの場合、これらのツールでは管理が困難なカスタム スクリプトが必要であり、最新化しないと問題が発生する可能性があります。

このリスクを軽減するには、最新のテクノロジ オプションを調べて、オンプレミス のプロセスを更新します。

IaC を採用するための目標の 1 つは一貫性です。 さまざまな環境にデプロイするのに十分な柔軟性を持つテンプレートを作成します。 パラメーター、変数、および構成ファイルを使用して、各環境のリソース設定を変更します。 必要な設定のみを抽象化し、ほとんど変更されない設定の過剰な抽象化を避けます。 また、広範なテンプレート ライブラリに依存して、ソリューションの複雑化を避けてください。 この方法は、メンテナンスの課題につながる可能性があります。

将来のレベルで展開とシステム管理の最適化のためのより多くの機会を作成するための強固なIaC基盤を確立します。 たとえば、目的の状態構成や GitOps を追加できます。

✓最初からセキュリティに優先順位を付ける

この初期段階でもセキュリティに優先順位を付けます。 セキュリティ対策は、多くの場合、ロール、リソース、ネットワークなどのセグメント化に基づいており、複雑さが生まれます。 チームは、これらの複雑さを認識し、早期にセキュリティ対策を構築し、時間の経過に伴うセキュリティへの投資を計画する必要があります。 この方法では、セキュリティ実装を後のステージに遅延させるのを回避できます。

リスク： 開発、サポート、運用のプロセスは摩擦を生む可能性があります。 多くの場合、セキュリティの取り組みは、チームが善意で強いスタートを切っても抵抗に直面します。

リスクを軽減するには、バックログにセキュリティ タスクを追加します。 このプラクティスにより、チーム内のアカウンタビリティが確保され、開発タスクと共に進行状況を追跡できるようになります。

ツールとプロセスを透過的にし、監査とピア レビューを通じて脆弱性を簡単に検出できるようにします。 脆弱性スキャンとセキュリティ制御をサポートする業界標準のツールを、まだ完全に実装していない場合でも確認します。

さまざまな ID コントロール プレーンを最小限に抑えるために、ツールとデプロイのプラクティスで運用環境と同じ ID プロバイダーが使用されていることを確認します。

基本プロセスを標準化します。このアプローチにより、意思決定の責任が合理化され、システムの展開と監視の要件が定義されます。

レベル 2 では、チームはより構造化されたアプローチを採用し、開発アクティビティをワークロードのコア機能に集中させる必要があります。 一貫性を早期に確立することで、後の段階で運用上の負担を最小限に抑えることができます。

主な戦略

✓ チームの役割と意思決定の責任を定義する

製品の考え方を採用する。 ワークロードをツール、テクノロジ、またはジョブ機能の統合として見るのではなく、最終的な目標に明確に焦点を当てたまとまりのある製品として扱います。 レベル 2 では、各ロールが明確に定義され、尊重される、より構造化されたアプローチを適用します。

チーム内の専門知識は、多くの場合、異なります。 この多様性は、さまざまな職務間で意思決定を分散するのに役立ちます。 たとえば、特定のチーム メンバーは技術的な決定を行うのに優れていますが、他のチーム メンバーは、エコシステムで競争力を維持するためにビジネス成果を定義する専門家である可能性があります。

リスク： 一部のワークロード チームはコンセンサス主導のカルチャを採用し、全員が同意した場合にのみタスクにコミットします。 この文化は包摂性を促進しますが、完全なコンセンサスが達成されないとイニシアチブを妨げることがよくあります。

次の原則を使用して、適切に構造化された意思決定プロセスを確保します。

• 意思決定がチーム メンバー間で分散され、1 人のユーザーと一元化されるのではなく、専門知識の領域と一致するように、直接責任を持つ個人を指定します。

  意思決定者を文書化し、この情報を新入社員のオンボーディング資料に含めます。

• 特定の役割と責任を明確に定義する意思決定手法を採用することを検討してください。 これらのアプローチは、部門を作成し、製品の目標からフォーカスをシフトできることに注意してください。 チェックとバランスを確立して、サイロ化された意思決定を防ぎ、摩擦を軽減します。

✓ どんなに小さくても改善に努める

継続的な改善の考え方を育てることは、今日、彼らが明日洗練されることを理解して意思決定を行うことを意味します。

変更を遅らせると、チームは現在の改善の機会を逃す可能性があります。 考え過ぎや優柔不断は避けてください。 完璧なソリューションを追求すると、小さいながら意味のある進歩が妨げられる可能性があります。 改善の方法を継続的に追求しながら、今すぐ改善することに重点を置く。

技術的負債は、短期的な意思決定をキャプチャするための開発における戦略的ツールです。 増分更新の動機として機能し、不要な蓄積を防ぐことができます。 技術的負債をバックログの定期的なタスクとして扱います。

✓ 基本プロセスの標準化

ワークロードのさまざまなクラスには、固有の特性に合わせて調整された独自のプロセス要件があります。 たとえば、AI ワークロードは、機械学習操作と生成型 AI 操作に依存して、データ パイプラインをモデルに駆動します。 ミッション クリティカルなワークロードは、サイトの信頼性エンジニアが迅速に操作できるリアルタイム監視ダッシュボードに優先順位を付けます。

ワークロード クラス内では、一貫性を強化し、運用上の負担を軽減するための標準化に努めます。 判別モデルと生成モデルの両方を含む AI ワークロードの場合は、データ操作に関するプロセスを標準化します。 これらの操作には、モデルまたは地上生成 AI モデルのトレーニングに使用される前のデータ アクセス、クレンジング、変換が含まれます。

次のユース ケースでは、標準化をお勧めします。

リスク： 継続的な改善とイノベーションは、多くの場合、チームが確立された標準から若干逸脱して、より良いアプローチを探るときに発生します。 これらの偏差は推奨されますが、構造化されている必要があります。 たとえば、イノベーションの日をホストすることで、チームは事前に選択された改善プロジェクトに集中でき、新しいアイデアや実験が促進されます。

✓カスタムツールを構築する代わりにツールを購入

標準化されたプロセスには、効果的な実装に必要なツールが含まれます。 このレベルでは、カスタムビルドのソリューションではなく、既製のソリューションに優先順位を付けます。このソリューションは、後で特殊なユース ケースについて再検討できます。

ワークロード用の日常的なツールには、開発、テスト、監視、デプロイ のツールが含まれます。 購入したツールはワークフローを合理化し、一貫性を確保します。 この一貫性により、チームはカスタム ソリューションの開発と保守の複雑さなしで機能の提供に集中できます。

リスク： ツールを検討する場合、多くの場合、ツールの機能拡張と将来の可能性を、そのコア機能ではなく過大評価する傾向があります。 この段階では、実用的で、現在の問題に対処し、現在のワークフローに適合するツールに焦点を当てます。

✓ ワークロード全体で自動化を採用する

新規または既存のワークロードを開発するときは、自動化を統合する機会を求めます。 最初から自動化を念頭に置いて新しいワークロードを設計すると、将来の導入がシームレスになります。 同様に、既存のワークロード ( ブラウンフィールド ワークロード) に自動化を組み込むことで、ライフサイクルの早い段階で効率を高め、一貫性を維持することができます。

導入を効率化するには、ソリューションをゼロから構築するのではなく、クラウド プラットフォームと互換性のある成熟した使い慣れた既製ツールを使用します。 クラウド プロバイダーのネイティブ自動化ツールを調べて、設計を簡略化します。 たとえば、多くの Azure サービスでは、ディザスター リカバリーのパフォーマンスとフェールオーバーの機能に対する自動スケールがサポートされています。 Microsoft 以外のツールを評価する場合は、チームの専門知識と関連するビジネス標準を考慮します。

自動化の利点は次のとおりです。

• 監視やアラート、更新管理などの日常的な運用タスク

• 展開やテストなどのソフトウェア開発ライフサイクル タスク

• リソースのスケーリングなどのワークロード パフォーマンスの最適化

• スキャンやポリシーの適用など、セキュリティとガバナンスのメカニズム

• バックアップと回復のアクティビティ

• リソースの割り当て解除やシャットダウンなどのコストの最適化

リスク： ワークロード開発の初期段階では、ワークロードの提供から運用環境への注意を転用する可能性があるため、自動化の構築または統合に重点を置きすぎないように注意してください。 開発速度を維持しながらワークロードを管理できるように、測定されたアプローチを取ります。

トレードオフ： 人間が頻繁に、効率的に安全にタスクを実行できる場合は、自動化する価値がない可能性があります。 たとえば、証明書の年次更新を自動化しても、開発サイクルの投資が正当化されない場合があります。

✓ コードとしてのインフラストラクチャエクスペリエンスを拡張してインフラストラクチャを構成し、アプリケーションを管理する

レベル 1 では、アプリケーション コード用のインフラストラクチャとパイプラインをデプロイするために、コードとしてのインフラストラクチャ (IaC) ツールを採用することに重点を置きます。 レベル 2 では、そのプラクティスを拡張して、デプロイされたインフラストラクチャとアプリケーションの構成と管理を含めます。

目的の状態構成アプローチを使用して、リソースをブートストラップし、構成の誤差を回避します。 タスクやプラットフォームが異なると、さまざまな自動化ツールが必要になります。 たとえば、Ansible は仮想マシン (VM) の望ましい状態構成を管理するのに適していますが、Flux などの GitOps ソリューションは Kubernetes クラスターに適しています。

デプロイ後のタスクに適したレベルの自動化を決定し、設計をシンプルにしながら運用上の負担を最小限に抑えます。 証明書のインストール、OS 構成、データベースのシード処理などのタスクはすべて、自動化に適したオプションです。 また、新しくデプロイされた VM またはコンテナー ホストでのアプリのデプロイと構成を含むように自動化を拡張することを検討してください。

リスク： 不要なツールの無秩序な拡大を避けます。 異なるアプローチとテクノロジを使用する開発者または開発チームは、ツール エコシステムが破壊される可能性があります。 要件を満たすワークロードの選択された数のツールを標準化し、ワークロード チームがそれらのツールでトレーニングされていることを確認します。 ツールに関する組織標準の採用には慎重になってください。 ワークロードに過度のリスクを追加するツールを組織が提案している場合は、より適切な代替ツールを評価します。

✓ ワークロードのデプロイ戦略を定義する

デプロイ戦略は、オペレーショナル エクセレンスの重要なコンポーネントです。 適切に設計されたデプロイ戦略により、更新または変更中のダウンタイムを削減または排除することで、ユーザーがサービスを引き続き利用できるようになります。 変更を運用環境にデプロイする方法とタイミングについて、利害関係者から合意を得る。 次の点を考慮してください。

• 許容されるダウンタイムを定義します。 重大な問題や財務上の損失を引き起こすことなく、ワークロードがダウンタイムをサポートできるかどうかを判断します。 ダウンタイムゼロが定期的なデプロイの要件であるかどうかを明確に指定します。

• デプロイの頻度を確立します。 機能開発に基づいてデプロイの頻度を決定します。 スケジュールは毎日、毎週、四半期ごと、または他の適切な方法で決定します。 可能な場合は、シナリオに合わせて、より小規模で頻繁なデプロイに優先順位を付けます。

• 緊急展開を計画する。 セキュリティ修正プログラムなど、緊急展開を管理する手順を実装するための計画を策定します。 このアプローチにより、チーム メンバーは自分の責任を理解し、必要に応じて迅速に行動できます。

エラーを最小限に抑え、一貫性を確保するために自動化できる反復可能なデプロイ システムを設計します。 前回のデプロイでエラーが発生した場合にシステムを機能状態に復元するためのロールバックのプロビジョニングを含めます。

✓ ワークロード監視スタックを設計する

監視システムを設計するには、監視する対象を選択し、ユーザーに対するこれらのメトリックの重要性を理解する必要があります。

まず、ワークロード内のすべてのコンポーネントからログとメトリックを収集します。 プラットフォームが提供する監視ツールを利用します。 これらのツールはサービスと統合され、機能と運用に関する分析情報を少ない構成で提供します。 このデータは、分析のために照会できる信頼できるストレージ ソリューションに安全に格納します。

リスク： ノイズが発生し、コストが増加する可能性があるため、過剰なデータを収集しないようにします。 まず、CPU、メモリ使用量、ストレージ使用量などの基本的なメトリックから始めます。 時間の経過に伴う便利なアプリケーションの正常性メトリックを追加します。

最初の分析に基づいて、利害関係者と協力して、ワークロードの正常な状態と異常な状態の両方の意味を定義します。 この情報は、その正常性状態を正確に反映する正常性モデルを開発するために、後の段階で使用します。

リスク： 監視パイプラインは、チャージバック、トランザクション サービス レベル アグリーメント、容量保証、売上合計など、ビジネス メトリックを収集するためのツールとして機能します。 ワークロードの正常性メトリックとビジネス メトリックを明確に区別します。

監視構成ではなく、アプリケーション機能としてビジネス メトリックを収集します。 監視データ ストリームはサンプリングでき、通常は障害発生時に復旧できません。 ビジネス クリティカルなデータをワークロード データとして扱い、ワークロードの正常性シグナルとは別に保ちます。

ダウンタイムが発生する可能性があるデプロイ エラーのリスクを軽減します。ダウンタイムが発生した場合は、サイトの信頼性エンジニアが分析のためにメトリックの収集に時間を無駄にすることなく、重大な問題に集中できることを確認します。

以前のレベルでは、ソフトウェア開発ライフサイクルを標準化し、展開方法、テスト、テレメトリ収集に関する重要な決定を行います。

レベル 3 では、運用を成熟させ、デプロイの信頼性を高める必要があります。 テストは、安全で安定したデプロイを確保するための稼働状態の要件になります。 デプロイ プロセスも進化し、自動化されたパイプラインを採用してワークロードを構築し、運用環境にデプロイします。 リスクの爆発半径を最小限に抑えるために、基本的なリソースとアプリケーション コードの間で適切なセグメント化が維持されます。

監視のプラクティスも成熟しています。 監視システムは、運用上の知識を実用的な分析情報に変える正常性モデルを実装するように拡張されています。 アラートはビジネス コンテキストに合わせて合理化されるため、無関係なアラートでは誤ったアラームが発生せず、監視システムに不信感が生じません。

主な戦略

✓ リリースを促進するために個別の環境を使用する

このレベルでは、公開前に正式な変更制御プロトコルとして リリースプロモーション を確立することが重要です。 このプロセスは、品質ゲートを使用してさまざまな段階を通じて提案された変更を進行します。 各ステージは徹底的なテストを受け、変更はこれらのチェックに合格して承認を受けた場合にのみ進みます。

開発/テスト、品質保証、ユーザー受け入れテスト (UAT)、運用環境など、さまざまなステージに個別の環境を作成します。 この方法により、次のステージに進む前に検証が徹底されます。 この考え方は、爆発半径を最小限に抑えるためにエラーを早期にキャッチする必要があるため、より低い環境でリスクを管理することです。

✓ 十分なテストを実行する

このレベルでは、システムの重要な部分に対してテストが優先される戦略を決定します。 堅牢なテスト戦略を確保するには、次の手順を使用します。

• テスト ケースを定義します。 アプリケーション コード、インフラストラクチャ テンプレート、および構成のテスト ケースを作成します。

• さまざまな種類のテストを実施します。 環境ごとに異なる種類のテストを実行します。 リスクの低い環境でリスクの高い変更のテストを開始します。 信頼度が高まるにつれて、リスクの高い変更をリスクの高い環境に徐々に移行します。

• 個別のテスト環境を設定します。 さまざまなテスト アクティビティ用に個別の環境を作成します。 たとえば、UI テストを行う場合は、開発環境と運用環境の両方とは別の専用環境を作成します。

理想的には、開発環境とテスト環境を運用環境とできるだけ似た状態に保ちます。 サンプルのみの場合でも、テスト データが運用環境のデータと密接に一致することを確認します。 リソースも同等である必要があります。 たとえば、数 MB のデータを含む小規模なテスト データベースで十分な場合もありますが、実際のパフォーマンスを評価するには、数テラバイトのほぼ実稼働サイズのデータベースを使用して機能を検証することが不可欠です。

トレードオフ： これらの環境を近くに保つことは重要ですが、考慮すべきトレードオフがあります。 運用環境のフル スケールを開発中にデプロイすることはできません。

運用環境との近接性と、コスト効率の高い非運用環境とのバランスを見つけます。 たとえば、一時的な開発/テスト環境を作成することを検討してください。この環境は、テストに合格した後に取り壊されます。

テスト ケースに従って環境のサイズを設定します。 単体テストでは、小規模なセットアップで一致するライブラリと OS のバージョンのみが必要になる場合があります。 回復性テストでは、同じサービス SKU を持つ実稼働前環境が必要になる場合があります。 パフォーマンス テストでは、運用環境規模のデプロイが必要になる場合があります。

✓可能な限りテストやその他の品質チェックを自動化する

自動化は、一貫性を確保し、予期しない構成変更をすばやく見つけるのに適しています。 自動テストを通じて確認できる変更を決定します。 たとえば、セキュリティ スキャンは、開発環境に移行する際の自動化に最適です。 すべてのテストを自動化する必要はありません。また、一部のテストを自動化することはできません。 たとえば、UAT では、実装をユーザーの期待と比較し、承認を得る必要があります。

自動テストを調整するための Azure Load Testing や Azure Pipelines など、さまざまな種類のテストを自動化および合理化するためのさまざまなテスト ツールを使用できます。

✓ 承認プロセスを設定する

デプロイが異なる環境を移動する場合は、テストプロセスと承認プロセスを使用して変更を検証することが重要です。 この検証は成熟し、時間の経過と伴ってより厳格になる必要があります。 たとえば、開発者ワークステーションから共有開発環境に移行する場合、通常は基本的なセキュリティ スキャンとピア レビューで十分です。 しかし、後で、ビジネス利害関係者を含める必要がある場合があります。 構造化された効率的なデプロイ プロセスを確保するには、次のガイドラインを考慮してください。

• 定期的なリリースの承認: 通常のリリースに関しては、ステージングから運用環境への移行には、異なる一連の条件が必要です。 運用環境への移行などのリリースに関する決定には、利害関係者からの承認、明確なドキュメント、またはその両方が必要です。 ワークロード チームは、承認プロセスの一部であるユーザーとその責任を定義する必要があります。 規制の場合によっては、監査者が意思決定プロセスに含まれることもあります。 レベル 2 でこれらの役割と責任を確立します。

• 修正プログラムの別のプロセスがあります。 セキュリティ パッチのデプロイなどの重大な状況では、即興展開プロセスが必要になる場合があります。 緊急プロセスを作成して、これらの優先度の高い修正プログラムを高速化します。 このプロセスには、主要な利害関係者と技術メンバーからの承認のみが含まれる場合があります。 または、一部の承認をバイパスするパイプラインを開発して、デプロイを迅速に行うことができます。

  スキップする手順を決定するときは、ビジネスまたは顧客に対するリスクを考慮してください。 高い投資とリスクの低いテストは緊急時にはスキップできますが、高リスクと低投資のテストは常に実行する必要があります。 直接責任ある個人 (DRI) は、主要な利害関係者や技術的な意思決定者からの意見を得て最終的な意思決定を行う必要があります。

✓ 自動デプロイを実装する

予想される変化率に基づいて、異なるレイヤーに対して個別のデプロイ サイクルを維持します。 場合によっては、相互依存関係とダウンタイムの要件によっては、サイクルの組み合わせが必要になる場合があります。 ただし、ほとんどの場合、最小限の特権で各レイヤーを個別に管理することで、細分性を追求します。 1 つのレイヤーの変更が他のレイヤーに影響しないようにします。

たとえば、ネットワーク インフラストラクチャの変更の頻度は、アプリケーション コードの変更よりも少なくなります。 これらの変更は、品質管理による合理化されたプロセスによって個別に管理します。 プロセスを作成するには、ワークロード レイヤーに合わせて配置パイプラインを構築します。 運用環境にデプロイする前に、制御された環境でコードとしてのインフラストラクチャ資産に対してテストを実行します。

✓ 健康モデルの開発

基本的な監視システムを用意したら、ビジネス コンテキストと監視データを組み合わせて、ワークロード コンポーネントの全体的な正常性状態と全体的な状態を定量化します。 この演習は 、正常性モデリングと呼ばれ、ビジネス コンテキストを使用してインフラストラクチャとアプリケーションからの監視値をコンテキスト化することを含みます。 効果的な正常性モデルを構築するには、次の重要な原則を検討してください。

• システムが監視するデータ コンテキストを指定します。 しきい値の設定は、正常性モデリングの重要な部分です。 しきい値がワークロードにとって意味のあるものになるように、コンテキストを使用して数値を指定します。 たとえば、70% から 90% の CPU 使用率が高い場合、一般的に 1 つのワークロードで 異常 な状態を示している場合は、使用可能なリソースを効率的に使用する別のワークロードでは 正常 である可能性があります。

• 変更に関するアラート。 これらの値の変化は健康状態の変化を示しており、DRIsからの対応を促す必要があります。 そのため、アラートは正常性モデリングのもう 1 つのコア コンポーネントです。 標準メトリックを有効にして、すべてのアラートをサポート センターに送信することは避けてください。 代わりに、健康モデルの変更に基づいてアラートを発します。 アラートに含まれる情報は、調査または是正措置を必要とする特定の問題について適切なチームに通知する、意味のある実用的な情報である必要があります。

• あなたの健康モデルを視覚化します。 監視プラットフォームの視覚化ツールを使用して、ワークロードの正常性シグナルをさまざまな利害関係者と簡単に共有できます。 一部の利害関係者は、アプリケーションの可用性など、特定の統計情報を必要とする場合があります。 また、運用チームは、すべての正常性シグナルにアクセスする必要があります。 異なるダッシュボードを設定すると、各チームに必要な情報を提供するのに役立ちます。

時間の経過とともに、ワークロードの正常性に関する履歴の傾向を追跡し、分析する戦略を策定します。

✓ インシデント管理プロセスを設定する

ワークロードが運用環境にある場合は、プラットフォームの停止、データの破損などのインシデントに対処するのが普通です。 重要なのは、ワークロードに設定したターゲット内でこれらのインシデントを効果的に処理することです。 そのため、運用環境に移行する前に、インシデント管理の最初のステップとして構造化されたサポート 計画を用意します。

• 通話中のユーザー、その職務、およびオンコール担当者間のハンドオフの管理方法を定義して、サポート操作を正式化します。 理想的には、通話中のローテーションにギャップがあってはなってはいけません。また、誰もがインシデントをいつでも処理する責任を誰もが知っているはずです。

• インシデントの種類ごとに、明確に定義されたプレイブックまたは対応プロセスがあることを確認します。 たとえば、エラー モード分析 (FMA) またはセキュリティ ベースラインの結果を使用できます。

• 正常性モデルを使用して、インシデント管理の準備に関する基本的なテストを実行します。オペレーターは、シミュレートされた問題の影響を監視しますが、開発者が通話中に問題のトラブルシューティングを行う必要がある場合があります。

: システムがユーザーに約束されている品質基準を満たし、サービス レベルアグリーメントの違反を防ぎます。

以前のレベルでは、ワークロード チームは機能の構築とシステムの運用環境への移行に重点を置いています。 このレベルでは、機能の構築からライブ システムの維持と改善に焦点が移ります。 実際のユーザーがそれに依存するようになったため、優先順位は、トリアージ、メンテナンス、アップグレード、トラブルシューティングなどの 2 日目の効率的な操作によって変更管理になります。

主な戦略は、実際のエクスペリエンスを使用して運用を改善することです。 また、テストは、変更に関連するリスクを軽減するための交渉不可能なプラクティスでもあります。 バグの修正から機能の追加、インシデント対応の改善まで、開発のあらゆる部分にテストを統合する必要があります。 それがなければ、深刻な問題は運用環境に到達するまで検出されない可能性があります。

このレベルでは、技術的負債が本当の懸念事項になります。 理想的ではない実装は稼働する可能性があり、メンテナンスが複雑になる可能性があります。 チームは、メンテナンスの負担を分析し、それを減らすことに重点を置く必要があります。

主な戦略

✓ 安全な展開方法を使用する

運用環境の後、通常、3 つの主要な種類の変更には、定期的な更新プログラム、新機能の更新プログラム、緊急更新プログラムが含まれます。 安全な展開プラクティスを使用して、これらの変更中にシステムを安定した状態に保ちます。 変更の種類に関係なく、すべての変更をワークロードのユーザーの潜在的な障害点として扱います。

次の戦略を変更管理プロセスに統合します。

• 継続的かつ包括的に検証します。 開発ライフサイクル全体を通して、またさまざまな環境で変化が進むにつれて、早い段階で頻繁にテストします。 アーティファクトが変更されるたびに、それらの変更に重点を置いたテストを作成するのが理想的です。 その後、完全なテスト スイートを実行して、フローをエンドツーエンドで検証します。 テスト結果は検証データを提供しますが、ビジネス関係者は引き続きこれらの変更を承認する必要があります。

  トレードオフ： テスト スイート全体を実行すると、デプロイの信頼性が高くなります。 ただし、時間とコストが原因で、すべての変更に対して実用的でない場合があります。 徹底的なテストとコストに関する考慮事項のバランスを取る。 変更の影響に基づいて承認プロセスを調整します。 軽微な変更には簡単な手順が必要ですが、新機能などの大幅な変更には徹底的なレビューが必要です。

  このレベルでは、リージョンフェールオーバーなどの高度な運用概念を採用できます。 目標は、ほとんどのシナリオで自己復旧に焦点を当てて、これらのプロセスを完全に自動化することです。 これらのプロセスも広範囲にテストする必要があります。

• API のバージョン管理を実装します。 下位互換性を確保するために、データ モデルの変更を慎重に管理します。 API のバージョン管理戦略は、変更がデプロイされた後も既存のシステムがスムーズに動作し続けるのに役立ちます。 振り返りバージョン管理は困難な場合があるため、早い段階で戦略を立てることもできます。

• 増分更新を展開します。 レベル 3 では、デプロイ プロセスは、すべての環境で自動化されたパイプラインを使用して標準化されます。 レベル 4 の成熟度で、ワークロードは運用中です。 リリース サイクルの管理など、増分更新の調整に焦点が移ります。

  小規模で頻繁な更新プログラムをデプロイして、小規模な変更セットの検証を簡略化します。 ロード テスト、テスト環境へのデプロイ、A/B テストなどの検証タスクを自動化します。

  注

  カナリアデプロイやブルーグリーンデプロイなどの安全なデプロイパターンは、サイドバイサイドデプロイを通じて柔軟性と信頼性を提供します。 たとえば、ブルーグリーンデプロイでは、新しい環境が構築され、トラフィックがシフトされ、古い環境は使用停止になります。 その他のデプロイ手法には、機能フラグやダーク 起動が含まれます。 これらの方法を使用すると、すべてのユーザーに変更がロールアウトされる前に運用環境でテストできます。 この機能は、デプロイ スロット間で段階的にスワップすることで更新プログラムをロールアウトできる、Azure App Service などの特定の Azure サービスで使用できます。

• デプロイ エラーから復旧します。 一部の更新が失敗することが予想されます。 問題が発生した場合、増分更新によりトラブルシューティングが迅速化します。 障害が発生した場合は、システムを停止してさらなる損傷を防ぎ、変更を実装して問題を解決します。 バックアップからの復元は、継続性が維持される場合に許容されます。 目標は、ロールバック プロシージャだけに依存するのではなく、安定したバージョンに移行することです。

✓ ビルド操作を最適化する

レベル 3 では、アーキテクチャのレイヤーごとに、変更率に基づいて個別のデプロイ サイクルが必要です。 少なくとも、インフラストラクチャとコード パイプラインを維持します。

ワークロードが運用環境に入ったので、階層化アプローチを見直します。 可能であれば、アーキテクチャ コンポーネントをさらに分離して、より柔軟なリリース周期を実現します。 この方法では、遅延を減らし、個々のコンポーネントの障害を最小限に抑えます。 また、テストと実行時間の長いプロセスを並列ジョブとして実行して、時間を節約し、開発者の生産性を向上させます。

✓ インシデント対応プロセスを検証する

レベル 3 では、プレイブックを使用してオンコール サポート システムを確立し、インシデントへの対応を定義します。 ただし、プレイブックを持つことは最初のステップにすぎません。 ワークロードが運用環境になったので、インシデント管理プロセスの有効性を検証して強化し、堅牢なコミュニケーション計画を策定する必要があります。 次のプラクティスを検討してください。

• インシデントへの対応をテストします。 テクノロジ、人、プロセスからの応答を組み込みます。 検証作業に現実性を導入するには、ゲームデーを実施することをお勧めします。 ゲームデーは、問題を検出して解決するチームの能力をテストするために障害が導入される計画イベントです。 このアプローチにより、チームは適切なツール、リソース、手順を確実に配置できます。 カオス エンジニアリングは、制御された中断を導入して結果を観察するもう 1 つの貴重な手法です。 または、グローバル ロード バランサーでバックエンドを無効にしたり、データベース フェールオーバーを実行したりするなどの手動の方法を使用して、応答をテストすることもできます。

• コミュニケーション計画を立てる。 ワークロード チーム、サポート チーム、緊急対応担当者全体のコミュニケーション責任を明確に定義します。 ビジネス利害関係者に対する内部状態の更新の頻度と形式を標準化することで、透明性と信頼が促進されます。 セキュリティ侵害などの特定のシナリオでは、エンド ユーザーへの責任ある開示が必要です。 これらの外部通信では、適切な種類とレベルの情報が明確に定義されていることを確認します。

• インシデント レビューを実施します。 すべてのインシデントを運用環境から学ぶ機会として扱います。 このプロセスを使用して、デプロイと開発プロセスの弱点を特定し、システムの改善にコミットします。

✓ 運用環境の監視データを使用して運用を最適化する

レベル 4 では、高度な監視は、ビジネス コンテキスト内でメトリックを出力、関連付け、分析する必要があります。 このレベルでは、運用環境から学習することで精度を向上させます。 監視データを使用して、最適な推測に基づいて構築されたプロセスを調整します。 次の主な例を考えてみましょう。

• レベル 3 の主な焦点は、ワークロードの正常性モデルの開発です。 レベル 4 では、アラート システムを微調整し、現実的な目標とサービス レベルのインジケーターを設定します。

• 2 日目の操作の一環として、構成の誤差を最小限に抑えることが重要な優先順位である必要があります。 このフォーカスがないと、ランタイム環境は意図した状態から徐々に分岐する可能性があります。 まず、既知の適切な構成のスナップショットをキャプチャします。 次に、運用環境の可観測性メトリックを利用して、現在の動作をそのベースラインと比較します。 このアプローチにより、意図したシステム状態との継続的な整合が保証されます。

• このレベルは、フィードバック ループを導入して、システムが特定のストレス要因の下でどのように動作するかを理解し、新機能の影響を予測するのに最適です。 システム テレメトリは、ワークロードの変化を予測し、潜在的な問題に対するプロアクティブなソリューションを形成するのに役立つ重要な分析情報を提供することで、これらのフィードバック ループをガイドします。 このデータを使用して、技術的負債の優先順位付けを行うこともできます。

一般的なプラクティスとして、運用環境の監視データとパターンに基づいて監視スタックを微調整します。 次のプラクティスを検討してください。

• 重要なパスのアクティビティをキャプチャするために、可視性とノイズのバランスを取るためにログ記録レベルを調整します。

• 無関係なアラートを抑制しながら、重要なアラートを増幅します。

✓ メンテナンスの自動化

レベル 3 では、自動化の取り組みは主に運用環境へのデプロイに重点を置きます。 レベル 4 では、チームは継続的インテグレーションと継続的デリバリー パイプラインを使用してビルド、テスト、デプロイのプロセスを自動化することで、手動作業を大幅に削減しました。 品質ゲートと同様に、特定の承認も自動化されたワークフローを通じて管理される場合があります。

レベル 4 では、運用の自動化は実際の運用エクスペリエンスによって推進され、技術的負債への対処に重点を置く必要があります。

次の day-2 自動化の例を考えてみましょう。

主な目標は、期限のために以前の段階で見落とされていた可能性のある反復的な人間主導のタスクを特定することです。 しかし、すべてを自動化するべきではありません。 投資収益率は自動化を導く必要があります。 まったく新しいツールから始めるのではなく、既存のテクノロジと知識を使用することをお勧めします。 軽量工具が必要な場合は、そのライフサイクルとメンテナンス要件を評価します。

✓ ツールとプロセスを組織の基準に合わせて調整することで効率を向上させる

レベル 4 の成熟度では、エンジニアリングの資産とプロセスを評価して運用効率を上げます。 どの資産が重要で、ビジネスの中核ではないかを特定します。

これらの資産については、次の点を考慮してください。

• 組織内で既に利用可能な共有ツールを使用します。

• データ変換などの特定のタスクについては、Microsoft 以外のソフトウェアを検討してください。

事前構築済みの資産にはサポート チャネルが付属しており、カスタム ソリューションを置き換えることができます。 このアプローチにより、チームが作成したソリューションの運用上の負担が軽減されます。 これらのリソースがニーズをどの程度満たしているかを評価し、残りのギャップを特定します。

ワークロードの次の領域を確認します。

• カスタム コードを評価します。 解析などのタスクのカスタム コードを記述する代わりに、業界標準と見なされるオープン ソース ソリューションを評価します。 これらのツールを使用すると、コードのメンテナンスの必要性が減り、コード ベースが小さくなります。 組織内で既に使用可能なオプションを確認します。 認証などの日常的なタスクを処理するためにワークロードに統合できる既存のライブラリが存在する可能性があります。

• ツール チェーンを評価します。 同様のツールを使用する他のチームに依存できる領域を評価します。 それに応じて、ライブラリ、テンプレート、およびモジュールの使用を調整します。 組織全体にコードとしてのインフラストラクチャ ツールを配置して、運用を効率化します。

• プロセスを評価します。 セキュリティ スキャンなど、自分で実装した可能性のあるタスクを実行できる一元化されたプロセスを特定します。 NuGet パッケージの独自の検疫プロセスを管理する代わりに、ワークロードで使用されているモジュールを通知することで、組織の既存のセキュリティ チームのプロセスを使用します。

  サポート可能性はもう 1 つの重要な領域です。 初期の段階では、多くの場合、開発チームはメトリックを監視し、ライブの問題を修正することで、自身のサポートを処理します。 この段階では、オンコール エンジニアなどの専用ロールを設定することを検討してください。 組織に共有サポート チームがある場合は、それを使用して開発者のサポート負荷を軽減します。

  注

  可能であれば、日常のサポートを外部ベンダーに移行します。 ベンダーは、開発チームやワークロードを運用環境に移行するアーキテクトのような深いコンテキストを持っていません。 仕入先にタスクを渡す前に、システムが運用環境で安定していることを確認し、管理タスクを明確に定義します。 ベンダーが成功するには、重要な要素が必要です。 正常性モデルで、 正常、 異常、および 低下状態 を表すしきい値を定義します。 プレイブック、ツール、その他のトラブルシューティング リソースについてベンダーをトレーニングします。 原因を特定できない場合は、問題をエスカレートしてワークロード チームにルーティングするための明確に定義された経路を設定します。

✓ 定期的に技術的負債を管理する

技術的負債は、開発時に期限を満たすために実行するショートカットの結果であり、実装が理想的ではない可能性があります。 チームは、メンテナンスの複雑さと時間を分析することで、この負債の削減に取り組む必要があります。 技術的負債に対処しないと、システムがより複雑になり、保守やスケーリングが困難になる可能性があります。 この複雑さは、開発者が新しい機能に取り組む代わりに問題の修正に多くの時間を費やすので、イノベーションが遅くなります。

技術的負債を処理するための次の戦術的な推奨事項を検討してください。

• 機能の作業に併せて技術的負債を追跡します。

• すべてのスプリントで、機能開発とは別に技術的負債に対処するためのリソースを確保します。 場合によっては、スプリント全体を技術的負債への対処に専念します。

• 新機能に対して新しい技術的負債が発生する予定の場合は、提案された解決策をすぐにバックログに追加します。

技術的負債は、開発の通常の部分であり、改善の機会です。 新機能が追加されると、負債が蓄積されます。 既存の技術的負債を返済する努力と、新機能の開発による新たな技術的負債の管理とのバランスを取ります。

改善と適応を続けますが、完了したとは決して想定しないでください。

レベル 1 からレベル 4 に進むにつれて、Azure で適切に設計されたワークロードを確立します。 設計では、運用用にシステムを準備する監視、テスト、デプロイ、自動化などの運用プラクティスを設定します。 システムが運用環境に入った後は、ユーザー エクスペリエンスを保護するために、運用の安定化と変更の管理に重点を置きます。

最後の段階での成熟度とは、ワークロードを大規模に運用し、信頼性と最新の状態を維持することです。 また、現在の設計が限界に達している領域を特定し、ビジネス要件の変更に備える能力も必要です。 制約に関する前提は、エコシステムの進化に伴って古くなる可能性があります。 環境、プラクティス、およびツールは進化し続けているため、静的な場合は回帰が発生する可能性があります。 レベル5のアプローチに投資しないと、ワークロードが遅れるリスクがあります。

レベル 5 は、最終的な目標でも技術的なチェックポイントでもない。 文化、プロセス、ツール、テクノロジの最新化に重点を置いた考え方の転換です。 運用は、ワークロードのアプリケーションが受け取るのと同じ厳密さ、投資、イノベーションで処理されます。

主な戦略

✓観察された成長と将来の可能性に基づいてアーキテクチャの再構築のチャンスを見つける

ワークロード アーキテクチャは、制約を使用して意図的に設計されており、有効期間が限られています。 レベル 4 を通じて、アーキテクチャはビジネス要件を効果的に満たしている可能性があります。 このレベルでは、システムが新しい使用パターン、テクノロジ、成長、運用上の課題をどのように処理するかを評価します。

たとえば、何千人ものユーザーに対して機能するソリューションは、数万人にスケーリングすると失敗する可能性があります。 データ量の増加によって原子性の問題が発生する可能性があります。一方、パフォーマンスとコンプライアンスに対する要求が増える一方で、アーキテクチャをその限界まで押し上げることができます。 これらの圧力により、新機能の提供を防ぎ、スケーリングのボトルネックを生み出すことができます。

このレベルでは、チップポイントを認識し、 再設計が必要な領域を特定します。 次の領域について考えてみましょう。

• ツール、フレームワーク、プラットフォーム サービスの最初の選択は、ビジネス ニーズに適している可能性があります。 ただし、システムの進化に伴い、これらのツールは堅牢または密に結合され、ライブラリの拡張性が不足し、プラットフォーム サービスが終了し、既存の依存関係が破損する可能性があります。

  強力なサポートと広範なコミュニティ導入を提供する広範なエコシステム内のツールとサービスについて説明します。 交換やアップグレードを容易にするために、モジュール式の疎結合アーキテクチャを選択します。

• 以前のレベルでは、ワークロード チームが 技術スタック全体を管理する場合があります。 このアプローチは最初は有効ですが、システムのスケーリングに伴って圧力と運用オーバーヘッドが増加することがよくあります。 この負担を軽減するには、ネットワーク、セキュリティ、監視に重点を置くチームなど、専門チームに責任をオフロードすることを検討してください。 その専門知識により、コア ワークロード チームは製品価値の提供に専念できます。

• 顧客専用 (またはシングルテナント) インスタンスを管理すると、コストと運用上のオーバーヘッドの両方が増加する可能性があります。 多くの場合、この課題はマルチテナント アーキテクチャを採用する必要性を示しています。 この移行には、テナントのオンボードやデータ アクセスの分離の処理など、より広範なアーキテクチャと運用への投資が必要です。

• デプロイ戦略を再検討して、予測可能にスケーリングし、障害の分離とパフォーマンスを大規模に処理します。 デプロイ スタンプ パターンなどの実証済みのプラクティスについて説明します。

  • スケール ユニット は、個別に監視されている間、負荷の増加を処理するために一緒にスケーリングするリソースの論理グループです。 これらのユニットは、定義されたしきい値に基づいて繰り返し可能なブロックとして自動的にデプロイされ、必要に応じてレプリケートできます。

    ただし、このアプローチにより、特定のサービスのスケーリングが過剰になり、コストが追加される可能性があります。

    詳細については、「 スケール ユニットアーキテクチャ」を参照してください。

  • 不変環境 とは、デプロイ後にシステムが変更されない展開セットアップです。 デプロイ スタンプを更新する代わりに、古いスタンプを破棄し、必要な変更を加えて再デプロイします。 このアプローチでは、ブルーグリーン デプロイなどのサイド バイ サイド デプロイ モデルが必要です。 このプラクティスを採用するには、ハイパースケールを処理したり、異常なユニットを置き換えたりするために、新しいスタンプを自動的にデプロイするパイプラインを準備する必要があります。

    レベル 4 の安全なデプロイプラクティスでは、この移行に備えて準備する必要があります。 回帰は必要なく、ユーザーは新しいスタンプにスムーズに移行する必要があります。

✓自動化を使用して摩擦をさらに減らす

レベル 4 からレベル 5 への移行は、自動化の向上だけではありません。 また、自動化を使用して摩擦を減らし、これらのタスクを実行するタイミングを決定する方法についても説明します。

次の例を考えてみましょう。

• ローカル開発者環境の自動作成: 同じ一連のツール、ライブラリ バージョン、およびその他の開発資産を使用して各開発者ワークステーションを構成することで、標準化されたエクスペリエンスを提供します。 この一貫性により、エクスペリエンス レベルに関係なく、すべての開発者が統一された環境にアクセスできるようになります。 また、コラボレーション、知識共有、オンボーディングも容易になります。 仮想化された開発環境を使用して、このプロセスを簡略化します。

• 自動アラートトリアージと解決ワークフロー: 自動化を使用して、定義済みのルールに基づいてアラートを分類および優先順位付けし、解決ワークフローをトリガーします。 優先度の高いアラートの場合、システムは関連するチームに通知し、解決プロセスを開始して応答時間を短縮できます。

• 自動インシデント修復: 問題が検出されたときにサービスを自動的に再起動したり、ワークロードを移行したりする自己復旧スクリプトを実装します。 たとえば、Web サーバーがクラッシュした場合、スクリプトはサービスを再起動したり、トラフィックをバックアップ サーバーに再ルーティングしたりしてダウンタイムを最小限に抑えることができます。

• リソースの自動使用: 他の柱の成熟度が進むにつれて、その目標をサポートするための自動化を導入する必要があります。 たとえば、重要でないリソースと環境をピーク時間外にスケジュールして、コストを削減し、リソースの使用を最適化できます。

• テナント管理の自動化: マルチテナント環境でのテナントのオンボードとオフボードを効率化します。 新しいテナントがサインアップすると、自動化でユーザー アカウントの作成、リソースのプロビジョニング、設定の構成を行うことができます。

✓ 機能や変更ごとに開発環境を作成する

Day-2 操作では、安全な変更の実装に重点を置いています。 各変更は、開発、テスト、セキュリティなどの特定の目的で設定されたさまざまな環境を通過します。 レベル 4 のガイダンスに従うことで、これらの環境の作成が自動化されていることを前提としています。

レベル 1 から 4 とは異なり、運用環境の準備状況を内部的に確認し、ワークロードの変更を管理することに重点を置いているレベル 5 は、ワークロード チームが組織全体の他のワークロードと設計、成功、失敗を共有する機会です。 負荷分散チームは、失敗を回避する方法を先人から事前に学ぶことができる場合、自ら失敗を経験する必要はありません。

✓ 知識を共有し、組織の成熟度に貢献する

レベル 1 から 4 は、内部の準備とワークロードの変更の管理に重点を置いています。 レベル 5 は、ワークロード チームが組織全体の他のチームと設計、成功、失敗を共有する機会を作るため、異なります。 同様の課題を経験した他のユーザーから学べる場合、チームは失敗を直接経験する必要はありません。

この移行には、個々のワークロード レベルのオペレーショナル エクセレンス原則から、一元化された運用に投資する組織への移行が含まれます。 これらの一元化されたチームは、ガードレール、自動化、可観測性、テストを備えた展開ツールを構築する専用のエンジニアリング グループで構成されています。

ワークロード チームは、ピア チームと効果的な手法、ツール、分析情報を共有する必要があります。 まず、ワークロードが依存するチームと連携します。 その後、ワークロードに依存するチームと接続します。 経験と成果を共有するときは、それらのチームから学びます。 共有プラットフォーム、ドキュメント、コミュニティエンゲージメントを通じて、知識共有が増えることがわかります。

✓ ワークロードのさまざまな職務に対するセルフサービス機能を有効にする

ワークロードの日常的な開発責任内で計画外のタスクが繰り返し発生する場合は、チーム メンバーが必要なときに責任を持って呼び出すことができるスクリプト ソリューションとして提供する必要があるかどうかを評価します。 計画外のタスクのセルフサービス機能を構築して維持し、チームの機敏性と自律性を高めます。

セルフサービス ソリューションとしてワークロード チームに提供するためにコスト効率の高い、時間のかかるタスクやエラーが発生しやすい計画外のタスクから始めます。 ソリューションでは、チーム メンバーの時間を最適化し、これらのタスクに一貫性を組み込む必要があります。 このアプローチにより、セルフサービス ソリューションの有効期間に対する投資収益率が得られます。

「プラットフォーム エンジニアリング体験を開始する」で説明されているアプローチと機能に従ってください。