correction of error (COE) を開発すべき理由

アプリケーションの信頼性は非常に重要です。サービスの中断はマイナスのお客様体験となり、お客様の信頼とビジネス価値を低下させます。Amazon で学んだベストプラクティスの 1 つは、インシデント発生後の分析のための標準的なメカニズムを持つことです。これにより、インシデント発生後にシステムを分析し、今後の再発を防止することができます。また、インシデントの発生は、システムおよびプロセスがどのように機能するかについて理解を深めるのにも役立ちます。その知識は、特定のインシデントの再発防止だけでなく、他のインシデントシナリオに役立つアクションにつながることがよくあります。このメカニズムは、Correction of Error (COE) プロセスと呼ばれています。事後分析は COE プロセスの一部ですが、障害を文書化するだけではなく、是正措置に焦点を当てる点がポイントです。このブログでは、インシデント発生後の COE メカニズムを導入すべき理由と、その構成要素について説明します。

なぜ COE を行う必要があるのか

COE プロセスは、事後分析で構成されています。COE プロセスを開始する前に、イベントによって引き起こされた負の影響を軽減しておくことが不可欠です。これにより、次のことが可能になります。

イベントに至るまでの一連の流れを深く掘り下げる
問題の根本原因を特定し、改善策を特定する
インシデントがビジネスやお客様に与える影響を分析する
問題の再発を防止するためのアクションアイテム特定し、追跡する

COE とは

問題の責任者を特定するプロセスではありません：COE の目的は、最も改善が必要な領域を最大限に可視化することです。問題を表面化させれば報われる風土を築くことで、改善が必要な領域がより明確になります。人間は、報われる行動を繰り返し、ペナルティーを受ける行動を制限する傾向があります。

悪いイベントの発生後に罰を与えるプロセスではありません：COE プロセスの目的は、アプリケーションのライフサイクルの中で、継続的に改善を行うことです。多くの場合、あるイベントに最も詳しい人物は、その結果に最も影響を受ける人物です。イベントの経過をより完全に理解できるようにするには、イベントの完全な開示に報い、悪い結果に最も近い人物が問題の一部ではなく、解決策の一部になれるような文化を作る必要があります。

COE の構成要素とは

COE プロセスの結果は、AWS System Manager Incident Manager などのツール (試すにはここをクリック)、もしくは少なくとも次のセクションを含む文書で記録する必要があります。

インシデントの概要

このセクションは最初のセクションであるにもかかわらず、最後に書くべきものです。このセクションは、イベント全体の背景を説明するものです。誰が、いつ、どこで、どのように影響を受けたのか、詳細を記述してください。問題を発見するまでにかかった時間の詳細も含め、問題をどのように軽減したか、また再発防止策をどのように講じるかをまとめます。ここにすべての詳細を記入しようとせず、インシデントに関する基本的な情報を記載します。インシデントの概要は、読者が他のセクションを参照する必要が無く単独で成り立つものでなければなりません。会社の主要な利害関係者 (CEO など) へ更新情報を電子メールで送信するように記述します。
AWS Systems Manager Incident Manager COE テンプレートを使用する場合は、ここの手順でテンプレートに含まれないセクションを追加できます。

影響

お客様やビジネスにどれだけの影響があったかを定量化できる方法で調査し、文書化します。そのためには、影響を受けたお客様数と、受けた影響について詳細な情報を収集することが重要です。お客様への影響を説明するアウトラインは、次のようなものです。

影響を受けたお客様の数は？
- お客様またはビジネスに与える影響の説明
- どの程度の影響があったのか、具体的には以下の例が考えられます。
  - お客様に過大請求があったか？
  - ソーシャルメディア統計（センチメント）
  - 金銭的損失の推定値または実測値による影響の記述
  - お客様への副次的な影響があったか？
    - 障害により、お客様のビジネスや日常業務にどのような影響があったか？
  - 評判：お客様の取引を遅らせたのか、それともお客様を完全に失ったのか
どのような非機能要件が影響を受けたか？
- セキュリティ（機密性、完全性、可用性）、信頼性、パフォーマンス効率、コスト最適化、運用への影響
インシデントの結果、何が発生したか？
- このインシデントにより他のインシデントが発生したか？
- このインシデントは、ワークロードの運用以外にも影響を及ぼしたか？例えば
  - 機会喪失（競争力のある契約を獲得できなかった、販売出来なかったために X ドルの損失など）
  - SLA、契約要件、規制要件を満たすことができず、罰則が発生した。
  - お客様センチメント把握
    - 評判の失墜
    - お客様信頼度の低下

タイムライン

タイムラインには、インシデント中に発生したすべてのイベントを記述しています。インシデントに関連する最初のイベントから、システムが通常のオペレーションに戻った瞬間までをカバーしています。タイムラインには、発生したすべてのことと、インシデント中に得られたすべてのイベントと情報が明確に示されます。COE 活動によるアウトプットの質は、それを構築するために使用されるデータの品質に依存します。
タイムラインは、何がいつ起こったのかを箇条書きで説明することを推奨します。詳細なタイムラインを作成することが重要です。これにより、作成者とレビュー担当者はインシデントがどのように管理されたかを理解できます。タイムラインを確立する際には、次のことを考慮することが重要です。

一連のイベントを時系列で表現します。
一連のイベントのタイムゾーンを統一します。
タイムラインは、イベントに対するチームの認識だけでなく、開始時間と終了時間を含むイベントに焦点を当てます。
タイムラインは、チームが通知を受けたときだけでなく、問題につながった最初のきっかけ (デプロイの不良など) から開始します。
タイムラインに 10～15 分を超えるギャップがある場合は、COE の今後のセクションで明確に説明します。
タイムラインの各項目は、前の項目から明確に続いている必要があります。タイムラインは、インシデントについて他の人にストーリーを伝えるものです。
時刻を記録するときは、必ずタイムゾーンを含めて、タイムゾーンが正しく使用されていることを確認します (例：PDT vs PST)。さらに良いのは、UTC を使用するか、タイムゾーンの中央の文字を省略することです (例：「PT」)。
できる限りデータによる裏付けを行います。可能な場合、外部のアイテム、画像、または成果物 (ダッシュボード、またはその他の情報ソース) にリンクします。

評価指標

このセクションには、影響、問題の特定方法、およびイベントを監視するための設定方法を定義する指標が含まれています。これらの指標がない場合、それは危険信号であり、後のセクションに含めるべきアクションアイテムである可能性があります。

インシデントに関する質問

タイムラインができたら、イベントを分析するための質問を行い、インシデントの重要な側面の特定を始めます。質問では、次のようなインシデントの重要な側面に焦点を当てる必要があります。

検出
- お客様への影響があることを知ったのはいつですか？
- お客様への影響があることをどのように知りましたか？
  - お客様からの報告
  - 監視やアラートによる特定
- どうすれば検出時間を半分に短縮できますか？
診断
- お客様への影響の根本的な原因は何でしたか？
- インシデント発生中にメンテナンスウィンドウが行われていましたか？
  - メンテナンスウィンドウは適切にアナウンスされていましたか？
  - サービスオーナーはメンテナンスウィンドウについて知っていましたか？
  - バックログに、依存関係を解消するタスクがありますか？
    - なぜそれが実施されなかったのですか？
  - どうすれば診断時間を半分に短縮できますか？
緩和
- お客様への影響がインシデント前のレベルに戻ったのはいつですか？
- システム所有者は、システムが正常に復旧したことをどのようにして知ることができますか？
- 問題を緩和する場所と方法をどのように決定しましたか？
- どうすれば緩和までの時間を半分に短縮できますか？

AWS Systems Manager Incident Manager COE テンプレートには、これらの質問の一部が含まれています。テンプレートをカスタマイズすれば、各キーアスペクトのコメントセクションに質問を追加できます。

予防
- 今後発生するイベントを防止するためには、何が起こったのかだけでなく、なぜ起こったのか、根本的な原因を完全に理解する必要があります。
- 何段階にも掘り下げて初めて、そのイベントが再発するのを防止するために十分な情報を得ることができます。
- Amazonで使っている根本原因を特定するための仕組みは、「5 Why」と呼ばれています。

5 Whys

5 Whys は、原因を理解するための一貫したアプローチとして有効です。それは私たちの思い込みを克服するのに役立ちます。このプロセスは、個人でもチーム全体でも、簡単に習得し、使用することができます。5 Whys は、「誰」を非難するのではなく、「なぜ」を見つけることに重点を置き、非難しない方法で適用される必要があります。AWS Systems Manager Incident Manager COE テンプレートを使用する場合、5 Whys のセクションは、予防セクションの下にあるインシデントに関する質問の一部として含まれています。

5 Whys の手法を使用して、問題の根本原因を特定したことを確認します。原因を見つけるために、5 Whys を超える質問をする必要があるかもしれません。また、原因を防ぐことができたかどうかを検討する必要があります。たとえば、RCA に「ヒューマンエラー」が根本原因として出てきた場合、チェックやフェイルセーフの仕組みがないことを示している可能性があります。したがって、なぜヒューマンエラーが起こり得るのかを常に考える必要があります。

問題を特定します。
（1st Why）なぜこの問題が起きたのですか？
（2nd Why）ステップ2で文書化された「1st Why」に対する答えが何であれ、Why を尋ねます。
（3rd Why）ステップ3で文書化された「2nd Why」に対する答えが何であれ、Why を尋ねます。
（4th Why）ステップ4で文書化された「3rd Why」に対する答えが何であれ、Why を尋ねます。
（5th Why）ステップ5で文書化された「4th Why」に対する答えが何であれ、Why を尋ねます。
Why の回数に関係なく、このイベントの発生を許した一連のイベントが完全に明らかになるまで、このプロセスを続けてください。
Why に対するそれぞれの回答を改善するための計画を立てます。これにより、イベントの症状だけでなく、そのイベントの発生を許した一連のイベントを改善することができます。

例

問題は X です。
#1 なぜ X が起きたですか？
- X が起こったのは、このアクションが行われたからです。
#2 なぜそのアクションが行われたのですか？
- タイプミスがあったため、このアクションは行われました。
#3 なぜタイプミスが許されたのですか？
- 検証がなかったため、入力ミスが許されました。
#4 なぜコードの検証がなかったのですか？
- 現在のプロセスはコードの検証を行われていません。
#5 なぜ現在のプロセスではコードの検証がおこなわれないのですか？
- コードの入力に使用するシェルにその機能がないからです。

それぞれの Why に答えられたら、次の質問を考えて、プロセスを続ける必要があるかどうかを判断します。必要に応じて、その理由を問題点として、このプロセスを繰り返します。根本原因を発見したと確信した時点で、やめてください。

Why の理由は根本的な原因ですか？
理由は、それが起こる前に検出できましたか？
理由はヒューマンエラーですか？もしそうなら、なぜそれが起こりえたのですか？

上記の例では、対処すべきポイントが 5 つあります。

アクション X の影響を是正する必要があります。
コマンドの再実行が必要な場合、タイプミスを避ける必要があります。
コードの検証を実装する必要があります。
コードの検証を確実に行うために、現在のプロセスを修正する必要があります。
コードに使用するシェルは、コードの検証を行う必要があります。

アクションアイテム

アクションアイテムは、COE プロセスの主な成果です。目標は、将来同じ問題の予防、診断、根本原因の解決といったプロセスを改善するための活動を特定することです。各アクションアイテムには、優先度、責任者、および終了期限を明記する必要があります。よいアクションアイテムは、具体的で、特定のタイムライン内で達成可能なものです。たとえば、社内 SLA は 14 日で、COE が平均 6 ～ 8 個のアクションアイテムがある場合です。

まとめ

本ブログでは、COE のプロセスを持つことの重要性と、その主な構成要素について説明しました。独自のプロセスを実装し始めるには、このブログを参考にして AWS Systems Manager Incident Manager COE テンプレートを使用することをお勧めします。学び、より良くするための最善の方法は実践することですので、準備を始めて、最初のインシデントに取り組むことをお勧めします。

著者について

翻訳はソリューションアーキテクトの村田が担当しました。原文はこちら。

Amazon Web Services ブログ