緊急対応戦略を設計するための推奨事項
この Power Platform Well-Architected オペレーショナル エクセレンス チェックリストの推奨事項に適用されます:
| OE:07 | 効果的な緊急時対応の実践方法を開発します。 ワークロードが意味のある正常性シグナルを発していることを確認してください。 結果のデータを収集し、それを使用してダッシュボードとクエリを通じて緊急対応を実行する実用的なアラートを生成します。 オンコール ローテーション、インシデント管理、緊急リソースへのアクセス、事後検証の実行など、人的責任を明確に定義します。 |
|---|
このガイドでは、緊急対応戦略を設計するための推奨事項について説明します。 一部のワークロードはミッションクリティカルである可能性があり、ワークロードのライフサイクル中に発生する問題は緊急事態と宣言する必要があるほど深刻である可能性があります。 厳密に管理され、焦点を絞ったプロセスと手順を実装することで、チームが従うことで問題が冷静かつ秩序立った方法で処理されるようにすることができます。 緊急事態が発生すると当然全員のストレスレベルが高まり、チームが十分な準備をしていないと混乱した環境につながる可能性があります。 ストレスと混乱を最小限に抑えるために、対応戦略を設計し、組織内で対応戦略を共有し、定期的に緊急対応のトレーニングを実施してください。
主要な設計戦略
緊急対応戦略は、明確に定義された一連のプロセスと手順である必要があります。 各プロセスと手順にはスクリプトを用意し、各 手順 によってチームが問題を迅速かつ安全に解決できるようにする必要があります。 緊急対応戦略を策定するには、次の概要を考慮してください。
- 前提条件
- モニタリング システムを開発する
- インシデント 応答プランを作成する
- インシデント フェーズ
- 検出と封じ込め
- トリアージ
- インシデント前のフェーズ
- 根本原因分析 (RCA)
- 事後分析
- 進行中の活動
- 緊急応答訓練
以下のセクションで、これらのフェーズの各シナリオのレコメンデーションを提供します。
監視システム
堅牢な緊急時の 応答 戦略を実現するには、堅牢な監視システム、つまり観測可能性プラットフォームを導入する必要があります。 可観測性プラットフォームには次の特性が必要です。
総合的な監視: 構成とアプリケーションの観点からワークロードを徹底的に監視し、ワークロードのコンポーネントがクラウドまたは オンプレミスの でホストされている場合はインフラストラクチャの監視も含めるようにしてください。 ワークロードのすべてのコンポーネントが監視戦略でカバーされていることを確認します。 たとえば、ワークロードがAzureリソースまたは オンプレミスの システムと対話する場合は、それらのコンポーネントを監視に含めます。
詳細ログ記録: 問題をトリアージする際の調査を支援するために、コンポーネントの詳細ログ記録を有効にします。 管理しやすいようにログを構造化します。 分析の準備として、ログをデータ シンクに自動的に送信します。
便利なダッシュボード: 組織全体の各チームに合わせて調整されたヘルス モデルに基づくダッシュボードを作成します。 さまざまなチームが、ワークロードの正常性のさまざまな側面を担当します。
実用的なアラート: ワークロード チームに役立つアラートを作成します。 チームによるアクションを必要としないアラートは避けてください。 この種のアラートが多すぎると、ユーザーがアラート通知を無視したりブロックしたりする可能性があります。
自動通知: 適切なチームがアクションを必要とするアラートを自動的に受信できるようにします。 たとえば、Tier 1サポート チームはすべてのアラートの通知を受け取る必要がありますが、セキュリティ エンジニアはセキュリティ イベントのアラートのみを受け取る必要があります。
詳細については、 監視フレームワークの設計と作成に関する推奨事項をご覧ください。
インシデントの対応プラン
緊急対応戦略の基礎となるのは、インシデント対応プランです。 災害復旧計画と同様に、インシデントに対応するための役割、責任、手順を明確かつ徹底的に定義します。 計画はバージョン管理された文書である必要があり、定期的なレビューを受けて最新であることが確認されます。
あなたのプランでは次のコンポーネントを明確に定義します。
Roles
インシデント対応マネージャーを特定します。 この人物は、インシデントの開始から修復、根本原因の分析までを担当します。 インシデント 応答 マネージャーは、応答 チームが作業を実行する際にプロセスが遵守され、適切な関係者に通知されるようにします。
事後リーダーを特定します。 この人物は、インシデントの解決後すぐに事後分析が実行されるようにします。 インシデントから得られた調査結果を適用するのに役立つレポートを作成します。
プロセスと手順
ワークロード チームは緊急基準を定義し、理解する必要があります。 チームが状況が深刻であると判断した場合、災害を宣言し、災害復旧計画を開始できます。 それほど深刻ではない場合、問題は災害の基準を満たさない可能性がありますが、それでも問題を緊急事態と見なす必要があり、緊急時の 応答 計画を開始する必要があります。 緊急事態は、アプリケーション コードのバグなどワークロード内部で発生する場合もあれば、APIやデータベースが利用できないなどワークロードの依存関係の問題によって発生する場合もあります。 緊急事態は、サプライヤーの稼働停止 (例えば、Microsoft Entra ID または Power Platform) によるものであることもあります。 サポート チームは、根本的な問題を把握していない場合でも、問題が緊急基準を満たしているかどうかを判断できる必要があります。
コミュニケーションとエスカレーションの計画を正確に定義します。 受信するアラート通知の種類に基づいて、Tier 1サポート チームのメンバーが問題をエスカレーションするために適切なチームに簡単に連絡できるようにします。
その他に含めるべき項目
インシデント発生中に使用される、内部コミュニケーション用 ( Microsoft Teams など) や、チケット ツールやバックログ計画ツールなどのインシデント発生中のアクティビティの追跡用に使用される標準ツールをすべて文書化します。
緊急時の資格情報、別名 緊急アカウント を記録します。 使用方法を説明したステップバイステップのガイドを含めます。
緊急時の 応答 より細かく 指示を作成し、訓練を実施した日時を記録します。
データ侵害の伝達など、必要な法的または規制上の措置を文書化します。
インシデントの検出と封じ込め
異常を監視し、自動的に警告を発する適切に設計された監視システムがあれば、問題を迅速に検出し、その重大度を判断できます。 問題が緊急事態であると判断された場合、計画を開始できます。 場合によっては、監視システムを通じてサポート チームに通知されないことがあります。 ユーザーは、サポート チームの通信手段を使用して、サポートに問題を報告する場合があります。 または、サービス管理者やCenter of Excellenceチームなど、定期的に一緒に仕事をしている人や、一緒に仕事をしているとわかっている人に連絡することもあります。 Power Platform Power Platform サポート チームへの通知方法に関係なく、サポート チームは常に同じ手順に従って問題を検証し、重大度を判断する必要があります。 対応計画からの逸脱は、ストレスと混乱を増大させる可能性があります。
トリアージ
問題修復の最初のステップは、問題の原因となっているワークロードのコンポーネントを特定することです。 トリアージ中に従う手順は、問題の種類によって異なります。 特定のワークロード サポート領域を担当するチームは、その作業に関連するインシデントの手順を作成する必要があります。 たとえば、セキュリティ チームはセキュリティの問題をトリアージし、作成したスクリプトに従う必要があります。 チームがトリアージの取り組みを進める際には、明確に定義されたスクリプトに従うことが重要です。 これらのスクリプトは、効果のない変更や他の問題を引き起こす可能性のある変更を元に戻すためのロールバック プロセスを含む、ステップバイステップの手順である必要があります。 問題が解決したら、明確に定義されたプロセスに従って、影響を受けるコンポーネントをワークロード フロー パスに安全に戻します。
根本原因分析の報告
インシデントの所有者または所有者と緊密に連携した人物が根本原因分析 (RCA) レポートを作成する必要があります。 この戦略により、インシデントの正確な記録が保証されます。 通常、組織には、情報の表示方法や共有できる情報の種類、共有できない情報の種類に関するガイドラインを含む定義済みの RCA テンプレートがあります。 独自のテンプレートとガイドラインを作成する必要がある場合は、関係者がそれらを確認して承認するようにしてください。
インシデントの事後分析
公平な立場の人間が非難の余地のない事後検証を主導すべきです。 事後検証セッションでは、全員がインシデントから得た知見を共有します。 インシデント 応答 に関与した各チームは、インシデントに取り組んだ個人によって代表される必要があります。 これらの個人は、成功したアクションの例と改善できる領域を準備してセッションに出席する必要があります。 このセッションは、応答 中に発生する可能性のあるインシデントや問題に対する責任を割り当てるためのフォーラムではありません。 事後分析リーダーは、次のような改善に焦点を当てたアクション項目の明確なリストを持ってセッションを終了する必要があります。
- 対応計画の改善。 適切なアクションをより適切に把握するには、プロセスまたは手順を再評価して書き直す必要がある場合があります。
- 監視システムの改善。 特定の種類のインシデントを早期に検出するためにしきい値を再評価する必要がある場合や、考慮されていない動作を検出するために新しい監視を実装する必要がある場合があります。
- ワークロードの改善。 インシデントにより、永続的な修復として対処する必要があるワークロードの脆弱性が明らかになる可能性があります。
考慮事項
緊急対応戦略は、全体的な Power Platform サポート戦略 と密接に連携する必要があります。 管理者やCenter of Excellenceチームと協力して、すでに定義されている可能性のあるサポートと緊急時の 応答 オプションおよびプロセスについて話し合ってください。 Power Platform
サポート プロセスとエスカレーション パスを定義するときは、重要度に基づいて構築されたソリューションを 分類 することが重要です。 このプラクティスにより、生産性シナリオの革新を妨げたり、インシデント 応答 チームに負担をかけたりすることなく、重要なアプリケーションに必要なサポート ガードレールが備わっていることを保証するプロセスを確立できます。 サポート モデルを定義するときは、卒業までの道のりについても考えてください。 ソリューションは、最初は生産性レベルのサポートのみを必要とするかもしれませんが、機能やユーザー ベースが拡大すると、より高いレベルのサポートが必要になる場合があります。 作成者がより正式なサポートを要求し、ソリューションをサポートされる環境に移行する方法を定義します。
Power Platform の促進
Power Platform は、Azure Monitor エコシステムの一部である Application Insights と統合します。 この統合は以下に使用します。
Application Insights の Dataverse プラットホーム で取得された診断とパフォーマンスに関するテレメトリを受信します。 アプリケーションが Dataverse データベースおよびモデル駆動型アプリ内で実行する操作に関するテレメトリを受信するようにサブスクライブできます。 このテレメトリは、エラーとパフォーマンスに関連する問題の診断とトラブルシューティングに使用できる情報を提供します。
キャンバス アプリから Application Insights に接続します。 これらの分析を使用して問題を診断し、ユーザーがアプリで何を行っているかを把握できます。 より適切なビジネス上の意思決定に役立つ情報を収集し、およびアプリの品質を向上することができます。
Power Automate テレメトリ を Application Insightsに流入するように構成します。たとえば、クラウド フロー の実行を監視し、クラウド フロー の実行失敗に関するアラートを作成します。
Application Insights は、クラウドおよび オンプレミスの 環境から監視データを収集、分析し、対応するための包括的なソリューションです。 これには、自動通知やその他のアクション を設定できる堅牢なアラート プラットフォームが含まれています。
Power Platform オートメーション キット は、自動化プロジェクトにおけるデスクトップ用 Power Automate の使用とサポートを加速させる一連のツールです。 このキットは、自動化プロジェクトを管理し、それらをモニタリングして節約された費用と投資収益率 (ROI) を見積もるのに役立つツールを提供します。 自動化キットの一部である コントロール センターは、既存のモニター デスクトップ フロー 実行機能を補完します。 コントロール センターの主な焦点は、サポート アナリストと組織が監視し、アクションを実行し、必要に応じて警告するためのオーケストレーター ビューです。