BLOG
インシデント対応のボトルネックを回避する

インシデント 対応のボトルネック―今お使いのインシデント 対応システムでは少ないかも知れませんが、確かに存在することをご存知でしょう。オンコールのチームやお客様のためにボトルネックは最小限に抑える必要があります。最も重大なボトルネックのいくつか、およびそれらを回避する方法を見てみましょう。

あなたの目標は何ですか?

まず、プロセスのボトルネックを理解する前に、そのプロセスの目標が何かを理解する必要があります。インシデント対応の目標は何でしょうか。

ほとんどのインシデント対応チームにとって目標はおそらく次のようになります。

• インシデントの発生を防ぐ。 インシデントの予防は、問題解決を主な目的とするインシデント管理の手には余る可能性がありますが、予防は計画外の作業を削減するために重要です。
• 損害を最小限の範囲にとどめる。実際には、インシデント管理における予防的取り組みの大部分はこの点に焦点に当てられています。インシデントが発生しないようにすることができない場合でも、インシデントが広がらないようにすることができます。
• インシデントを迅速に解決する。全てのインシデントを解決できるわけではなく、全ての修正が根本的な問題を解決するわけではありませんが、迅速なインシデント解決は一番重要です。

各ボトルネックを監視する

上記がインシデント対応の基本的な目標である場合、ボトルネックはそれらの目標を達成することを困難にします。これらの中で最も重要なものは次のとおりです。

優先順位を適切に設定できない

優先順位付けは、インシデント解決とインシデントの影響の封じ込めに利用できる最も重要な手段です。深刻な影響の可能性に基づいて、最も注意が必要なインシデントに焦点を当てることができます。インパクトが比較的少ないインシデントは脇に置いておくこともできますが、それでも多大なチームの時間と注意が取られます。適切な優先順位を設定しなかった場合、重要なインシデントの一部が速やかに処理されない、あるいはまったく処理されないことがあります。

過負荷とアラート疲れ

対応チームがアラートの量に圧倒された場合、どの問題を優先すべきか判断する時間がないため、または真のインシデントをノイズのアラートから見分けることができず、麻痺して全てに対応することができなくなります。これは慢性的なアラート疲れにつながる可能性があります。チームメンバーが無意識にほとんどのアラートを無視する精神状態に陥るため、僅かなインシデントにしか集中できなくなります。

アラートのノイズをフィルタリングするための（典型的には自動化された）システムが絶対必要です。対応不可能なアラートを抑制し、関連するアラートを1つのインシデントにグループ化する必要があります。理想的には、これはルールを介して自動的に行われるべきです。さらに、アラート疲れや報告忘れが致命傷になる可能性があるため、チームメンバー全員にアラートするのではなく、適切なチームやチームメンバーだけにアラートを送るシステムを導入することが重要です。

不十分な準備、訓練、経験

理想的には、全てのインシデント対応チームは、問題を迅速に診断でき、各インシデントを修正するためにどのツールとテクニックを使用すべきかを理解している、高度に熟練した技術者で構成する必要があります。

このような問題を最小限に抑える最良の方法は、インシデント対応者のための正式なトレーニングシステムを用意すること、新しいチームメンバーは可能な限り経験豊富なチームに配属すること、チームに適切なドキュメントを用意することです。一貫性と再現性の高いベストプラクティスを実現するためのドキュメントには、基本的な手順のマニュアルや、索引付きで簡単に検索できる相互参照の効くデータベース（過去のインシデントなど）が含まれている必要があります。

メジャーな新製品のロールアウトに対する不十分な準備

メジャーなアプリケーションのリリースの際―それは全く新しいアプリケーションやサービスかもしれませんがー開発者がいくつかの重大なバグを見逃して大量のアラートが押し寄せる事態に対応チームは備えておくべきでしょうか。結局のところマーフィーの法則はいつでも有効です。それが起こるのは広く使われているプログラムのアップデートや、1つ2つのバグが絡みあったトレースしにくいエラーを発生させる場合です。対応チームが準備できていない場合、時間とリソースの全てが優先順位の高いアラートの暴風に巻き込まれ、関連性のないその他のインシデントを処理するための余裕はほとんどありません。

もちろん、リリース前にA／Bテストやカナリアテストなどでアップデートが適切にテストされていることが理想的です。応答チームが配備作業に加わっていれば、問題がはるかに小さなうちに対処できる機会があります。しかし、限定的な導入から始めるという決定をインシデント対応チームが下すのは不可能であり、十分にテストされていないリリースに対処しなければならない可能性があります。

このような状況では、全ての対応者をオンコール待機にするか、アップデートで起こる全ての問題を処理する特別なチームを指定する必要があります。どのアプローチが最も効果的かは、少なくとも更新の範囲と利用可能な対応チームのリソースによって決まります。しかし、計画はいつでも何度でも必要に応じて変更できますし、計画を立てておけば準備ができていない場合とは大違いになります。

ボトルネックの解消

他にも、時代遅れの障害が発生しやすいインフラや過負荷のインフラから生じるインシデントや、インシデントとは無関係のタスクで対応チームの時間が取られるなど、多くのボトルネックがあります。しかし、私たちが列挙したボトルネックは、インシデント対応チームが時間を消費した理由の多くを占めており、ここで提案した修復アプローチは、それらの大半をなくすのに役立ちます。