緊急対応戦略を設計するための推奨事項

  • [アーティクル]

この Azure Well-Architected Framework のオペレーショナル エクセレンス チェックリストの推奨事項に適用されます。

OE:08 効果的な緊急業務の実践を開発する。 ワークロードがインフラストラクチャとコード全体で意味のある正常性シグナルを出力していることを確認します。 結果のデータを収集し、それを使用して、ダッシュボードとクエリを介して緊急対応を実行する実用的なアラートを生成します。 オンコール ローテーション、インシデント管理、緊急リソース アクセス、事後分析の実行など、人間の責任を明確に定義します。

このガイドでは、緊急対応戦略を設計するための推奨事項について説明します。 ワークロードのライフサイクルの過程で発生するいくつかの問題は、緊急事態を宣言するのに十分重要です。 チームが従うことができる、厳密に制御された重点的なプロセスと手順を実装して、問題が落ち着いた順序で処理されるようにすることができます。 緊急事態は自然にすべての人のストレス レベルを上げ、チームの準備が整っていない場合は混同的な環境につながる可能性があります。 ストレスと混乱を最小限に抑えるために、対応戦略を設計し、対応戦略をorganizationと共有し、定期的な緊急対応トレーニングを実行します。

主要な設計戦略

緊急対応戦略は、適切に定義されたプロセスと手順のセットである必要があります。 各プロセスと手順には、各ステップが迅速かつ安全に問題を解決するためにチームを進めるスクリプトが必要です。 緊急対応戦略を策定するには、次の概要を検討してください。

  • 前提条件
    • 監視プラットフォームを開発する
    • インシデント対応計画を作成する
  • インシデント フェーズ
    • 検出
    • Containment
    • トリアージ
  • インシデント後のフェーズ
    • 根本原因分析 (RCA)
    • 事後評価
  • 進行中のアクティビティ
    • 緊急対応訓練

次のセクションでは、これらの各フェーズに関する推奨事項を示します。

可観測性

堅牢な緊急対応戦略を立てるには、堅牢な監視プラットフォームを用意する必要があります。 監視プラットフォームには、次の特性が必要です。

  • 包括的な監視: インフラストラクチャとアプリケーションの観点からワークロードを徹底的に監視します。

  • 詳細ログ: 問題をトリアージするときに調査を支援するために、コンポーネントの詳細ログを有効にします。 ログを簡単に管理できるように構成します。 分析用に準備するために、データ シンクにログを自動的に送信します。

  • 便利なダッシュボード: organization全体の各チームに合わせて調整された正常性モデルベースのダッシュボードを作成します。 ワークロードの正常性のさまざまな側面を担当するチームが異なります。

  • アクション可能なアラート: ワークロード チームに役立つアラートを作成します。 チームからのアクションを必要としないアラートは避けてください。 この種のアラートが多すぎると、ユーザーがアラート通知を無視またはブロックする可能性があります。

  • 自動通知: 適切なチームが、アクションを必要とするアラートを自動的に受け取るようにします。 たとえば、レベル 1 のサポート チームは、すべてのアラートの通知を受け取る必要があります。一方、セキュリティ エンジニアはセキュリティ イベントのアラートのみを取得する必要があります。

詳細については、「 監視フレームワークの設計と作成に関する推奨事項」を参照してください。

インシデント対応計画

緊急対応戦略の基盤は、インシデント対応計画です。 ディザスター リカバリー計画と同様に、インシデント対応計画の役割、責任、手順を明確かつ徹底的に定義します。 このプランは、最新であることを確認する定期的なレビューの対象となる、バージョン管理されたドキュメントである必要があります。

プランで次のコンポーネントを明確に定義します。

ロール

インシデント対応マネージャーを特定します。 このユーザーは、開始から修復までのインシデントを根本原因分析に所有します。 インシデント対応マネージャーは、プロセスに従い、対応チームが作業を実行すると適切な関係者に通知されるようにします。

死後のリーダーを特定する。 この個人は、インシデントが解決された直後に事後分析が確実に実行されるようにします。 レポートが生成され、インシデントから得られる結果を適用するのに役立ちます。

プロセスと手順

ワークロード チームは、緊急基準を定義して理解する必要があります。 チームがケースが重大であると判断したら、ディザスター リカバリー計画を宣言して開始できます。 それほど深刻ではないケースでは、問題が災害の基準を満たしていない可能性があります。 ただし、緊急対応計画を開始する必要がある緊急の問題を考慮する必要があります。 緊急時には、ワークロードの内部にある問題や、ワークロードの依存関係に関する問題の結果である可能性があります。 サポート チームは、外部ユーザーによって報告された問題が、基になる問題に対する可視性がない場合でも、緊急基準を満たしているかどうかを判断できる必要があります。

コミュニケーションとエスカレーションの計画を正確に定義します。 受信するアラート通知の種類に基づいて、階層 1 のサポートが適切なチームに簡単に連絡して問題をエスカレートできることを確認します。 社内および外部の関係者に適したコミュニケーションの種類を把握していることを確認します。 コミュニケーションとエスカレーションの計画には、通話中のスケジュールとスタッフの一覧を含めます。

計画全体に、包含スクリプトとトリアージ スクリプトを含めます。 Teams は、コンテインメント機能とトリアージ機能を実行するときに、次の手順に従います。 インシデントのクローズを定義する内容の説明を含めます。

含めるその他の項目

Microsoft Teams などの内部通信や、チケット ツールやバックログ計画ツールなど、インシデントの過程でアクティビティを追跡するためにインシデント中に使用されるすべての標準ツールを文書化します。

緊急の資格情報を文書化します。それ以外の場合は 、ブレークグラス アカウントと呼ばれます。 使用方法を説明するステップ バイ ステップ ガイドを含めます。

緊急対応訓練指示を作成し、訓練がいつ行われたかの記録を保持します。

データ侵害の伝達など、必要な法的または規制上の措置を文書化します。

インシデント検出

異常を監視し、それらに対して自動的にアラートを生成する適切に設計された監視プラットフォームがある場合は、問題をすばやく検出して重大度を判断できます。 問題が緊急事態と見なされた場合は、計画を開始できます。 場合によっては、監視プラットフォームを介してサポート チームに通知されない場合があります。 お客様は、サポート チームのコミュニケーション手段を使用して、サポートする問題を報告する場合があります。 または、アカウント エグゼクティブや VP など、定期的に作業しているユーザーに手を差し伸べることがあります。 サポート チームに通知を受ける方法に関係なく、常に同じ手順に従って問題を検証し、重大度を判断する必要があります。 応答計画からの逸脱により、ストレスと混乱が増す可能性があります。

Containment

問題の修復の最初の手順は、ワークロードの残りの部分を保護するための問題を含めます。 封じ込め戦略は問題の種類によって異なりますが、通常はワークロード フロー パスから影響を受けるコンポーネントを削除する必要があります。 たとえば、リソースをシャットダウンしたり、ネットワーク ルーティング パスからリソースを削除したりすることができます。 システム管理者、エンジニア、上級開発者は協力して封じ込め戦略を設計する必要があります。 この封じ込めでは、問題の爆発半径を制限し、問題が解決されるまでワークロード機能を低下状態に維持する必要があります。 トリアージを実行するために影響を受けるコンポーネントにアクセスできる必要がある場合は、ワークロードの残りの部分へのアクセスがブロックされていることが重要です。 可能な限り、ワークロードとシステムの残りの部分から分離されたパスを介してのみコンポーネントにアクセスする必要があります。

トリアージ

問題が正常に含まれると、作業のトリアージを開始できます。 トリアージ中に実行する手順は、問題の種類によって異なります。 ワークロードサポートの特定の領域のチームは、チームに関連するインシデントの手順を作成する必要があります。 たとえば、セキュリティ チームはセキュリティの問題をトリアージし、開発したスクリプトに従う必要があります。 チームがトリアージ作業を進める中で、明確に定義されたスクリプトに従することが重要です。 これらのスクリプトは、無効な変更や他の問題を引き起こす可能性がある変更を元に戻すためのロールバック プロセスを含む、ステップ バイ ステップのプロセスである必要があります。 既製のログ集計と分析ツールを使用して、詳細な分析を必要とする問題を効率的に調査します。 問題が解決したら、適切に定義されたプロセスに従って、影響を受けるコンポーネントをワークロード フロー パスに安全に戻します。

RCA レポート

顧客に対するサービス レベル アグリーメント (SLA) によって、インシデントが解決された後、特定の期間内に RCA レポートを発行する必要があると指示される場合があります。 インシデント所有者は、RCA レポートを作成する必要があります。 それが不可能な場合は、インシデント所有者と密接に協力した別のユーザーが RCA レポートを作成できます。 この戦略により、インシデントを正確に把握できます。 通常、組織には定義された RCA テンプレートがあり、情報の提示方法と、共有できる情報と共有できない情報の種類に関するガイドラインが記載されています。 独自のテンプレートとガイドラインを作成する必要がある場合は、利害関係者によってレビューおよび承認されていることを確認します。

インシデント事後分析

公平な個人は、責任のない死後をリードする必要があります。 事後分析セッションでは、全員がインシデントの結果を共有します。 インシデント対応に関与した各チームは、インシデントに取り組んだ個人によって表される必要があります。 これらの個人は、成功した領域と改善できる領域の例を使用して準備されたセッションに来る必要があります。 セッションは、対応中に発生した可能性のあるインシデントや問題の責任を割り当てるフォーラムではありません。 事後リーダーは、次のような改善に焦点を当てたアクション 項目の明確なリストをセッションから離れる必要があります。

  • 対応計画の改善。 適切なアクションをより適切にキャプチャするには、プロセスまたはプロシージャを再評価して書き換える必要がある場合があります。

  • 監視プラットフォームの機能強化。 しきい値は、特定の種類のインシデントを前にキャッチするために再評価する必要がある場合や、考慮されていない動作をキャッチするために新しい監視を実装する必要がある場合があります。

  • ワークロードの機能強化。 このインシデントにより、永続的な修復として対処する必要があるワークロードの脆弱性が公開される可能性があります。

考慮事項

過度に積極的な対応戦略は、誤ったアラームや不要なエスカレーションにつながる可能性があります。

同様に、しきい値違反に対応するために自動スケーリングやその他の自己復旧アクションを積極的に実装すると、不要な支出や管理負担につながる可能性があります。 アラートやスケーリングなどの自動アクションに対して設定する正確なしきい値がわからない場合があります。 低い環境と運用環境でテストを実行して、要件に適したしきい値を判断できるようにします。

Azure ファシリテーション

Azure Monitor は、クラウド環境とオンプレミス環境から監視データを収集、分析、対応するための包括的なソリューションです。 これには、 自動通知やその他のアクション (自動スケーリングやその他の自己復旧メカニズムなど) 用に構成できる堅牢なアラート プラットフォームが含まれています。

Monitor を使用して機械学習を統合します。 インシデントトリアージとプロアクティブな対策を自動化して最適化します。 詳細については、「監視」の AIOps と機械学習に関するページを参照してください。

Log Analytics は、Monitor に組み込まれている堅牢な分析ツールです。 Log Analytics を使用すると、集計されたログに対してクエリを実行し、ワークロードに関する分析情報を得ることができます。

Microsoft では、Azure 関連のインシデント対応トレーニングを提供しています。 詳細については、「Azure インシデント対応性とインシデント対応性の概要」を参照してください。

オペレーショナル エクセレンス チェックリスト

推奨事項の完全なセットを参照してください。

オペレーショナル エクセレンス チェックリスト