インシデントのコストはどのように測定するか
テクノロジー業界の多くの人々は、インシデントのコストを、ダウンタイムや影響を受けた顧客や従業員の数といった観点のみから語ります。そして、表面的には正しい見方であることが多いのです。ニュースにもなりますし、顧客の評判と信頼はあらゆるビジネスの成功に欠かせないことは明らかです。
しかし、インシデントの直接的なコストとしてあまり認識されていないのが、インシデント発生時に関与する必要がある人数です。顧客に影響を与えるほど深刻なインシデントであろうとなかろうと、根本原因の調査、トラブルシューティング、インシデントの解決、チームの責任の放棄などに多くの人が関わります。
PagerDutyのデータによると、レスポンダーの時間の50％は、x環境、またはyサービスでの追加サポートのために誰を呼び出すのが最善かを判断する（そして実際に問題があるかどうかを見極める）ために費やされています。この統計によると、インシデントの寿命の50％は、実際の改善活動ではなく、インシデントの初期段階（診断とトリアージの段階）に費やされていることになります。
結論から言うと、インシデントごとにかかる工数と手動アクションの数は、急速に増加する可能性があります。
インシデント対応の自動化
インシデントの深刻度を診断し、何が（どのように）うまくいかなかったのかの構造を理解するなど、インシデントの初期の再発段階に自動化を適用することは、最終的なインシデントの是正を成功させるために非常に重要です。
自動化は人の観点からも重要です。インシデントが発生するたびに同じ作業を繰り返し、チームが疲弊しないようにする必要があります。診断データを第一レスポンダーが確実に利用できるようにすることは、事故対応のルーティング効率と全体的なワークフローに最も重要です。
先に進む前に、まず診断データの定義について説明します。診断データは、インシデントレスポンダーによって取得されるデータで、通常、監視ツールによって提供される情報よりも具体的です。たとえば、監視ツールは、CPUやメモリーが急増したときに警告を発しますが、インシデントレスポンダーは、CPUやメモリーを最も多く消費するプロセスを見ることで調査を行います。したがって、この場合、プロセス名またはID、およびそれらに関連するコンピューターの消費量が「診断データ」となります。
さて、Automated Diagnosticsの定義は分かりましたが、なぜ必要なのでしょうか。それは、Automated Diagnosticsを導入すると、インシデントの発生期間を短縮し、対応にかかる人数を減らすことで、インシデントのコストを削減できるからです。
MTTRの問題点
ここで「問題」という言葉は適さないかもしれませんが、最後まで読んでください。MTTRという指標は、粒度の細かい実用的な洞察を得るには広すぎるのです。MTTR（Mean Time to Repair）は、IT業界では何十年も前から保守性の指標として定番となっています。MTTRには多くの用途があり、一般的な回復速度を説明するのに適していますが、その欠点は一般的であるということです。そして今、レスポンダーの時間の50％は、追加サポートのために誰を呼び出すのが最善かを判断するために費やされていると安全に推測できるため、MTTT（トリアージまでの平均時間）やMTTI（調査までの平均時間）など、MTTRタイムライン内の他の指標にも目を向けるようになりました。
MTTI/MTTT。ITインシデントを検出してから、組織がその原因や解決策の調査を開始するまでの平均時間。MTTD（平均検出時間）からMTTR（平均修復時間）開始までの時間を表す。
PagerDutyでは、最初のレスポンダーが受任してからリゾルバーが受任するまでの時間として測定しています。この指標は、インシデント発生時に水面下で実際に何が起きているのかを知るのに役立ちます。自社のデータを観察した結果、MTTIはMTTRの中で最も時間を消費する要因の１つであると推測することができました。現代のビジネスでは、エンジニアが時間と注意を払う必要があるタスクは、ビジネスにとって高価なものなのです。 本当に 高価なものです。
Automated Diagnosticsの活用
ここで、MTTIとAutomated Diagnosticsに話を戻しましょう。MTTIは、レスポンダーが手動で診断データを取得し、xサービスとyインシデントに基づいてどのチームにエスカレーションするかを解読しなければならないという技術的タスクによって長引くだけではありません。解決に必要な専門知識によって、担当者とその制約も変わってきます。例えば、多くの場合、最初のレスポンダーは、データベースやネットワークの「視点」から問題を調査する方法を知りません。それは、彼らのスキル（データベースやネットワークのバックグラウンド）、アクセス、またはチーム的知識（例えば、特定のアプリコンポーネントがサードパーティーのサービスとの複雑なインテグレーションに依存していること）の不足が原因である可能性があります。
このような調査やデバッグの作業を自動化し、チームや担当者にこれらの作業を委ねることができれば、MTTI、ひいてはMTTRにプラスの連鎖効果をもたらすことができます。
なぜAutomated Diagnosticsにこだわる必要があるか
Automated Diagnosticsでできることは以下の通りです。
- 通常、手作業で収集される情報をファーストレスポンダーに提供するパスを設計することで、希少な専門家へのエスカレーションを削減
- 対応チームに専門知識を共有
- ファイアウォールやVPCの背後にある安全な自動化の呼び出し
- 人の手を借りずにトラブルシューティングと解決を迅速化
- 新人エンジニアへの教育のスピードを向上させ、インシデント対応組織の全レベルで最適な効率性を確保
始めましょう
あなたは決断しました。今こそ道を切り開く時ですが、何から始めればいいのでしょうか。
マーケティングのスラングを使えば、「海を沸かそうとしてはいけない（訳注：無理な仕事を引き受けてはいけない）」ということです。複雑さもリスクも低いアクションをいくつか試してみてください。例えば、最もノイズの多いサービスを詳しく調べたり、さまざまな監視アプリケーションから簡単なデータを取得したり、ディスクの使用状況を調べたりすることができます。しかし、この機能を長期的に展開するための戦略を持つことが重要です。確かに、多数のソースからデータを取得し、それをインシデントに追加するスクリプトを書くことは可能です。しかし、それではスケーラブルであることとは程遠くなります。
診断データを取得するために、さまざまなインフラやツールについて考えることは重要です。異機種混在のダイナミックな環境と連動するための標準化されたアプローチが必要です。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
カテゴリー ：インシデント＆アラート
