緊急時対応戦略の設計に関する推奨事項
Azure Well-Architected フレームワークのオペレーショナル エクセレンスに関するチェックリストの次の推奨事項を対象とします。
| OE:08 | 効果的な緊急作業プラクティスを策定します。 ワークロードがインフラストラクチャとコード全体で意味のある正常性シグナルを出力していることを確認します。 結果のデータを収集し、それを使用して、ダッシュボードとクエリを介して緊急時応答を実施するアクション可能なアラートを生成します。 オンコール ローテーション、インシデント管理、緊急時リソース アクセス、事後分析の実行といった人的責任を明確に定義します。 |
|---|
このガイドは、緊急時応答戦略の設計に関する推奨事項を説明したものです。 ワークロードのライフサイクルの過程で発生する問題の中には、それらが緊急事態であると宣言するのを保証するのに十分クリティカルなものがあります。 問題が平穏に秩序だった方法で処理されるように、チームが従う厳密に制御され、重点を絞ったプロセスと手順を実装することができます。 緊急時は自然とすべての人のストレス レベルが上がり、チームの準備が整っていない場合は混沌とした状況につながる可能性があります。 ストレスや混乱を最小限に抑えるために、応答戦略を設計し、その応答戦略を組織と共有し、定期的な緊急時応答トレーニングを実行します。
主要な設計戦略
緊急時応答戦略は、秩序だった、適切に定義されたプロセスと手順のセットである必要があります。 各プロセスと手順には、迅速かつ安全な問題解決に向けてステップごとにチームを確実に前進させるスクリプトが必要です。 緊急時応答戦略を策定するには、次の概要を検討してください。
- 前提条件
- 監視プラットフォームを開発する
- インシデント対応計画を作成する
- インシデントのフェーズ
- 検出
- 封じ込め
- トリアージ
- インシデント後のフェーズ
- 根本原因分析 (RCA)
- 事後評価
- 進行中の活動
- 緊急時応答訓練
以降のセクションで、各フェーズに関する推奨事項を示します。
堅牢な緊急時応答戦略を立てるには、堅牢な監視プラットフォームを用意する必要があります。 監視プラットフォームには、次の特性が必要です。
包括的な監視: インフラストラクチャとアプリケーションの観点からワークロードを十分に監視できるようにします。
詳細なログ: 問題をトリアージするときの調査を支援するために、コンポーネントの詳細ログを有効にします。 ログは管理が簡単になるように構成してください。 分析用に準備するために、ログをデータ シンクに自動的に送信します。
便利なダッシュボード: 組織全体の各チームに合わせて調整された正常性モデルベースのダッシュボードを作成します。 異なるチームが、ワークロードの正常性のさまざまな側面を担当します。
アクション可能なアラート: ワークロード チームに役立つアラートを作成します。 チームのアクションを必要としないアラートは避けてください。 このようなアラートが多すぎると、ユーザーがアラート通知を無視したりブロックしたりする可能性があります。
自動の通知: 適切なチームが、アクションを必要とするアラートを自動的に受け取るようにします。 たとえば、レベル 1 のサポート チームはすべてのアラートの通知を受け取る必要がありますが、一方でセキュリティ エンジニアはセキュリティ イベントのアラートのみを受け取る必要があります。
詳細については、「監視フレームワークの設計と作成に関する推奨事項」を参照してください。
インシデント対応計画を作成する
緊急時応答戦略の基礎となるのは、インシデント応答計画です。 ディザスター リカバリー計画と同様に、インシデント応答計画の役割、責任、手順を明確かつ徹底的に定義してください。 この計画は、バージョン管理されたドキュメントであり、必ず最新になるように定期的なレビューを行う必要があります。
計画では次のコンポーネントを明確に定義します。
ロール
インシデント応答マネージャーを特定しましょう。 このユーザーは、開始から修復、そして根本原因分析までインシデントに責任を持ちます。 インシデント応答マネージャーは、プロセスが確実に対応され、応答チームが作業を実行した際に適切な関係者に通知されるようにします。
事後分析リーダーを特定しましょう。 この個人は、インシデントが解決された直後に事後分析が確実に実行されるようにします。 さらに、インシデントから得られる結果を適用するのに役立つレポートを作成します。
プロセスと手順
ワークロード チームは、緊急時の基準を定義して理解する必要があります。 重大なケースであるとチームが判断したら、ディザスターを宣言し、ディザスター リカバリー計画を開始できます。 重大度の低いケースでは、問題がディザスターの基準を満たしていない可能性があります。 ただし、その問題によって緊急時応答計画を開始する必要がある場合は、緊急時と考える必要があります。 緊急時の問題は、それがワークロードの内部で起きているか、ワークロードの依存関係に関する問題の結果として発生する可能性があります。 サポート チームは、内在する問題が見えない場合でも、外部ユーザーによって報告された問題が緊急時の基準を満たしているかどうかを判断できる必要があります。
コミュニケーションとエスカレーションの計画を正確に定義しましょう。 受け取るアラート通知の種類に基づいて、レベル 1 のサポートが適切なチームに簡単に連絡して問題をエスカレーションできるようにします。 彼らが内部および外部の関係者に適したコミュニケーションの種類を把握できるようにします。 コミュニケーションとエスカレーションの計画には、オンコールのスケジュールとスタッフの一覧を含めてください。
全体的な計画には、封じ込めとトリアージのスクリプトを含めます。 チームは、封じ込めとトリアージの機能を実行するときに、次のステップに従います。 何をもってインシデントをクローズするかの説明を含めます。
その他に含める項目
Microsoft Teams などの内部コミュニケーションや、チケット作成ツールやバックログ計画ツールのようなインシデントの過程で活動を追跡するためにインシデント中に使用されるすべての標準ツールを文書化します。
緊急時の資格情報を文書化します ("break-glass アカウント" とも呼ばれます)。 使用方法を説明するステップバイステップ ガイドを含めます。
緊急時応答訓練の指示を作成し、訓練が実行された日時を記録しておきます。
データ侵害の伝達など、必要な法的または規制上の措置をすべて文書化します。
監視トリガーに対するアクション
異常を監視し、それらに対して自動的にアラートを生成する、適切に設計された監視プラットフォームがあると、問題をすばやく検出し、その重大度を判断できます。 問題が緊急と見なされた場合は、計画を開始できます。 場合によっては、監視プラットフォームからサポート チームに通知されない場合があります。 サポート チームのコミュニケーション手段を使用して、顧客がサポートに問題を報告する場合があります。 アカウントの役員や VP など、定期的に仕事をしているユーザーに連絡を取る場合もあります。 どのようにしてサポート チームに通知するかに関係なく、常に同じステップに従って問題を検証し、重大度を判断する必要があります。 応答計画から逸脱すると、ストレスや混乱が増す可能性があります。
封じ込めの手順を定義する
問題を修復する最初のステップは、問題を封じ込めてワークロードの残りの部分を保護することです。 封じ込め戦略は問題の種類によって異なりますが、通常はワークロード フローのパスから影響を受けるコンポーネントを削除する必要があります。 たとえば、リソースをシャットダウンしたり、ネットワーク ルーティングのパスから削除したりする場合があります。 システム管理者、エンジニア、上級開発者は、協力して封じ込め戦略を設計する必要があります。 封じ込めでは、問題の爆発半径を制限し、問題が解決されるまでワークロード機能を低下状態に維持する必要があります。 トリアージを実行するために影響を受けるコンポーネントにアクセスできるようにする必要がある場合は、ワークロードの残りの部分へのアクセスがブロックされていることが重要です。 可能な限り、ワークロードと残りのシステムから分離されたパスを介してのみコンポーネントにアクセスする必要があります。
トリアージの手順を定義する
問題の封じ込めに成功したら、トリアージ作業を開始できます。 トリアージ中に実行するステップは、問題の種類によって異なります。 ワークロード サポートの特定領域のチームは、自分のチームに関連するインシデントの手順を作成する必要があります。 たとえば、セキュリティ チームはセキュリティの問題をトリアージし、自分たちで開発したスクリプトに従う必要があります。 トリアージ作業を行うチームは、明確に定義されたスクリプトに従う必要があります。 これらのスクリプトは、ステップバイステップのプロセスであり、無効な変更や他の問題の原因となる可能性がある変更を元に戻すためのロールバック プロセスを含む必要があります。 詳細な分析が必要な問題を効率的に調査するには、既製のログ集計および分析ツールを使用します。 問題が解決したら、適切に定義されたプロセスに従って、影響を受けるコンポーネントをワークロード フローのパスに安全に戻します。
RCA インシデント レポートを生成する
顧客とのサービス レベル アグリーメント (SLA) によっては、インシデントが解決された後、一定の期間内に RCA レポートを発行することが規定されている場合があります。 インシデント所有者は、RCA レポートを作成する必要があります。 それが不可能な場合は、インシデント所有者の近くで働いていた別の人物が RCA レポートを作成しても構いません。 この戦略により、インシデントの正確な報告が保証されます。 通常、組織は RCA テンプレートを定義しており、情報の提示方法、そして共有できる情報と共有できない情報の種類に関するガイドラインがあります。 独自のテンプレートとガイドラインを作成する必要がある場合は、関係者によってレビューされ、承認されていることを確認します。
インシデント事後分析を行う
公平な個人が、非の打ちどころのない事後分析を主導する必要があります。 事後分析セッションでは、全員がインシデントの結果を共有します。 インシデント応答に関与した各チームは、インシデントに取り組んだ個人が代表する必要があります。 これらの個人は、成功した領域と改善できる領域の例を準備してセッションに参加する必要があります。 このセッションは、応答中に発生した可能性のあるインシデントや問題に対する責任を割り当てるためのフォーラムではありません。 事後分析のリーダーは、次のような改善内容に焦点を当てた実施項目の明確なリストをセッションで残す必要があります。
応答計画の改善。 適切なアクションをより適切にキャプチャするには、プロセスまたは手順を再評価して書き換えなければならない場合があります。
監視プラットフォームの改善。 特定の種類のインシデントを事前に把握するためにしきい値を再評価したり、考慮されなかった動作を把握するために新しい監視を実装したりしなければならない場合があります。
ワークロードの改善。 インシデントによって、永続的な修復として対処する必要があるワークロードの脆弱性が明らかになる場合があります。
考慮事項
積極的すぎる応答戦略は、誤ったアラームや不要なエスカレーションにつながる可能性があります。
同様に、しきい値違反に応答するために自動スケーリングやその他の self-healing アクションを実装しすぎると、不必要な支出や管理の負担につながる可能性があります。 アラートや自動アクション (スケーリングなど) に設定する正確なしきい値がわからない場合もあります。 早い段階の環境と運用環境でテストを実行することが、要件に適したしきい値を判断するのに役立ちます。
Azure ファシリテーション
Azure Monitor は、クラウドとオンプレミスの環境からの監視データを収集し、分析し、それに応答するための包括的なソリューションです。 これには、自動スケーリングやその他の self-healing メカニズムなど、自動通知やその他のアクション用に構成できる堅牢なアラート プラットフォームが含まれています。
機械学習を統合するには Monitor を使用します。 インシデントのトリアージとプロアクティブな対策を自動化して最適化します。 詳細については、Monitor の AIOps と機械学習に関する記事を参照してください。
Log Analytics は、Monitor に組み込まれている堅牢な分析ツールです。 Log Analytics を使用すると、集計されたログに対してクエリを実行し、ワークロードに関する分析情報を得ることができます。
Microsoft は、Azure 関連のインシデント対応トレーニングを提供しています。 詳細については、「Azure Incident Readiness の概要」と「インシデント対応」を参照してください。
関連リンク
オペレーショナル エクセレンス チェックリスト
レコメンデーションの完全なセットを参照してください。