インシデント対応のベスト プラクティスとヒント

1. 常に備えておく

インシデント対応者が「備える」には、チームが最小限の遅延時間でアクセスする必要があるすべての重要な情報が必要です。たいていはデジタル ドキュメントですが、インシデント対応者にとっては一元的な開始ポイントとして役立つでしょう。

これにはさまざまなものが含まれます。

• インシデント対応計画
• 連絡先リスト
• オンコール スケジュール
• エスカレーションポリシー
• 会議ツールへのリンク
• アクセス コード
• ポリシー ドキュメント
• テクニカル ドキュメントとランブック

2. ランブックに従う

ランブックは、特定のシナリオでどのようなステップを実行すべきかについてのガイダンスを示すものです。システム エキスパートがすぐに対応できない場合にオンコール ローテーションに取り組んでいるチームにとっては、ランブックが特に重要です。しっかり整理された一連のランブックがあれば、チームはより迅速に対応できるようになり、インシデント対応プラクティスの共有ナレッジ ベースを構築できます。

3. カオスを受け入れて安定を促進する

カオス エンジニアリングは、システムをより堅牢に構築する方法を理解するために故意に障害を組み込んで、システムを実験する手法です。その一例が Chaos Monkey です。もともと Netflix で開発された Chaos Monkey は、本番システムを意図的にオフラインにすることでネットワークの復元性をテストするツールです。

4. NOC の枠に囚われずに考える

従来、NOCs (Network Operations Centers) は、大規模な IT システムの監視およびアラート ハブとして機能していました。このプロセスは、最新のインシデント管理ツールによって大幅に合理化できます。定義されたアラート タイプ、チーム スケジュール、エスカレーション ポリシーに基づいてアラート配信ワークフローを自動化することで、人的ミスや遅延の可能性を回避できます。

5. 悪化させるのではなく集約する

複数の監視ツールからアラートの集中砲火を受けるほど最悪の事態はないでしょう。アラートのフローを 1 つのツールで一元化すれば、ノイズをより適切にフィルターできるため、チームは注意を向けるべき課題にすばやく集中できます。

6. 知識は力であることを念頭に置く

基本的なアラートは何か問題があることを伝えてくれますが、必ずしもそれが何であるかを表しているとは限りません。このため、チームが原因を調査して特定する必要があるときに、不要な遅延が生じます。アラートがトリガーされた理由に関する技術的な詳細をアラートと組み合わせることで、修復プロセスをより迅速に開始できるようになります。

7. アラートに関するアラートを用意する

「quis custodiet ipsos custodes (誰が見張り役を見張るのか)」というラテン語の慣用句は、普遍的な問題を突きつけています。IT チームと開発者チームが採用する監視ツールは、保護する対象であるシステムと同じくらいインシデントやダウンタイムに対して脆弱です。総合的なアラート プロセスを採用すると、システムとそれらを監視するツールの両方の正常性を常にチェックできます。

8. 被害を抑える

トリアージを行う医師は、発生する事態をすべて解決しようとして行き詰まってしまうと、さらに大きな危険が生じることを承知しています。このような医師は、救急処置に対応した施設への移動に間に合うだけ患者を安定させる、短期的な措置に焦点を当てています。技術分野では、封じ込め措置は一時的なソリューション (ネットワークの分離、ビルドの回帰、サーバーの再起動など) に重点を置いています。これらのソリューションによって、少なくともインシデントのスコープを限定するか、可能であればシステムをオンラインに戻します。

9. 1 人で進めない

IT チームと DevOps チームにおけるヒーローを崇める文化は、すたれつつあります。システムをオンラインに戻せる唯一の人物であっても、ただ 1 人のエンジニアが夜間と週末の勤務を際限なく続けることは、もはや時代遅れです。代わりに、チームがまさにチームとして働くのです。このチームの鎖全体の強度は最も弱い輪の強度と等しいため、たった 1 人の超人を育成するのではなくチーム全体を育成することに取り組む必要があります。

10. 透明性を高める

ユーザーがサービスの中断に遭うと、このインシデントがただちに公開されることがよくあります。これに先んじて対処するには、チームがインシデント コミュニケーション計画を実施する必要があります。その目標は、中断が発生していることを公表することで顧客の信頼を得て、それを解決するための措置が取られていることを顧客に保証することです。このような情報の配信には、Statuspage などのツールが最適です。

11. 失敗から学ぶ

IT チームと DevOps チームの「重大な機能停止」の見直しにしか時間を割けないという声は、大きくなっています。ここから開始することをお勧めしますが、長引く影響をもたらす可能性のある小さなインシデントが見落とされることが多々あります。すべてのインシデントについて詳細なレポートが必要なわけではありませんが、事後分析は必ず役に立ちます。

12. 根本原因を見つける (根本原因がありません!)

本当に根本原因はあるのでしょうか? インシデントを分析する際は、特定可能な「根本」原因を 1 つ名指しできることは稀です。多くの場合、システムは複雑で相互に依存しすぎているため、インシデントの唯一の根本原因を定義できません。根本原因が明らかな場合でも (たとえば、アプリケーションをクラッシュさせるキーストロークのエラー)、たいていは、アプリケーションのクラッシュを許してしまった (またはそれを妨げなかった) 外部要因を理解することに意味があります。複数の根本原因を探して、インシデントをより深く理解してください。

13. 誰も責めない

インシデントの事後分析の目的は、何がうまくいかなかったか、将来同様のインシデントを避けるために何ができるかを理解することです。重要なのは、このプロセスを使用して誰かに責任をなすりつけるべきではないということです。なぜなら、「何が」ではなく「誰が」に焦点を当てているチームが感情に任せて分析すると、何が起こったのかを真に理解することから分析の対象が離れていってしまうからです。

最後に

最新のインシデント管理環境では、変化のみが常態化しています。つまり、システムは絶え間なく、さまざまな新しい形で継続的にストレスを受けています。このことを理解しているチームは、それ事態が問題なのではなく、システムにいつ障害が発生するかが問題なのだということも理解しています。これらの障害に備えるための措置を講ずることを継続的な成功の重要な要素として認識して、エンジニアリング チームの DNA に組み込む必要があります。