インシデント対応の重要性
このラーニング パスから別のモジュールで説明されている監視の原則とプラクティスを基にして、監視によって問題が見つかった場合の対処方法を学習します。 システムが想定どおりに動作していないことを通知するアクション可能アラートを受け取った場合は、その問題に対処するための対応のトリガーとなります。
インシデントとは何でしょうか。
インシデント対応とは、インシデントが発生したときにとる行動のことですが、インシデントを構成するものは正確には何でしょうか。 この答えは主観的である可能性があります。インシデントとは何かについて、エンジニアでも全員が同意することはありません。 さまざまな業界や組織にわたってこの質問をすると、さまざまな回答が得られます。
お客様が影響を受けるかどうかにかかわらず、すべての中断をインシデントとしてラベル付けする人もいるでしょう。 このモジュールのコンテキストでは、インシデントをサービスの中断として定義することに同意できます。つまり、ユーザーが依存しているサービスを使用できるかどうかに影響する出来事または状態です。 たとえば、システムがダウンしている場合や、顧客に影響を与えるような誤動作が生じた場合などです。
インシデント対応とは
すべての問題の防止は、すばらしいゴールですが、不可能です。 物事はおかしくなるものなので、エンド ユーザーへの影響を制限し、可能な限り迅速にオペレーションを正常に戻すための計画が必要です。
重要なのは、反応することではなく、"緊急に対応する" ことです。 反応は、長期的な効果を考慮せずに、現時点に基づいた衝動的なものになる傾向があります。 対応は、情報に基づいて十分に考慮され、整理されたものです。
あなたのインシデント対応のアプローチによって、次のような有効性が決まります。
- 何が起きているのかを把握する (問題の診断)。
- トリアージ (緊急度の判断) と問題の優先順位付けを行う。
- 適切なリソースを活用して問題を軽減する。
- 問題について利害関係者との連絡を取る。
問題を修復した後は、インシデントの事後レビュー プロセスを通じてインシデントから学ぶことができます。 これは重要な主題であり、議論する価値のある別のモジュールが用意されています。
インシデント対応パフォーマンスの測定
TTR という頭字語は見慣れているかもしれませんが、"復旧する時間"、"修復する時間"、"復元する時間" などさまざまな定義があります。これらのすべてのバリアントは同じことを意味します。顧客の期待に応えて、サービスを元の場所に戻すために必要な時間の合計です。
このメトリックは、インシデント対応においてチームがどの程度のパフォーマンスを発揮しているかを測定する 1 つの方法です。 サービスの復旧/修復/復元の速度が向上するにつれて、サービスの停止や低下による影響が少なくなります。
組織がインシデント対応をどの程度適切に処理しているかを把握しておくことが重要です。 毎年、DevOps Research and Assessment (DORA) から State of DevOps レポートがリリースされます。 2019 年のレポートでは、いくつかの重要な所見で、インシデント対応のパフォーマンスに焦点を当てています。
- このレポートで、サービスの中断を 1 時間以内に検出、対応、および修復できるエンジニアリング チームは "エリート/高パフォーマー" に分類されています。
- 24 時間以内にインシデントから復旧できる人は "中パフォーマー" に分類されています。
- "低パフォーマー" とは、サービスの中断から復旧までに 1 週間ないし 1 か月かかる人のことです。
これらのレベルの間にはかなりの差があります。 この調査で、エリート/高パフォーマー チームは "低パフォーマー" よりも 2,604 倍迅速にインシデントから復旧することがわかりました。 また、エリート/高パフォーマーでは、運用環境への展開の頻度も 208 倍になっています。
他に比べて、エリート パフォーマーはなぜ、どのようにして、これほど迅速に対応と復旧を行うことができるのでしょうか。 その理由の少なくとも一部は、問題発生時に適切な基本対応計画が既に用意されていることの重要性を彼らは理解しているという点にあります。
このモジュールでは、インシデントの特性とライフサイクル、およびその知識を使用して独自の基本計画を作成する方法について学習します。