翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ステージ 5: 応答して学習する

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

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

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

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

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

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

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

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

運用レビューの実施

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

社内のエンジニアリングコミュニティに運用レビューを開いて、ビジネスを運営する IT アプリケーションと、それらが遭遇する可能性のある問題の種類について詳しく知ることができるようにします。この知識は、ビジネス用の他のアプリケーションを設計、実装、デプロイする際に活用できます。

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

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

アラームの精度

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

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

誤検出

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

偽陰性

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

重複アラート

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

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

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

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

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

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

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

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

レジリエンスを深く実装する

前述のように、高度な組織はアラームに対して複数の応答を実装します。レスポンスが有効である保証はありません。そのため、レスポンスをレイヤーすることで、アプリケーションが適切に失敗する準備が整います。各インジケータに少なくとも 2 つのレスポンスを実装して、個々のレスポンスが DR シナリオにつながる可能性のある単一障害点にならないようにすることをお勧めします。  これらのレイヤーは、前のレスポンスが無効な場合にのみ連続したレスポンスが実行されるように、シリアル順に作成する必要があります。1 つのアラームに対して複数のレイヤードレスポンスを実行しないでください。代わりに、レスポンスが失敗したかどうかを示すアラームを使用し、失敗した場合は次のレイヤードレスポンスを開始します。