PagerDutyでインシデントを割り当てられたとき、最初にすべきことは何でしょうか？すぐに「受任！（Acknowledge）」と思った方は間違っていませんが、その後は、できるだけ早く、痛みを伴わずに問題を解決することが大切です。解決への第一歩は、最初にインシデントの原因を調査し、簡単に修正策を講じられるようにすることです。 PagerDutyのプラットフォームでは、Root Cause Analysis（根本原因分析）*は、レスポンダーであるあなたにできるだけ多くのコンテキストと実用的なインテリジェンスを提供することを目的とした一連の機能を指します。過去に発生したインシデントや関連するインシデント、インシデントの発生頻度に関する情報を表示することで、レスポンダーは根本原因を特定するために必要な状況認識を素早く得ることができ、迅速なトリアージと、そして最終的には早期解決につながるツールを手にすることができます。また、過去のデータに基づき、発生源と思われる場所がハイライト表示され、状況を把握しやすくなります。 ここでは、インシデントの詳細ページで、潜在的な根本原因を調査するのに役立つ5つの場所を紹介します。
1. Outlier Incident
インシデントを最初に開くとき、［Outlier Incident］分類ラベルを探します。このラベルはインシデント名の直下にあり、"Frequent", "Rare", "Anomaly "のいずれかの分類ラベルが表示されます。この分類ラベルに基づいて、このインシデントが以前に発生したことがあるかどうか、また過去の経験に基づいてどう対応すべきかをすぐに判断することができます。ラベルにカーソルを合わせると、それぞれの定義が表示されます。
2. Past Incidents
サービス上でインシデントが発生した頻度を決定したら、ページのさらに下にある［Past Incidents］タブに移動します。ヒートマップが表示され、このオープンインシデントのような過去のインシデントが過去６カ月間にいつ発生したかが示されます。色のパターンを探す（色が濃いほどインシデントが集中している）か、ヒートマップの色にカーソルを合わせると、関連するインシデントの詳細が表示されます。その下には、オープンインシデントのような過去のインシデント上位５件（もしあれば）の詳細と、それらがいつ発生したか、誰が最後にインシデントを変更したかについての情報が表示されます。注：その人は、インシデントに際して何をしたか尋ねたり、それに関するメモを見たい場合、素晴らしいリソースになります。過去のインシデントの詳細ページを開くには、ハイパーリンクされたタイトルをクリックします。
3. Related Incidents
もう一つの簡単な情報源は、［Related Incidents］タブです。ここでは、同じサービス上の類似のインシデントしか表示されない過去のインシデントとは異なり、全サービスからあなたの問題に関連する可能性のある進行中のインシデントがあるかどうかを確認できます。ビジネス全体のインシデントの範囲（これは孤立したものか、より大きな問題の一部か）を理解することは、影響を理解し、問題を解決するために協力する必要がある人を迅速に特定するのに役立ちます。
4. Probable Origins
インシデントの詳細ページにある［Probable Origins］ウィジェットを使用して、トリアージ作業を素早く始められます。このウィジェットは、インシデントが現在のオープンインシデントの類似イベントの直前に発生したか、または直後に発生したかなどの履歴データに基づいて、発生源の可能性のパーセンテージを計算します。
5. Change Correlation
最後に、インシデントの原因となった可能性のあるインフラやコードの変更に気付いている場合、解決を大幅に加速できます。インシデントの詳細ページの［Recent Changes］に表示される［Change Correlation］は、時刻、関連サービス、PagerDutyの機械学習に基づいて、インシデントに最も関連する最近の変更イベントを３つ表示します。最近の変更イベントには、プラットフォームがイベントを表面化させた理由が表示されるため、潜在的な原因を簡単に絞り込めます。
ナレッジチェック！ 正しいでしょうか、間違いでしょうか？： [Past Incident]タブには同じサービスのResolved Incidentsが表示され、[Related Incidents]には他のサービスのOpen Incidentsだけが表示されます（ページ下部の回答を参照）。
いかがでしたでしょうか？これら５つの、コンテキストをすばやく取得し、トリアージ作業を開始するために調べられる場所を忘れないでください。
インシデントを迅速に解決し、ダウンタイムをさらに短縮するには、この一連のRoot Cause Analysys機能をNoise ReductionとEvent Orchestrationの機能と組み合わせるとよいでしょう。再確認が必要な場合は、PagerDuty UniversityのEvent Intelligenceコースを受講し、Event Intelligence認定を取得して、ハードワークではなく、スマートな作業ができることを証明してください。
次のステップのためのリソース：
Event Intelligenceコースは、PagerDuty University eLearning Portalでご覧いただけます。
- Noise Reduction
- Event Orchestration
- Root Cause Analysis
Event Intelligence Certification Exam（認定試験）の情報は、このページの "Specialty Product Certification" でご覧いただけます。この新シリーズの発売を記念して、30日間、試験への登録を無料にしますので、今すぐご登録ください。
*脚注：このカテゴリーの機能を「Root Cause Analysis」と呼んでいますが、PagerDutyは根本原因を予測したり特定したりするものではありません。むしろ、PagerDutyの機能は、インシデントに関連するコンテキストを作成し、より迅速な解決を促進するためのものです。また、業界では、真の「root cause」が１つであることを示すような用語ではなく、「probable」cause または「 proximate」causeという用語を採用する方向に変化していることも注目に値します。
ナレッジチェックの回答：誤りです。過去のインシデントは同じサービス上で解決された過去のインシデントのみを表示するという記述は正しいのですが、関連インシデントは全サービス（現在のインシデントが起きているサービスを含む）上で未解決の、または最近解決した他のアクティブなインシデントを調べ、現在のインシデントに関連しているインシデントがあるかどうかを確認します。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
カテゴリー ：DevOps
