史上增长最快的SaaS公司-Slack的混沌工程实践

另外，这个理论上令人恐惧的时刻，实际上是相当平静的。所有的一切完成后，我们在运维频道中宣布故障全部清除。
然后，我们开始总结和持续跟进:

找到问题根源和解决问题的时间点；
是否有用户已经注意到这个问题；
是否需要人工干预这个问题；
这个问题的严重程度；
演练计划的文档是否有差错；
Grafana中的仪表板是否已过时。

演练结果
我们在Slack进行了数十次灾难剧院的演练。其中大多数能按计划进行，增强了我们对现有系统的信心，并验证了新功能的容错能力。当然，有些时候我们还是会发现Slack可用性的严重问题，并在影响客户之前找到提前修复的机会。
以下是三个特别成功的演练：
1、避免缓存不一致
第一次的灾难剧院演练，我们把注意力投向了memcached ，用于证明在生产中自动实例替换能正常工作。
这个演练很简单，选择将memcached的实例断开网络连接，观察备用实例是否能正常替换。最后，我们恢复了网络连接并终止了备用实例。
演练计划审核时，我们发现了实例替换算法中的一个漏洞，并很快在开发环境确认了它的存在。
根据最初的设计，如果实例在一组缓存键上丢失了租约，然后又获得相同的租约，则该实例不会刷新其缓存项。但是，在这种情况下，备用实例在此期间已使用了该组缓存键，这意味着原始实例中的数据已过时而且可能不准确了。
在演练中，我们通过选定适当时间段手动刷新缓存，在演练完成后立即更改算法，并再次进行测试来解决此问题。
没有演练发现的这个问题，我们很可能不会察觉缓存损坏的问题。
2、为了安全反复尝试
在2019年初，我们计划进行十次演练，用来证明Slack对AWS中的区域故障和网络分区的容错能力。其中一个演练涉及信道服务器(Channel Server) ，负责将新发送的消息和元数据，广播到所有关联Slack客户端的WebSocket中。
这次演练的目标是将25％的信道服务器受到网络分区的故障，并观察是否能检测到对应的故障点，系统是否自动会将原实例替换为备用实例。
创建网络分区故障的第一次尝试失败了，问题出在提供透明传输加密的overlay网络。实际上，我们对信道服务器的隔离远超出了预期，与网络分区相比，这是断开网络连接。我们提早停下使信道服务器重新加入集群，恢复网络故障。
第二次尝试好了很多，但在投入生产前就结束了。但这次演练提供了积极的结果，我们发现Consul适合管理网络分区上的路由。这个结果给了我们更多的信息，但还是结束了这次演练，因为虽然做了很多工作，最终还是没有产生任何信道服务器的故障。

史上增长最快的SaaS公司-Slack的混沌工程实践 | IDCF( 三 )