本文转载自微信公众号《董泽润的技术笔记》，作者董泽润。转载本文请联系董泽润技术笔记公众号。换个角度，我今天不写纯技术文章，而是分享一个highlevel的topic。如果公司或部门的微服务频繁出现故障，老板让你负责维稳建设，俗称救火队长，你会怎么办？？？这个问题可以作为面试题来测试应聘者是否具有全球视野和对技术栈的掌握程度。同时需要多维度的思考，比如产品、工程师、服务、基础设施等等。一般来说灭火的原则和上图一样，包括扑灭明火、定期检查设备、进行消防演练等。稳定性建设也分为三个步骤：短期故障排除、中期稳定性建设和长期压力测试。短期故障排除1、灭火迫在眉睫，持续存在的问题必须及时处理，至少先减轻影响。它不能影响核心订单创建过程。慢一点也没关系。那些可以降级的将首先降级。如果因为上线导致核心链路失效，必须及时回滚。不建议上网找原因。2.功能冻结由于是特殊时期，所以从产品的角度考虑：freezefreeze所有的开发功能都上线了，除了bugfix和非常重要的改动需要boss批准。同时，每次上线至少要得到领导和稳定负责人的认可。总结分析失败原因、处理过程、后续TodoActions，并跟踪后续执行情况。最重要的是将其推广到其他服务。爆，真的很夸张4.服务服务，短期内需要检查一切：设置合理的超时时间，比如很多使用pythonrequests库没有设置超时时间，给每个设置一个合理的限流接口，并保护自己不调用第三方设置熔断断路器，保护他人不检查重试逻辑。你需要做的是重试，而不是增加洪水下游的警报。很多时候，只要有报警就可以提前发现问题。毫不夸张地说，以上步骤可以排除90%的故障。尤其是限速器/断路器可以避免大部分的级联故障。中期可以做很多事情来建立稳定。既然不急，还需要慢慢测试细节。1、产品优化。是很多工程师不具备的素质，需要产品经理一起梳理业务流程。很多时候，一个业务形态的优化远远超过工程师的努力，广义上说，这个产品功能可能是最脏的，我们是为自己服务的产品经理。比如，原来的双写逻辑可以用第三方同步工具完成吗？这样，服务就可以清洗了。2.服务架构优化随着功能的不断迭代，原有的架构设计已经不再适用。简单来说，10万单的架构不管加多少台机器，都无法应用到100万单的场景。有幸接触到滴滴的订单共享架构，就是走过了这一步。它可以针对特定的服务做很多事情：比如utcoverage达到一定的指标，即使有全链路压测，也不代表代码的所有逻辑分支都是正确的。还有一个很重要的是，服务要分等级，比如p0、p1、p2等，当出现故障时，首先要保证关键服务的QOS，在放弃低等级服务时要做fallback逻辑。例如，eta请求地图服务。如果地图服务不可用，使用道路距离作为回退等。可观察性，仪表盘是否足够，metrics指标是否全面排查隐患，墨菲定律无处不在，你可以想象失败的点，比如SPOF，只要时间足够长，肯定会爆炸。3、上线流程涉及到公司的CI/CD，工具是否易用、健壮、稳定。上线要有金丝雀灰度，全线上线要有群，留给工程师足够的观察期，而不是一个梭哈。同时定时使用rollback，保证回滚功能可用（都是泪，不要问我为什么）。可以想象一个服务有100台机器，灰度是没问题的。是不是真的就没有问题了？不可能，这么全上线也需要分组，把控制权交给工程师。对于工程师来说，培养风险意识是很有必要的。上线时需要观察日志，查看仪表盘。全面观察服务的健康状态，cpu和latency正常服务有没有问题？当然不是，同时注意新功能是否会淹没下游服务，做好评估4.技术审查很多公司都有技术委员会，除其他外，至少有58家有。公司层一般负责更多的提拔，所以每个部门需要有相同的人员。最重要的是重新审视方案，是不是设计不够，设计过度，还是选型过于激进。比如100年前，mongodb刚出来的时候，公司把mysql换成了mongodb。那个时候mongodb有db级锁，没有事务……长期实践压力测试也有很多工作要做。由于涉及所有开发部门、基础设施、运维团队，需要一个专职团队长期负责，定期审核总结1、全链路压测目前最好的是阿里巴巴。滴滴，这其中牵涉的细节太多了。压测工具的开发可以通过压测提前发现。压力测试工具的开发也是一个大工程。我记得当时我们说，每次工具失效，大家要等几个小时。以前的做法是在一个太平洋小岛上嘲笑。虚假打车需求，所有服务都需要做相应的修改，包括mysql创建影子表shadowtable，压测请求需要区分服务等。曹大前几天分享了一篇文章，为什么有的公司不写UT线线上也比较稳定。一个原因是入口处有全链路压测。2.烟雾混沌烟雾测试。混沌测试的目的是在线造成破坏，找到弹性不好的服务和模块。比如磁盘IO不稳定，机器突然宕机，时间突然回滚等。之前分享的Pingcap，混沌注入结束后，服务QPS还没有恢复到正常水平。有兴趣的可以去看看3.定期演练的servicerunbook我深有体会，就像消防员定期检查设备，然后试火一样。该服务需要针对特定??问题自定义runbook。毕竟，维护服务的工程师是流动的。今天是主人，明天就交给汤姆了。我们的服务依赖于etcd。大家都知道机器出故障的概率很低，但却是意料之中的。于是我们写了一个runbook，滚动升级etcd，故障节点的移除和添加等等，非常好用，新手也可以跟着流程走。4、人才素质建设长远看，重中之重是人才素质建设。如果您不阅读日志或检查grafana，我们不怪人。可能工程意识只是在人员素质建设上差了一点点。有太多的方面，软质和硬质。最直观的是编码能力。防御性编程应该深入每个工程师的骨髓。5.基础建设跳出工程师的视野。从公司的角度来看，一个idc或者云厂商是不够的。国内提到最多的是两地三中心、多项活动的设计。事实上，这是非常困难的。大多数公司都是假的和活跃的。主人房都完了，但不会发生水灾和火灾。最起码数据要多处备份，可以暂停服务，数据没有了，公司会倒闭。当年在天津港发生的事情，印象尤为深刻。微信IDC负责人做的很好。我不能说太多。有兴趣的可以搜索一下摘要。实际上，它必须是可执行的，并且每个步骤都必须细化为文档，并总结为流程和系统。
