Remediation
このモジュールで説明したように、インシデント対応のライフサイクルを 5 つのフェーズに分割すると、そのプロセスを理解するのに役立ちます。ただしこれらのフェーズは、ダイアグラムで示したほど明確ではない場合もあります。 特に、対応フェーズと修復フェーズの間の線は、ぼやけることがよくあります。 これは、状況を軽減または改善することを目的としたアクションが逆効果となる場合に特に当てはまります。 この場合、対応と修復は、両者の間で重なったり、行ったり来たりする傾向があります。
このユニットでは、修復の詳細と、このフェーズを構成する手順、およびいくつかの便利なヒントとツールについて説明します。 注意すべき重要な点の 1 つは、ここで概説されている対策を、規範的なチェックリストとして行うべきではないことです。
既に修復のチェックリストがあるなら、それは多くの場合、自動化を実現する準備ができたことを示しています。 ある問題を修復するために、何をどの順序で行う必要があるかを正確に説明できるようになったら、これらの手順をコンピューターに教えて、システムで実行できるようにする最適なタイミングです。
開始する場所
インシデントへの対応にかかる時間を短縮することの重要性について学習しました。 次に、修復、つまり問題解決のプロセスを高速化するために役立ついくつかのことを見てみましょう。
チーム メンバーごとに、物事がどのように機能するかについてのメンタル モデルが異なったり、最初に取るべき手順に関する考え方が異なったりする場合があります。 あるメンバーは最初にログを確認し、別のメンバーは最初にクエリを実行してメトリックを確認するかもしれません。 成功のための正しいパスは 1 つだけではありません。
ただし、どこへ行き何を確認すべきかについて、コンテキストやガイダンスをメンバーに提供することは役立ちます。
エスカレーションの方法と対象者
修復の開始点を計画する際には、次のような重要な疑問があります。行き詰まってしまったとき、この問題を誰にエスカレートできるでしょうか? オペレーションだけ、またはサイト信頼性エンジニアリングだけでなく、チーム全般に待機の責任を振り分ける必要があります。 信頼性の目標を達成するために、システムを稼働させておく役割をすべてのチーム メンバーが担う必要があります。
最初の対応者にはどのようなリソースが役に立ちますか?
次の考慮事項は、最初の対応者がプロセスを開始するために使用できるものを特定することです。 これには、関連するメトリック、ログ、クエリなどが含まれます。 これらは、可能であれば、Azure ブック/トラブルシューティング ガイドに記載するべきです。 これらについては、この後すぐに説明します。
また、リソースへの単純なリンクを提供することも役立ちます (多くの場合、トラブルシューティング ガイドの中にあります)。 できる限り迅速に問題に対応して修復することが目標である場合は、適切なドキュメントや URL を検索しなくても質問に対する回答を見つけやすくすることで、プロセスが速くなります。
利害関係者への情報更新
問題の解決に集中するあまり、そのインシデントの対応に直接は関与していないものの、状況を知りたい (知る必要がある) 多くの人がいることを忘れてしまう場合があります。
他の社内チームと連絡を取り、インシデントが発生した際には、何が起きているのかを絶えず知らせることが重要です。 着実な更新情報を提供しないければ、彼らは状況の更新情報を求めてやって来るでしょう。 彼らにはこの情報を求める権利がありますが、問題と進行中の対応について彼らに知らせる、より良い方法が必要です。
社内チームへの確認を明確にする必要があります。 わかっていることと、何が行われているかを彼らに明確に説明し、再度連絡する時期の見込みを設定してください。
利害関係者への連絡の式は単純です。
- これが私たちが理解していることです。
- これが私たちが行っていることです。
- X 時間以内に改めてご連絡いたします。
これにより、問題を解決しようとしている最中に、関係者がやって来て作業を中断することを防止できます。
この情報を配布する 1 つの方法は、最後のユニットで説明したような、簡単に編集できるステータス Web ページを使用することです。 多くの場合、社内の関係者向けのより詳細なステータス ページと、外部の顧客向けのものを別々に用意するとよいでしょう。 前述した連絡の方式は、両方のケースで機能します。
Azure Monitor のブックとトラブルシューティング ガイドを使用する
Azure には、修復フェーズのチームにとって非常に役に立つ、密接に関連する 2 つの機能があります。Azure Monitor のブックと Application Insights のトラブルシューティング ガイドです。 このモジュールの目的には、どちらも同様に使用することができ、ユーザー インターフェイスも同じです。 Azure Monitor ブックは、Azure portal 内の Azure Monitor の下にあります。 Applications Insight のインスタンスが選択されていると、Azure portal 内に Azure Insights トラブルシューティング ガイドが表示されます。
ブックとトラブルシューティング ガイドは、ページ作成インターフェイスを使用して作成することができる "ライブ ドキュメント" と考えることができます。 新規に作成するときに、次のものをページに追加できます。
- 実行する項目の箇条書き、またはページを参照している他の人に役立つ情報など、任意のテキスト
- 他のシステムへのリンク (他のダッシュボードまたはドキュメントへのリンクなど)
- Kusto クエリ言語 (KQL) のクエリ
この最後の項目によってドキュメントが "ライブ" になります。このラーニング パスの前のモジュールで、Azure Monitor の Log Analytics およびその他の部分に組み込まれている KQL クエリ言語について学習しました。 この言語を使用すると、独自のクエリを記述して、アプリケーションと Azure インフラストラクチャの診断情報を取得して表示することができます。 ブックまたはトラブルシューティング ガイドに KQL クエリを挿入すると、そのクエリの現在の結果がドキュメントの閲覧者にライブで表示されます。 つまり、トラブルシューティング ガイドで、"Web サーバー上のエラー率を確認してください" という指示だけでなく、そのエラー率の現在のグラフを指示の横に表示することもできます。 最初の対応者を必要なドキュメントに直接導く、"Web サーバーの再起動ドキュメントはこちら" といったリンクを含めることができます。
Azure では、独自のドキュメントの作成を始めるために役立つ、いくつかの既存のテンプレートも用意されています。 いくつかの事前に用意されているテンプレートのスクリーンショットを次に示します。
ブックおよびトラブルシューティング ガイド用の "詳細エディター" 機能により、そのドキュメントの JSON または Azure Resource Manager テンプレート表現のいずれかにアクセスして挿入することができます。 つまり、任意のソース管理システムを使用して、これらのドキュメントを追跡および配布することができます。 ブックまたはトラブルシューティング ガイドのプロビジョニングを自動化することもでき、他のインフラストラクチャをプロビジョニングするときに役立ちます。 このベスト プラクティスを使用すると、新しいサービスのプロビジョニング時に、そのサービスで使用するカスタム トラブルシューティング ドキュメントのセットを作成するのが簡単になります。
その他の便利なヒントとツール
このモジュール全体で、効率を高め、インシデント対応の時間を短縮するために使用できる、さまざまなツールやショートカットについて学習しました。 この最後のユニットのまとめとして、システム内の問題を診断する際に役立つ、いくつかのツールと手法の概要を簡単に説明します。
- Application Insights 内のアプリケーション ダッシュボードのリンクを使用すると、出発点として必要な主要項目のほとんどを含むダッシュボードを自動的に生成することができます。 Azure Service Health は含まれないことにご注意ください。 問題がシステムとクラウド サービス自体のどちらにあるかを確認できるように、これをダッシュボードにピン留めする必要があります。
- Application Insights 内のアプリケーション マップを使用すると、問題の原因を正確に調べることができます。 階層リンクを使用して、エラーの原因 (間違った形式の URL など) を見つけることができます。
- Log Analytics を使用して、システムの任意の部分に対してクエリを実行することができます。
上記のすべてのツールは、問題を修復するうえで非常に重要です。