事後レビュー用の停止の文書化

この1週間でかなり深刻な機能停止が発生し、お客様とのSLAから外れたいくつかのサービスに影響がありました。すべてが解決したので、事後レビューを行っています。

このレビューから、停止、その影響、私たちの対応、解決策を説明する内部文書を作成したいと思います。将来の再利用のために、かなり標準的なフォームを思いつきます。以下に私の考えを含めましたが、他にどんなアイテムを含めるべきですか？これがセキュリティ関連のインシデントであった場合、何を追加しますか？

• 概要イベントのエグゼクティブレベルの概要。
• 影響を受けるサービス
• 影響ユーザーとSLAにどのような影響がありましたか？ドル単位のコスト、取引の失敗、顧客の損失などがありましたか？
• 障害が発生した場合、影響を受ける各サービスの停止期間
• 原因一次および二次原因を含む
• 解決
• イベントのタイムライン通知の外部ベンダーとの連絡、顧客通知、応答など。
• 応答に関する問題停止に対する応答では、物事が計画どおりに進まなかったのですか？正しい人に通知されますか？ベンダーは契約上の義務を果たしましたか？
• 予防措置を講じるこの停止が再び発生するのを防ぐか、その影響を減らすにはどうすればよいですか？
• 検出方法この停止をどれだけうまく検出したか、また将来どのように検出を改善するか？
• 将来の停止対応で行う変更

投稿を1つの項目と説明にまとめてください。この投稿は、上位の回答で更新できます。

予防策でカバーすることもできますが、真の症状が何であり、問​​題が再度発生した場合に（理想的には自動化を使用して）問題を検出（どのように）できるかを記録できる検出方法セクションを用意することをお勧めします。

いいね。以下を追加するだけです。

影響/結果：停止の結果は何ですか-誰が影響を受け、どのSLAが（もしあれば）違反された場合、ノックオン効果がありましたか？

影響を受けるサービスと停止時間は、停止がどれほどひどいものかを示すだけです。また、ビジネスへの影響は何かを知りたいと思います。

影響：これはユーザーにどのような影響を与え、どのように認識されましたか？これにはどれくらいの費用がかかりましたか（SLAの不足、注文の紛失など）？

公開リリースと内部リリース

これは経営陣が決定するべきものですが、とにかく顧客にリリースすべき内容や推奨事項を含めるべきかもしれません。また、いずれかの方法で、何かをリリースする前に顧客にリリースされる内容の正確な文言について、経営陣からサインオフします。

社内の誰もが顧客に伝えることを許可されていることを知っているように、パブリックリリースをこれに含める必要があります。