我们谈论沟通的重要性，但有时这似乎是一个模糊的话题，并不受到重视。 因此，在本节中，我们将深入探讨与DevOps相关的两个非常具体的沟通关键方面：1没有指责的事后会议，2 服务时间透明化。 现在处理这两项活动需要比平常更好的沟通技巧，因为它们经常不经意时发生。在客户受到重大停电影响后的24小时或48小时内，我们应该进行事后处理，快速解决问题，这有助于保持与客户的合作关系稳定。
在准备事后总结会议的过程中，最好让团队里每一个人协作建立一个事故发生的时间轴，而不是只安排一个领导来主持事后领责会议。开这种会议，要避免直接造成这个事故的人员参与会议，不然这个人开会过程会变得很尴尬和不适。在开始这个会议之前，建议团队所有人员尽可能多填写这个事故发生时间轴，要求是按照发生的顺序进行客观记录发生事件，覆盖整个过程。事后总结会的特点是这样的：1）就是一个普通会议，不要变成背锅会议 2）尽可能在事故发生48小时内组织会议 3）需要邀请第三方参与（现实中可能是客户）
会议应该让团队知道我们不是来指责某个人，相反，我们试图阻止类似事件在将来某些时候继续发生。重要的是每次事后总结会议之后都达到了每个人的期望。商定好讨论范围和分析事故根本原因是同等重要。你需要分析和讨论到这个事故发生的可能的各种原因。
此外，确保组内每一个人都在同一个层面上去修复这个事故所做出努力。停止不前的诱惑的确很大，但是这个时候就是你们改变和提高以及学习的时机。检查项目时间轴，确保每个人都放在项目里的正确位置，不能有些人忙死，有些人没活干。一定要讨论这个事故给客户带来了那些不好的影响和损失。最后，你肯定想问，如何在未来的项目中尽快找出类似的问题。我们都知道，软件有bug是很难避免的。我们应该优化我们的测试手段和策略，加快事故响应速度，尽可能缩短由于事故带来的宕机时间，而不是思考如何优化软件，防止事故发生
最后一步是建立保证机制或实际操作项，这些应该包括新的监控服务或测试覆盖甚至修复环境手段。 记录这些并让会议中的每个人了解和明确。在SAS产品的世界中，当您的网站或应用或服务出现故障时，它会对用户产生巨大影响。 透明的正常运行时间意味着当我们与客户互动时，我们会在停电期间尽可能地与他们进行沟通。 在Transparent Uptime博客中，Lenny Rachitsky给出了他建议作为透明正常运行时间的先决条件的四点。
首先，承认失败。客户对你有停机时间并不感到惊讶，真的可以失败，但隐瞒起来并不好。 第二，人的责任。 获得公司层听取的回应并非真正的道歉，这是很常见的。 需要真实地和真诚与客户交谈，避免在道歉时重复官方说辞。 第三，有一个沟通渠道。 确保您的客户了解它。 确保它已更新，最重要的是，确保它是对外的。第四，最重要的是，是真实的。 在发生停电的那一刻，和客户保持沟通是一个很好的办法，也很难做到，因为需要忙着处理事故。 你的团队人员，需要了解客户手头上最重要的问题并尽可能及时处理和恢复服务。
无指责的事后总结会和服务期间的透明化是两个很重要的因数，在管理你的团队和建设信任方面。
Ps： 关于无指责的事后会议，在我过往工作经历中，确实发生了不好的事情。我们服务的客户发布了新版本，但是有一个设备出现输入问题。事后召开了总结会议，负责测试的女同事压力很大。最后才知道她怀孕了，过了一段时间，人家老公和公司打官司，胎儿流产，没保住。现在看来，确实不应该让这个人参与事后总结会议，以及项目管理和公司处理都有问题。
事故发生时间轴，简单一个例子。如果发生服务器宕机或者服务不可访问，例如HTTP 500错误，建立这样一个时间轴，很有必要和好处。可以很清楚看到整个时间发生前后所有事情和补救措施。如果没有这个准备，你的老板问你，发生了HTTP 500，整个过程你们如何处理？没有一些准备，你怎么去很好回答这个问题。让他看到你们组的努力和解决问题的效率。
