事後レビューのために停止を文書化する
先週、かなり深刻な停止が発生し、いくつかのサービスに影響が出て、お客様とのSLAから外れました。すべてが解決されたので、事後レビューを実施しています。
このレビューから、停止、その影響、対応、および解決策を説明する内部ドキュメントを作成したいと思います。将来の再利用のために、かなり標準的なフォームを考え出したいです。以下に私の考えを含めましたが、他にどのような項目を含める必要がありますか？これがセキュリティ関連のインシデントである場合、何を追加しますか？
- 要約イベントのエグゼクティブレベルの要約。
- 影響を受けるサービス
- 影響ユーザーとSLAにどのような影響がありましたか？ドルベースのコスト、取引の失敗、顧客の喪失などはありましたか？
- 停止期間差異があった場合、影響を受けるサービスごとに
- 原因一次および二次原因を含む
- 解像度
- イベントのタイムライン通知、外部ベンダーとの連絡、顧客への通知、応答など。
- 対応の問題停止への対応で計画どおりに進まなかったのですか？正しい人に通知しましたか？ベンダーは契約上の義務を果たしましたか？
- 取るべき予防策この停止が再び発生するのを防ぐ、またはその影響を減らすにはどうすればよいですか？
- 検出方法この停止をどの程度適切に検出し、将来的にどのように検出を改善しますか？
- 将来の停止応答で行う変更
投稿を1つの項目と説明に抑えるようにしてください。この投稿は、投票数の多い回答で更新できます。
予防策でカバーできますが、実際の症状とは何か、どのように検出できるかを記録するために使用できる検出方法セクションを用意することをお勧めします。理想的には自動化を使用して、問題が再び発生した場合（より速く）。
いいね。私は以下を追加するだけです：
影響/結果：停止の結果はどうなりますか？影響を受けた人、違反したSLA（ある場合）、ノックオン効果はありましたか？
影響を受けるサービスと停止期間は、停止がどれほどひどかったかを示すだけです。また、ビジネスへの影響を知りたいと思います。
影響：これはユーザーにどのような影響を及ぼし、どのように認識されましたか？これにはどれくらいの費用がかかりましたか（SLAの欠落、注文の紛失など）？
公開リリースと内部リリース
これは経営陣が決定するためのより多くのことですが、とにかくそれについて顧客にリリースすべきものやあなたの推薦を含めるべきかもしれません。また、どちらの方法でも、何かをリリースする前に、顧客にリリースされる内容の正確な表現について経営陣から承認を得ます。
公開リリースをこれに含める必要があります。そうすれば、社内の誰もが顧客に何を伝えることができるかを知ることができます。