向毫无戒心的工程师发送一堆 Jira 工单可能会让人感觉像是在指责和惩罚，但如果没有人负责出现，就没有人会出现。我们在这里谈论的都是技术，而不是健康紧急情况或犯罪，但旁观者效应在事后分析中也发挥着作用。
需要向特定的人员和团队分配任务，并在以后对其负责——同时也认识到他们需要额外的时间来完成正在进行的工作。
GitLab 在发生臭名昭著的数据丢失事件后，在所有权方 菲律宾电话号码数据 面做得非常出色。多年来，他们一直是一家以透明著称的公司，但他们还为与改善基础设施相关的所有其他任务和项目创建了一个元问题，以防止进一步的数据丢失问题，让任何人（包括内部工程师和客户）都可以跟踪进度甚至介入。
将事后调查结果传达给利益相关者
力求公开披露事后分析报告 — 这是向所有现有和未来客户透明披露的最佳方式。根据事件的性质（如零日网络攻击），您可能需要两个“版本”的事后分析报告 — 一个用于公开披露（删除了关键信息），另一个用于客户或监管机构，他们需要了解所有细节。
事后分析并不是进行产品营销式沟通的地方，但你确实需要时刻仔细考虑你的语言——为了防止最后一刻的沟通失误，请不要：
最小化影响在发生中断或数据丢失事件时，反复强调只有“ 3-5％ 的客户” 受到影响 — — 这并不能降低事件的严重性，而且会降低受影响客户的价值。
像Kagi 的人们一样，把这一切都归结为巧合。事件可能感觉只是因为一系列类似《死神来了》的不幸事件而发生，但如果你问“为什么”至少五次，你几乎肯定会得出不同的结论。
不要把责任推给供应商、依赖项或第三方——你仍然选择依赖他们，所以你仍然要负责。如果供应商发生故障，而你的系统像下一张多米诺骨牌一样倒下，那么这次事故也归咎于你。
正如一位 Hacker News 用户在回应Cloudflare 事后分析时所说，“这篇文章的大部分内容都公开指名道姓地将责任推给供应商，并推测其根本原因，这是一个有趣的选择。……我理解并支持解释事件的起因并提供一些背景信息，但事后分析的重点应该放在你的事件上，而不是你的供应商的事件上。”