如何在事件期间与客户交谈
在事件中经常忽略的一点是，我们如何与客户沟通，并让他们放心。当涉及到合同续约期时，你如何将事件传达给为你的服务付费的人可能会产生很大的不同。在过去的一家公司，我们的销售团队定期从客户会议中反馈，他们经常提到SRE团队的状态页面更新是多么有帮助和令人放心，即使在我们的服务完全关闭的情况下也是如此。我们需要停止将我们的客户视为非技术儿童，并向他们提供信息，帮助他们从长远来看更可靠地使用我们。
技术团队与客户最可能也是最简单的联系方式是状态页。当你怀疑是第三方引起问题或行为不端时，它是第一个停靠的端口。只要它为人们提供了查看OnCall团队在事件期间发布的带有时间戳的更新的功能，那么您的OnCall团队看起来是什么样子就无关紧要了。
一个好的状态页面有助于与我们的用户建立信任，并显示我们在事件发生期间的行为方式，以及我们不仅致力于减少事件的数量和影响，而且对事件保持透明(有时分享您的错误是羞愧地修复它们的好方法！)。
这将是过去和现在事件的持续记录，这样我们的客户就可以对以下问题有一个合理和当前的想法：1)我们的服务执行情况如何；以及2)他们遇到的问题是与更广泛的问题有关还是仅仅与他们有关。
假设您遵循类似事件指挥系统的操作，则此任务既可以由事件指挥官完成，也可以委托给其他人完成。这取决于领导事件的人来决定谁更新以及他们多久更新一次。
直到我们发布了一些东西，我们的用户才会知道我们知道有问题，并正在努力减轻它。一般来说，如果你在一家大公司工作，你会经历大量的电子邮件来支持“我的狗屎坏了，哟！你的状态页在哪里？“。虽然你永远不可能消除所有这些问题，但一旦你收到事故的警示，就立即发布一些信息肯定会大大减少这些问题(而且你的客户会因此而更欣赏你)。
话虽如此，但更新的速度是有权衡的。您需要在提供准确和相关的信息(事件的确切影响和实际开始时间)和快速响应之间找到平衡。这里没有明确的答案，这主要是你通过经验得出的结果，但请记住：你可以随时更新状态页面，让它稍后变得更具体，与其等待太长时间，不如更快地犯错误。
团队应该坐下来决定用于未来事件的适当间隔。在过去，我发现以20分钟的间隔作为起始点已经足够好了。
在这种情况下，你的目标应该是每隔20分钟更新一次相关信息-不要复制和粘贴相同的消息。如果我们现在没有要添加的新信息，那么可能是时候考虑增加更新间隔了。
增加间隔应在更新中明确说明。如果我们从20分钟移动到1小时，我们应该说明当前的影响，并说如果更多的信息变得相关，我们的客户应该在一小时或更短的时间内得到更新。
如果甲板上没有足够的人手，增加间隔也是一个很好的方法，可以将额外的人从沟通角色中解放出来。
给人们一个合理的时间框架来获取更多信息，可以缓解压力，并允许他们在依赖我们的服务时计划自己的缓解策略。我们也不希望有人疯狂地刷新我们的页面数小时，等待没有更新。
我敢打赌，手头有一群技术撰稿人帮你写最新消息，你一定不走运，所以这些消息都会落到普通的老工程师手中。这也意味着我们不指望你写下一部文学杰作。我们希望实现的目标是：
花些时间考虑沟通的正确基调，也许可以写一份文档，为团队概述一些常见的例子。
标题是更新的一个非常重要的部分。有时，这是用户在决定是否单击查看其余内容之前看到的唯一内容，因此我们需要帮助用户回答以下问题：“我需要关心这个吗？”我们该怎么做呢？通过尽可能清楚地说明它对他们的影响。
要好得多，并且清楚地识别受影响的服务、要查找的症状以及这可能如何影响客户。
你是如何写这篇文章的，归根结底是经验和同理心的混合。您需要设身处地为您的客户着想，并思考“如果我看到这个事件，我会关心什么？”
问题开始的确切时间。请确保包含时区以避免歧义。同样重要的是要注意，这不一定与您打开状态页或收到问题警报的时间相同。
清楚地描述什么是受影响的，什么不受影响。这应该包括客户可以用来诊断其特定问题是否与事件相关的信息。这也是一个很好的时间来说明哪些事情没有受到事件的影响，并缓解一些压力。例如：如果您摄取用户数据，但只是在处理它时出现延迟，那么最好声明摄取不受影响，并且没有用户数据丢失。
更新的确切时间以及问题已解决的时间。同样，对于时区，这些将帮助客户构建时间表，以便与他们自己的日志进行比较。
问题的技术描述。你的客户比你想象的要聪明，应该像对待成年人一样对待他们。坦诚地沟通问题是什么，因为这也会建立对下一个要素的尊重。
我们正在做些什么来解决这个问题呢？不要只说“我们正在处理这种情况”或“我们正在实施补救措施”，因为这对你的客户不公平。当您为事件创建尸检时，这也将对您非常有用。
看在上帝的份上，请不要一遍又一遍地复制和粘贴同一信息的相同变体。
这些都是事后检查的例子，但是您会注意到很多语言都是相同的，有些还包括所有的状态更新。它们都是有用的例子，既有状态更新，也有尸检，我强烈推荐阅读所有不同的风格。
