共计 4042 个字符，预计需要花费 11 分钟才能阅读完成。
堪称史上增长最快的 SaaS 产品: Slack。这是一家特地神奇的 SaaS 公司，号称在没有销售团队和营销估算的状况下，成立 3 年营收增长 10 倍，一度被誉为“历史上增长最快的 SaaS 公司”。明天，咱们来看看他们的混沌工程实际。
引 子
在过来的五年中，Slack 的日活用户数超过了 1000 万，疾速的迭代和重大的架构调整撑持了 Slack 更多的性能。目前，Slack 服务曾经变成了一个硕大无朋。对于这个硕大无朋的测试，咱们遵循假如验证的迷信办法和流程。
每当启用新的性能或对其进行批改时，咱们都会测试新代码的容错能力。可怜的是，只管服务依赖的环境在发生变化，咱们也很少反复这些测试。
最后，咱们对要害零碎的韧性和可靠性充满信心，但随着工夫的推移，这些最后的测试后果就会生效，这种信念就没有充沛的根据了。
靠运气？不！咱们必须有所扭转。
当然，如果这是一个从 0 到 1 的新产品，咱们一开始就会实际混沌工程。毕竟，测试故障门路的最佳办法就是永远不要失常敞开服务。
然而，咱们并不是从零开始，咱们经营着对业务至关重要且规模宏大的服务，咱们当初最须要的是什么呢？
Slack 服务放弃尽可能的健壮性：
- 开发环境成为一个对容错测试更有信念的中央；
- 测试所有零碎（不仅仅是新零碎）；
- 不能造成影响用户的事件，所做的测试都必须平安；
- 不要虚伪的信念，所做的所有都须要在生产中进行。
在 2018 年 1 月，咱们启动了一个严格的流程：
- 辨认可能产生的故障；
- 确保服务可能容忍这些故障；
- 成心在生产中引入这些故障。
这还不是 Netflix 实际和宣传的混沌工程。这是混沌工程的第一步，咱们称之为劫难剧院。
演练筹备
每次劫难剧院的演练过程都旨在最大水平地学习，同时最大水平地降低生产事变的危险。每次演练都在一个确定且告诉到位的工夫和地点进行，所有相干的专家都在同一房间或同一视频会议中。
这一阶段，咱们尚未试图在这些演练中测试监控的局部。在演练之前，主持者们要编写一份具体的打算并宽泛分享收集反馈，因为该打算对演练的安全性至关重要。
不过这份打算外面更多是演练的内容，不会提供服务的容错原理。
主持者们负责分享他们的电脑桌面，讲出整个打算背地的思考逻辑。同时，还要精密地记录如何引发故障，将要运行的命令，以及如何抉择波及的 EC2 实例（咱们将其称为“贡品”）。
咱们还要求主持者持续记录，用开发环境的容错情况去预测生产中的容错能力，他们有多少信念。此外还包含须要监控的所有日志、指标和告警，以及在此演练过程中须要的运行手册。
最重要的是，他们须要在打算中，提出一个具体的假如，用来形容上下游零碎以及 Slack 客户端经验故障的过程。
例如，“MySQL 主服务器的终止，将导致依赖于该数据库的申请，提早减少 20 秒，而其它申请的提早不会减少，失败的 API 申请数少于 1000 个，所有这些都是因为客户端重试造成的。”
劫难来袭
在开始演练之前，咱们会审核演练打算，将 Grafana 中定义好的仪表板和 Kibana 中预置的实时搜寻后果，投到幕布上或分享进去。当初咱们筹备注入故障。
咱们先在 Slack 领有 700 多人的运维频道，发表了这项演练的开始。
在演练过程中，咱们不会进行部署或其余任何失常流动，但会让相干的人提前通晓咱们的演练打算。
在整个演练过程中，咱们会在运维频道中提供一些粗略的状态更新，而在劫难剧场的频道中提供每一步的后果。
演练总是先在开发环境中注入故障。
之后，咱们查看日志和指标，以确认故障以咱们冀望的形式体现进去。碰到问题想要修复是一种常见的本能，但在这里咱们必须管制本人，作为旁观者，监视系统的自行保护。
咱们通过应用负载平衡和流量治理的形式进行故障转移或更换容量。极少的状况，咱们会依照运行手册来复原服务。
在开发环境中注入故障后，咱们会暂停，决定是否在生产上进行同样的操作。很多时候，咱们都感觉，如果不在生产上进行，这个演练就是失败的或者节约大家的工夫。
但实际上，往往最有价值的一些经验教训反倒是来自开发环境。
如果零碎的主动补救措施不起作用，或者不能按预期奏效，亦或者破费的工夫太长，更重要的是，如果故障会导致更多的毁坏，而不是客户端提早短暂且轻微的减少，咱们会认真思考停止。
如果咱们决定终止，就会在运维频道中发表。
侥幸的是，咱们对开发环境的后果感到称心，筹备在生产环境中注入故障。咱们把 Grafana 中定义好的仪表板和 Kibana 中预置的实时搜寻，投到幕布上或分享进去，并在运维频道中发表咱们行将在生产注入故障。
最初的时刻到了，在生产中注入故障，和咱们在开发环境中所做的一样，咱们查看日志和指标，以验证咱们的假如。同时，咱们也为零碎预留了主动修复所需的工夫。
另外，这个实践上令人恐怖的时刻，实际上是相当平静的。所有的所有实现后，咱们在运维频道中发表故障全副革除。
而后，咱们开始总结和继续跟进:
- 找到问题本源和解决问题的工夫点；
- 是否有用户曾经留神到这个问题；
- 是否须要人工干预这个问题；
- 这个问题的重大水平；
- 演练打算的文档是否有过错；
- Grafana 中的仪表板是否已过期。
演练后果
咱们在 Slack 进行了数十次劫难剧院的演练。其中大多数能按计划进行，加强了咱们对现有零碎的信念，并验证了新性能的容错能力。当然，有些时候咱们还是会发现 Slack 可用性的重大问题，并在影响客户之前找到提前修复的机会。
以下是三个特地胜利的演练：
1、防止缓存不统一
第一次的劫难剧院演练，咱们把注意力投向了 memcached，用于证实在生产中主动实例替换能失常工作。
这个演练很简略，抉择将 memcached 的实例断开网络连接，察看备用实例是否能失常替换。最初，咱们复原了网络连接并终止了备用实例。
演练打算审核时，咱们发现了实例替换算法中的一个破绽，并很快在开发环境确认了它的存在。
依据最后的设计，如果实例在一组缓存键上失落了租约，而后又取得雷同的租约，则该实例不会刷新其缓存项。然而，在这种状况下，备用实例在此期间已应用了该组缓存键，这意味着原始实例中的数据已过期而且可能不精确了。
在演练中，咱们通过选定适当时间段手动刷新缓存，在演练实现后立刻更改算法，并再次进行测试来解决此问题。
没有演练发现的这个问题，咱们很可能不会觉察缓存损坏的问题。
2、为了平安重复尝试
在 2019 年初，咱们打算进行十次演练，用来证实 Slack 对 AWS 中的区域故障和网络分区的容错能力。其中一个演练波及信道服务器(Channel Server)，负责将新发送的音讯和元数据，播送到所有关联 Slack 客户端的 WebSocket 中。
这次演练的指标是将 25%的信道服务器受到网络分区的故障，并察看是否能检测到对应的故障点，零碎是否主动会将原实例替换为备用实例。
创立网络分区故障的第一次尝试失败了，问题出在提供通明传输加密的 overlay 网络。实际上，咱们对信道服务器的隔离远超出了预期，与网络分区相比，这是断开网络连接。咱们提前停下使信道服务器重新加入集群，复原网络故障。
第二次尝试好了很多，但在投入生产前就完结了。但这次演练提供了踊跃的后果，咱们发现 Consul 适宜管理网络分区上的路由。这个后果给了咱们更多的信息，但还是完结了这次演练，因为尽管做了很多工作，最终还是没有产生任何信道服务器的故障。
第三次也是最初一次尝试，咱们应用了残缺的 iptables 规定库，并胜利地将网络分区故障注入到 25%的信道服务器。Consul 迅速检测到故障，并立刻采取代替口头。最重要的是，这种大规模主动重新配置的工作，给 Slack API 带来的负荷齐全在该零碎的能力范畴内。
漫漫长路的止境，最初都是踊跃的成绩！
3、看似不可能的后果
演练也会有负面的后果。事件响应，通常波及应用自研零碎 Confabulator 进行配置更改。
在一次特地重大的事件中，Confabulator 未能按预期运行，因而咱们不得不手动进行配置更改的部署。
因而，咱们认为这个事件值得进一步考察。系统维护人员和咱们打算进行一次演练，间接模拟咱们之前遇到的情况，这将会导致 Confabulator 的网络分区，其余的零碎都运行失常，咱们也不会尝试手动更改配置。
重现了这个问题很容易，而后咱们开始跟踪代码，很快就发现了问题。该零碎的作者发现问题出在 Slack 自身宕机的状况下。
当提交的配置更改无奈验证进而无奈部署时，零碎就会利用一种紧急模式，间接跳过了验证过程。然而，在失常模式和紧急模式中，零碎都会试图将配置更改的告诉公布到 Slack 通道。该操作恰好没有设置超时，只管配置 API 是有超时的。
因而，即便在紧急模式下，如果 Slack 自身处于敞开状态，该申请也永远无奈进行配置更改的部署。
这个演练之后，咱们对代码和配置部署进行了很多的改良，并审核了这些要害零碎中的超时和重试策略。
将来瞻望
劫难剧院演练，已对 Slack 要害零碎的容错能力进行了定期且平安的验证，帮忙咱们理解和进步了 Slack 服务的可靠性。
在咱们拓展和迭代产品时，这是博得并放弃客户信任度的最重要因素之一。
下面提到的三个演练，加强了 Slack 服务的健壮性，并建设或纠正了咱们对系统容错能力的信念。
咱们的韧性工程团队会始终一直地拓展和迭代这个过程。当然，咱们打算进行更多的劫难剧院演练。
起源：混沌工程实际 首发：slack.engineering
作者：Richard Crowley 译者：龙坞道长
题目：Disasterpiece Theater: Slack’s process for approachable Chaos Engineering
申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。
6 月每周四晚 8 点，【冬哥有话说】” 玩转 ” 系列。公众号留言“玩转”可获取地址
- 0603 无敌哥《IDCF 人才成长地图与 5P》（《端到端 DevOps 继续交付 (5P) 精品课》第 1 课）
- 0610 冬哥《带你玩转翻新设计思维》
- 0617 无敌哥《麻利项目管理到底是个啥》
- 0624 冬哥《VUCA 时代的麻利领导力》
