停机问题 我从10次停机中学到的几个经验( 三 )


行情
git lab 2017 Postgres宕机第2集:备份脚本每天运行,将内容放入S3 …直到软件更新破坏了备份脚本。相应的修复还没有真正测试过。
第六集,GitHub的43秒网络分区:恢复需要很长时间,尤其是流量高峰期,导致站点长期降级。

第4课:分阶段慢慢部署
尽管我们尽了最大努力,错误还是会发生。我们会引入错误,或错误配置的东西,或传播错误的防火墙规则,或其他东西。
但是,分阶段部署可以将问题锁定在一定范围内,这样就可以在火势蔓延并烧毁整个场地之前看到烟雾在哪里。
我们讨论过的很多团队都有一套彻底的部署方法,确保他们的员工是第一批尝试他们的服务变更的用户,然后只有少数客户会提前尝试新的部署。
下面是一个具体的例子:
部署到您的狗食集群-每小时或每一个变更集,当前的HEAD版本将部署到您的员工。这使您自己的团队能够在客户发现问题之前提前计划。
canary Cluster——根据你的发布节奏,候选发布被推到一个小的部署中,并暴露给你的一小部分用户。一些公司会从几十个数据中心中选择一个做金丝雀;其他公司根据他们的user_id或类似的东西挑选一部分用户群进行部署。在继续之前,发行经理可能会在canary观众中仔细监控这个新版本的相应指示器…
生产。现在它正走向一个更广阔的世界。根据服务的重要性和发布节奏,有时会同时进行生产部署,有时会进一步分批部署,比如一次部署一个数据中心。
对于采用这些方法的公司来说,一些小问题通常不会被大多数用户发现,因为它们会被自用、加那利或其他阶段提前捕获。
然而,当公司不使用分阶段部署时,事情显然不会进展顺利...撰写后分析的团队通常是第一个指出分阶段部署会产生多大影响的团队。
行情
在第4集中,一个微妙的正则表达式瘫痪了Cloudflare: Cloudflare非常快地部署了一个更昂贵的基于正则表达式的规则,导致整个站点由于CPU耗尽而瘫痪
在第11集,Salesforce发布了一个有争议的事后分析:DNS配置更改的快速部署使他们所有的名称服务器离线。

第五课:为失败做准备,提前写好策略和计划
最后,虽然我们都想相信,如果测试彻底,一切安排周密,就不会再遇到大规模停机事故……但我们都知道,它们迟早还是会发生的。
因此,正如我们从许多停机事件中了解到的那样,如果我们在停机前将策略和计划构建到系统和脚本中,我们将更容易从这些事件中恢复。
战略意味着仔细思考和做出决定。比如,如果整个站点因为超载而宕机,我们应该先减少什么流量才能恢复正常?这些流量涉及哪些类型或类别的客户?如果提前做出这些决定,由领导签字,甚至由律师核实,工程团队更容易将压力降低到门槛以下。
计划是我们可以设置类似“死机模式”的东西,在这种模式下,调度会停止,负载均衡器会变得不那么智能,不必要的工作会自动暂停。我们可以有一个运行时参数,调整它可以减少一点负载,这样我们就不用关闭和打开所有东西,也不用打扰很多客户。
行情
在第一集中,Slack和TGW:Slack使用了特使代理的恐慌模式,这大大增加了负载平衡算法过载时找到健康主机的机会。
在第4集中,一个微妙的正则表达式破坏了Cloudflare:Cloudflare制定了策略和支持使用条款,允许它们在服务失败时关闭全局Web应用防火墙。此外,它们还有一个运行时参数,允许它们在不部署代码的情况下立即禁用它。
第六集,GitHub的43秒网络分区:GitHub在过载恢复时关闭了Webhook调用和GitHubPages构建。

推荐阅读