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