外部沟通指南
关于在事件期间如何管理外部沟通的信息。请参阅我们的角色描述，了解谁负责外部沟通。
何时公开沟通#
在决定沟通事件之前，重要的是要有一套商定好的标准，用于确定何时沟通重大事件。误报和短暂问题有时会触发事件通话，因此了解何时进行沟通将有助于客户避免广泛的恐慌。这可以与您组织的什么是事件的定义和/或您的严重性级别相关联。
您可能还考虑以下标准：
- 哪些产品受到影响？
- 使用受影响的程度如何？
- 有多少客户受到影响？
- 影响有多明显？
- 客户是否可能希望为此影响准备应急措施？
我们还建议为事件的不同阶段制定一套模板，包括以下沟通选项以及特殊情况（长时间运行的事件、小范围或有限客户影响、立即解决的事件等）。
如何沟通#
初始沟通：#
第一次沟通应表明正在调查事件。这里的目标是避免客户经历事件的症状，检查状态页面或Twitter账户，但没有看到企业对问题的认识。
- 初始沟通的决定和发布应在启动事件通话后的5分钟内完成。
- 这些消息应完全模板化以方便操作。
- 这些消息可以最小限度地揭示可能尚未确定的范围，但应表明范围即将到来。
第二次沟通：初始影响范围#
这是一条应在第一次沟通后的5分钟内发送的消息，一旦了解了某些影响范围。此帖子应概述：
- 客户影响
- 受影响的组件和/或功能更新
- 受影响的地区。
更新#
根据事件的长度，需要定期更新。这些更新应从范围更新开始，在前两个小时内至少每20分钟发送一次。两小时后，您可以选择减少频率并切换到长时间事件沟通模型（见下文）。无论预期的频率如何，当影响程度有实质性变化时，应发布更新。这些更新应：
- 指出任何影响和/或范围的变化
- 如果我们认为已经进入恢复和/或缓解步骤，应予以说明。
- 提供下一次更新发布的时间预期。
与客户支持或客户成功有特殊合同的客户，如高级支持计划的客户，也应通过客户联络或其账户团队单独接收影响沟通。
长时间事件#
超过两小时的事件应被视为长时间事件，并因此有不同的沟通程序。当我们知道事件将持续很长时间时，必须适当设定客户期望，并避免因内容空洞的更新而导致的客户通知疲劳。如有疑问，请以保持更新有意义的频率通知。
- 不要在事件的第一小时内确定这一点。
- 对于我们知道将长时间恢复的事件，在已知时在更新中说明。
- 如果计划减少更新频率，请继续提供下一次更新发布的时间预期。
解决#
您的最终沟通应在事件指挥官确认事件已完全恢复时发布。此更新应包括：
- 确认完全恢复
- 明确指出任何数据丢失或持续损坏。
- 如果没有持续影响，请在更新中明确说明。
快速参考#
