ステージ 5: 対応と学習

アプリケーションによる中断を伴うイベントへの対応は、その信頼性に影響します。経験と、アプリケーションが過去に行った中断への対応方法から学ぶことも、信頼性を向上させるために重要です。 

「対応と学習」ステージでは、アプリケーションの中断を伴うイベントへのより適切な対応のために実装できるプラクティスに焦点を当てます。また、運用チームやエンジニアの経験から最大量の学習内容を抽出するのに役立つプラクティスも含まれています。

インシデント分析レポートの作成

インシデントが発生した場合の最初のアクションは、顧客とビジネスへのさらなる損害をできるだけ早く防止することです。アプリケーションが復旧したら、次のステップは何が起こったのかを理解し、再発を防ぐためのステップを特定することです。このインシデント後分析は、通常、アプリケーションの障害を引き起こした一連のイベントと、アプリケーション、顧客、ビジネスに対する中断の影響を文書化するレポートとしてキャプチャされます。このようなレポートは貴重な学習アーティファクトとなり、ビジネス全体で広く共有する必要があります。

Amazon Correction of Error (COE) プロセスで文書化されているように、優れたインシデント分析レポートは標準化された形式に従い、アプリケーションの障害の原因となった状況をできるだけ詳細に記載しようとします。このレポートでは、タイムスタンプ付きの一連のイベントを詳述し、タイムライン上のアプリケーションの測定可能な状態を記述する定量的データ (多くの場合、モニタリングダッシュボードからのメトリクスとスクリーンショット) を記載します。このレポートには、アクションを実行したオペレーターやエンジニアの思考プロセスと、それらを結論に導いた情報を記載する必要があります。また、レポートには、発生したアラーム、それらのアラームがアプリケーションの状態を正確に反映しているかどうか、イベントと結果のアラームの間の遅延時間、インシデントの解決時間など、さまざまな指標のパフォーマンスについても詳細に説明する必要があります。タイムラインには、開始されたランブックまたはオートメーションと、アプリケーションが有用な状態を取り戻すのにそれらがどのように役立ったかも記載されます。タイムラインのこれらの要素は、問題への対処速度や中断の軽減にどの程度効果的だったかなど、自動化された対応とオペレーターによる対応の有効性をチームが理解するのに役立ちます。

この過去のイベントの詳細な実態は、強力な教育ツールとなります。チームは、これらのレポートをビジネス全体で使用できる中央リポジトリに保存し、他のユーザーがレポートからイベントを確認して学習できるようにする必要があります。これにより、本番環境で何が問題になるかについてのチームの直感力を向上させることができます。

詳細なインシデントレポートのリポジトリも、オペレーターのトレーニング資料のソースになります。チームはインシデントレポートを使用して、テーブルトップデーまたはライブゲームデーを鼓舞します。ここではチームに、レポートに記載されたタイムラインを再生する情報が提供されます。オペレーターは、タイムラインの一部の情報を使用してシナリオを順を追って説明し、実行するアクションを記述できます。その後、ゲームデーのモデレーターは、オペレーターのアクションに基づいてアプリケーションがどのように応答したかに関するガイダンスを提供できます。これにより、オペレーターのトラブルシューティングスキルが育成されるため、オペレーターはより簡単に問題を予測してトラブルシューティングできるようになります。

アプリケーションの信頼性に対する責任を担う中央集中型のチームは、組織全体がアクセスできる一元化されたライブラリにこれらのレポートを維持する必要があります。また、このチームは、インシデント分析レポートの作成方法について、レポートテンプレートとトレーニングチームを管理する責任も担う必要があります。信頼性チームは定期的にレポートを確認し、ソフトウェアライブラリ、アーキテクチャパターン、またはチームプロセスの変更を通じて対処できるビジネス全体の傾向を検出する必要があります。

運用レビューの実施

「ステージ 4: 運用」で説明したように、運用レビューでは、最近の機能リリース、インシデント、運用メトリクスについて確認できます。また、運用レビューは、機能リリースやインシデントから学んだことを組織内の幅広いエンジニアリングコミュニティと共有する機会でもあります。運用レビュー中、チームはロールバックされた機能のデプロイ、発生したインシデント、およびそれらの処理方法を確認します。これにより、組織全体のエンジニアは、他者の経験から学び、質問をする機会が得られます。

社内のエンジニアリングコミュニティに運用レビューを公開し、ビジネスを動かす IT アプリケーションと、発生する可能性のある問題のタイプについて詳しく学習できるようにします。エンジニアは、この知識をビジネス用の他のアプリケーションを設計、実装、デプロイする際に活用できます。

アラームのパフォーマンスの確認

「運用」ステージで説明したように、アラームによってダッシュボードアラート、チケットの作成、E メールの送信、またはオペレーターのページングが発生する可能性があります。  アプリケーションには、オペレーションのさまざまな側面をモニタリングするように多数のアラームが設定されます。時間の経過とともに、これらのアラームの精度と有効性を確認してアラームの精度を高め、誤検出を減らし、重複アラートを統合する必要があります。

アラームの精度

アラームの原因となった特定の中断を解釈または診断するのにかかる時間を短縮するために、アラームはできるだけ具体的である必要があります。アプリケーションの障害に対応してアラームが発生した場合、アラームを受信して対応するオペレーターは、まずアラームが伝達する情報を解釈する必要があります。この情報には、復旧手順などの一連のアクションにマッピングされる単純なエラーコードであったり、アラームが発生した理由を理解するために確認する必要があるアプリケーションログの行が含まれていたりする場合があります。チームがアプリケーションの運用をより効果的に行うには、これらのアラームをできる限り明確かつ簡潔に調整する必要があります。

アプリケーションで発生する可能性のあるすべての中断を予測することはできないため、オペレーターが分析と診断を実行する必要がある一般的なアラームが常に存在します。チームは、対応時間を改善し、平均修復時間 (MTTR) を短縮するために、一般的なアラームの数を減らすように努める必要があります。理想的には、アラームと自動対応または人間による対応との間には 1 対 1 の関係が必要です。  

誤検出

オペレーターからのアクションは必要ないが、E メール、ページ、またはチケットとしてアラートを生成するアラームは、時間の経過とともにオペレーターに無視されるようになります。  定期的に、またはインシデント分析の一環としてアラームを確認し、無視されることが多いアラームや、オペレーターからのアクションを必要としないアラーム (誤検出) を特定します。  アラームを削除するか、オペレーターにとって実用的なアラートを発行するようにアラームを改善する必要があります。

偽陰性

インシデント中にアラートするように設定されたアラームは、予期しない方法でアプリケーションに影響を与えるイベントが原因で失敗する可能性があります。  インシデント分析の一環として、発生する必要があったのに発生しなかったアラームを確認する必要があります。イベントで発生する可能性のある条件をより適切に反映するように、これらのアラームを改善する必要があります。または、同じ中断にマッピングされるが、別の中断症状によって発生する追加のアラームを作成する必要があります。

重複アラート

アプリケーションを損なう中断は、複数の症状を引き起こし、複数のアラームを引き起こす可能性があります。  定期的に、またはインシデント分析の一環として、発行されたアラームとアラートを確認する必要があります。  オペレーターがアラートを重複して受信した場合は、集約アラームを作成して 1 つのアラートメッセージに統合します。

メトリクスレビューの実施

チームは、1 か月あたりの重大度別のインシデント数、インシデントの検出時間、原因の特定時間、修復時間、作成されたチケット数、送信されたアラート、呼び出すページなど、アプリケーションに関する運用メトリクスを収集する必要があります。これらのメトリクスを少なくとも月 1 回確認して、運用スタッフへの負担、それらが処理する信号対雑音比 (情報アラートや実用的なアラートなど)、チームが制御下でアプリケーションを運用する機能を改善しているかどうかを把握します。このレビューを使用して、運用チームの測定可能な側面における傾向を理解します。これらのメトリクスを改善する方法について、チームからアイデアを求めます。  

トレーニングと有効化の提供

インシデントや予期しない動作を引き起こしたアプリケーションとその環境の詳細な説明をキャプチャすることは困難です。さらに、アプリケーションの耐障害性をモデル化してこのようなシナリオを予測することは、必ずしも簡単なことではありません。組織は、耐障害性モデリング、インシデント分析、ゲームデー、カオスエンジニアリング実験などのアクティビティに参加するために、運用チームや開発者向けのトレーニングやイネーブルメントの資料に投資する必要があります。これにより、チームが作成するレポートの忠実度と、チームが会得する知識が向上します。また、チームは、スケジュールされたレビューを通じてインサイトを提供する必要がある、より小規模で経験豊富なエンジニアグループに依存することなく、障害を適切に予測できるようになります。

インシデントナレッジベースの作成

インシデントレポートは、インシデント分析からの標準出力です。アプリケーションに障害が発生していなくても、異常なアプリケーション動作を検出したシナリオを文書化するには、同じレポートまたは同様のレポートを使用する必要があります。同じ標準化されたレポート構造を使用して、カオス実験とゲームデーの結果を記載します。レポートは、インシデントやその他の予期しない動作を引き起こしたアプリケーションとその環境のスナップショットを表します。これらの標準化されたレポートは、ビジネス内のすべてのエンジニアがアクセスできる中央リポジトリに保存する必要があります。  

その後、運用チームと開発者は、このナレッジベースを検索して、過去にアプリケーションを中断した要因、中断の原因となった可能性のあるシナリオのタイプ、アプリケーションの障害の防止要因を理解できます。このナレッジベースは、運用チームと開発者のスキルを向上させるためのアクセラレーターになり、チームや開発者が知識と経験を共有できるようになります。さらに、レポートをゲームデーやカオス実験のトレーニング資料やシナリオとして使用し、運用チームの直感と中断のトラブルシューティング能力を向上させることができます。

耐障害性を綿密に実装する

前述のように、高度な組織はアラームに対して複数の対応を実施します。対応が効果的である保証はありません。そのため、対応を重ねることで、アプリケーションのフェイルグレイスフリーに備えることができます。各指標に対し少なくとも 2 つの対応策を実施して、個々の対応が DR シナリオにつながる可能性のある単一障害点にならないように確認することをお勧めします。  これらの複数対応は、前の対応が無効であった場合にのみ連続した対応が実行されるよう、番号順に作成する必要があります。1 つのアラームに対し複数の対応を重ねて実行しないでください。代わりに、対応が失敗だったかどうかを示すアラームを使用し、失敗した場合は次の対応を重ねて開始します。