効果的なインシデント管理のためのエスカレーション ポリシー
インシデントが発生した場合、最良のシナリオは、オンコール エンジニアまたは SRE が迅速に、かつ自分で解決できることです。
もちろん、現実の世界では必ずしもうまくいくとは限りません。解決には大規模なチーム、専門的な知識、または上級スキルが必要となる場合があります。そのため、3 人以上の技術プロフェッショナルを抱える組織には、インシデント エスカレーションの計画とポリシーが必要となります。
インシデントのエスカレーションとは?
インシデント エスカレーションとは、従業員がインシデントを自分で解決できず、より豊富な経験を持つ、または専門分野に特化した従業員にタスクを渡す必要がある場合に行われる手続きです。
エスカレーション ポリシーとは?
エスカレーション ポリシーでは、組織がこれらのハンドオフをどのように処理するかという質問の答えを提供しています。このポリシーでは、インシデント アラートを受信したときに通知を受ける担当者、最初の応答者が対応できない場合にインシデントをエスカレーションすべき担当者、応答者が自分で課題を解決できない場合に引き継ぐ担当者、これらのハンドオフの処理方法 (サービス デスク経由、技術者間で直接、またはインシデント管理ツールを介する) を説明しています。
一見すると、これらの質問はシンプルに見えますが、組織の規模が大きくなって技術エコシステムが複雑になるほど、それらの回答にはより詳細な説明が必要になります。たとえば、インシデント アラートを受信する際に通知を受ける担当者を特定する場合、オンコール担当者や対応可能な状態であるかどうかだけでなく、インシデントの重大度レベルや期間などによって、回答が異なる場合があります。
一部の企業では、インシデントの重大度に関係なく 1 人のオンコール担当者が最初に通知を受ける担当である場合があります。また別の企業では、インシデントが重大度 3 である場合は経験の浅い開発者に通知し、重大度 1 の場合はより上級の担当者または専門チームに通知するのが理にかなっている場合があります。
同様に一部の企業では、必要に応じてインシデントをエスカレートするかどうかは最初の対応者の判断に任せる場合があります。その他の企業では、インシデントが一定時間を超える、またはより多数のシステムまたはユーザーに影響を与え始めた場合は、より上級の開発者または専門チームへの自動エスカレーションがトリガーされる場合があります。
エスカレーション ポリシーでは、インシデントをエスカレートする方法や担当者だけでなく、インシデントのタイプ、重大度レベル、期間、インシデントの範囲に基づく微妙な違いがあるかどうかについても考慮する必要があります。
インシデントのエスカレーション プロセス
ITSM のベスト プラクティスに従う企業では通常、サービス デスクがインシデント エスカレーションの中核を担います。最初の対応者がインシデントを解決できない場合は、インシデントはサービス デスクに戻ります。サービス デスクは、適切な次の防衛線に課題をエスカレーションします。Jira Service Management を使用すると、対応者はインシデント チケット内でインシデントをエスカレーションすることができます。対応者は、解決プロセスの指針となるワークフローにアクセスでき、自動化を実行したり、必要に応じてアクションをカスタマイズしたりできます。重大度レベルを指定することで、対応者を適切なワークフローに誘導することができます。
Google のような他の企業は、SRE にインシデントを担当させて、この担当者が必要なエスカレーションをすべて担当します (さらに、SLA/SLO に従ってインシデントがダウンタイムの許容しきい値を超えた場合の新規リリースの凍結も担当します)。
その他の企業でも、最初の応答者が開発者またはインシデント マネージャーであったり、最初の窓口が複数存在したりする場合があります (特に重大度の高いインシデントに関するアラートを受信する場合)。また、エスカレーションが、それらのチーム内およびチーム間で直接に事前定義されたプロセスを介して行われる場合があります。
プロセスがサービス デスクを通じて行われるか、SRE によって促進されるか、またはインシデント追跡システム内で自動的に行われるかにかかわらず、通常、エスカレーション ポリシーが従う経路は 3 つあります。
階層エスカレーション
階層エスカレーションは、インシデントがチームまたは個人の経験レベルまたは年功序列に基づいて渡される際に行われます。
たとえば、最初のオンコールの応答者は、チームにとって新人の経験の浅い開発者である場合があります。階層的な組織において、これらの応答者が課題を解決できない場合は、その課題をより上級の開発者に渡します。この上級開発者も課題を解決できない場合は、再度より上級の開発者に渡します。このエスカレーションは課題が解決するまで続行されます。
機能エスカレーション
機能エスカレーションは、年功序列ではなく、スキルやシステムに関する知識に基づいて、インシデントを解決するのに最も適したチームまたは人物にインシデントが渡されるときに行われます。
たとえば最初のオンコールの応答者は、製品 X のバック エンドに焦点を当てたチームに属する、経験の浅い開発者である場合があります。中核となる問題が製品 Y との統合から発生している可能性があることが分かった場合、このインシデントを製品 Y チームに属する別の経験の浅い開発者にエスカレートできます。
自動エスカレーション
Opsgenie などのプラットフォームで作業しているチームの場合、主要なオンコール担当者がアラートを認識していない、またはアラートをクローズしない場合は、インシデントを自動的にエスカレートするようにシステムに指示するルールを設定できます。
チームによっては、エスカレーション方式のなかで 1 つのエスカレーション方式を好む場合がありますが、これらは互いに矛盾するものではありません。また、多くのチームは、階層エスカレーション、機能エスカレーション、自動エスカレーションを混合して使用しています。
エスカレーション マトリクス
エスカレーション マトリクスとは、エスカレーションを行う時期、各エスカレーション レベルでインシデントを処理する担当者を定義するドキュメントまたはシステムのことです。
この用語は、多くの業界で使用されています。人事部門が、社内の課題に関するエスカレーション マトリクスを採用している場合があります。コール センターが、カスタマー サービスの課題に関するエスカレーション マトリクスを採用している場合があります。また、IT チームと DevOps チームが、エンジニアがインシデントをエスカレートする方法と時期を把握できるように、マトリクスを 1 つ以上採用している場合があります。
マトリクスの詳細のレベルは、会社ごとに大きく異なります。一部の組織では、単純な階層チャートを採用して、各開発者が必要に応じてスキル レベルのより高い開発者にエスカレートしています。他の組織では、インシデントの種類や重大度レベル別に連絡すべきチームを開発者に指示する、状況に応じたマトリクスを採用しています。インシデント管理のほとんどの事例と同様に、組織のマトリクスを開発する方法についてはすべてに適した答えはありません。
エスカレーション ポリシーを策定するための優れたプラクティス
エスカレーション ポリシーは厳格な一連のルールではなく、ガイドラインとして扱う
テクノロジーは静的なものでも、チームでもありません。Google では、SRE が特定のケースに異なるエスカレーション戦略が必要だと考える場合は、自由に主観的な判断ができるようにするように提案しています。ここでのポイントは、柔軟性のないルールを作成するのではなく、ほとんどの状況に該当するガイドラインを作成することです。
オンコール スケジュールを定期的に監査する
スケジュールにギャップがありますか? オンコールに対応する適切な人材がいますか? オンコールの第 2 階層と第 3 階層に適切な人材がいますか? より迅速なインシデント管理を実現するには、オンコール スケジュールとエスカレーション ポリシーが連携している必要があります。
エスカレーションのスマートしきい値を設定する
すべてのインシデントが同等に作成されるわけではありません。つまり、すべてのインシデントが同じエスカレーション ポリシーに従えるということではなく、その必要もありません。
軽微なインシデントの場合は、勤務時間になるまでオンコール エンジニアに通知する必要はありません。重大なインシデントの場合は、おそらく何時であってもオンコール エンジニアが必要になるでしょう。複数のインシデントが発生した場合にエンジニアは、最初に取り組むべき内容やインシデントをすぐに第 2 のエンジニアにエスカレートする必要があるかどうかを把握する必要があります。
これに関しては、システムのアップタイムを最大限に確保して、SLA の約束と SLO の目標を達成することと、エンジニアが疲れ切り、働き過ぎ、睡眠時間を奪われ、アラートによる疲弊が生じないようにすることとの、バランスを取る必要があります。
エスカレーションの明確なプロセスを設定する
エスカレートする開発者は、適切なチームまたは担当者に直接連絡するか、ヘルプ デスクを経由する必要があるでしょうか? 開発者が使用する必要があるシステムは利用可能でしょうか? エスカレーションの追跡方法は? インシデントを次の担当者に確実に引き継ぐために、最初の対応者が負う責任はどのようなものでしょうか?
これらの質問には、ポリシーによって明確に対処してすべてのオンコール開発者に明確に伝達し、エスカレーションを円滑に実行してインシデントをより迅速に解決する必要があります。
Jira Service Management が、インシデントのエスカレーションをより迅速に解決するための総合ソリューションを提供することで、インシデント管理を強化する方法について詳しく説明します。
Opsgenie を使用したオンコール スケジュールの設定
このチュートリアルでは、オンコール スケジュールの設定、オーバーライド ルールの適用、オンコール通知の設定などの方法を学習します。すべて Opsgenie 内で行います。
このチュートリアルを読むオンコール スケジュールへのより優れたアプローチ
効果的なオンコール スケジュールは、健全なオンコール文化を維持するための鍵です。よくある間違い、ローテーション スケジュールの種類、正しく理解する方法を学びます。
この記事を読む