故障处理trouble shooting是每个SRE要做的日常，特别是处在快速成长期的大型互联网系统，模块多、变更多、访问量大、用户环境复杂，不就是这坏就是那坏，SRE就像一个医师，需要在故障时协同研发动各种手术去修复系统，常用的修复的方法一般会提前梳理准备好，我们称作预案。
经过无数次的故障处理，发觉是有一些不变的套路的，每次故障处理基本都是围绕这几个套路在做排列组合，其中最常用的6个，我把他总结出来，江湖就俗称“6把刀”吧。
第一刀——重启
无敌的“重启大法”，电子产品的修理秘术，同样也适应互联网服务，没有什么是用“重启大法”解决不了的，如果重启一次不行，那就两次，经过无数次实践证明，绝大多数问题确实可以通过重启短暂解决。
所以，故障来的时候，先把理性分析放一边，重启一下试试嘛！！
当然，重启也是有套路的，例如是一台一台还是瞬时批量？还有一些服务是不能重启的，有状态、又有状态存储，一重启数据就丢失，进而可能造成整个系统雪崩，坑死人不偿命，所以，哪些可以重启，还是要和研发提前达成一致。
总之，重启是最廉价的服务恢复手段，是付出成本最低的预案，故障来了，这第一刀，要先想到它。
PS 重启的本质是初始化，从健康的初始状态重新来一遍。
第二刀——回滚
第一刀下去如果没奏效，那就要考虑第二刀了，故障不是无缘无故就生发了，很多发生都是由于变化，其中最常见的变化就是变更，从每年的故障数据看，大量的变更类故障，这第二刀就是应对变更的——回滚！！
如果排查后，故障开始时间和变更时间基本一致，那就把理性分析放一边，先回滚吧！！
回滚相对于重启就重一些了，需要重新上线，也是最常用的故障预案，SRE一定要引导大家，不要试图想把原因在故障期间分析清楚了再操作。
PS 回滚的本质是回到上一个稳定的版本、健康的状态。
第三刀——扩容
第三刀看起来是处理容量类故障的，但其实不然，当简单的预案不能快速恢复业务，扩容同步做起来吧，经过小爱同学的无数次故障处理经验，故障处理的同时，一定要找同学同步扩容，而且有多少机器扩多少。
扩容这第三刀就更重了一些，需要投入新的机器资源，因为大型系统，但凡故障一定会带来用户请求的拥堵，进而流量堆积、抖动，所以哪怕从这个角度看，扩容也要先做起来，很多时候机器是解决问题最直接、成本最低的手段，不要讲那么多武德，每分每秒都很宝贵，理性分析等业务恢复了再说。
PS 故障期间扩容的本质是短暂提高系统的资源池，不能作为常态，代码或者架构烂不能一直堆机器。
第四刀——切流
第四把刀是切流，也是故障处理中最重要的一个招式，如果容灾、容量做的好，不用犹豫，第四刀是恢复故障最快的方式，do it！！
切流最常见的是机房和运营商的切换，这个操作最大的挑战是容量，最大的风险是流量切换后系统的雪崩，切换前我们要经常考虑的是，B机房的流量是否能承载线上所有的流量，回顾过去，都是惨痛的教训，本来还有一半的用户能够正常使用，结果流量切了后，整个系统雪崩了！！
所以说，要不要切、切哪些、切多少、怎么切是需要根据当时的客观情况，理性决策后再去执行的，我们故障处理的目标是止损，是两害相权取其轻，不能因为我们完美的想照顾每一个用户，反而把故障蔓延的更大。
第五刀——降级
这一刀是断臂求生、舍车保帅的功法，宝亮在开运维专项会时提了一下，思考后为了保障方法论的系统性，将其补上。
降级解释一下就是降低标准来服务，某些短时间修复不了的非核心功能，通过配置将其暂时下线，保障主干功能可以继续服务。例如，有时候我们发现小爱同学的一根手指坏了，短时间无法修复，但身体其他器官都是健康的，按理小爱只是无法提供这根手指的服务，但在设计上由于小爱对这根手指采用完全依赖等待的机制，大量请求过来，不一会儿就传导到胳膊无法工作，进而躯干无法工作最终到小爱的脑死亡，造成了整个系统挂掉（雪崩）无法服务，这个时候就要果断的降级。降级是迫不得已的一个手段，模块设计时做到解耦充分，故障期间可以用它来保命。
第六刀——限速
这第六刀是一个辅助招式，可以和其他任何招式做排列组合，但绝对是不可或缺的。
要没有它，你会发现碰到流量突增类故障很难处理，特别是数据库被打挂了，基本上服务一恢复，瞬间就再被打垮，只有通过限流，让流量缓慢进来，才能让系统逐渐恢复，去年小爱的就近唤醒故障，还有今年MIoT碰到的好几次mysql故障，都是惨痛的教训。
解释一下，很多系统是可以承载1个亿的用户同时使用，但无法瞬间承载1亿的用户同时上线（逻辑和开销不一样），1个亿的用户同时上线不异于一次洪水攻击，只有让流量缓慢进来，系统才能接住，并维持高并发的QPS，维护过大型互联网系统的同学应该会有感触，每秒新建连用户数是一个很重要的指标，而且一般都会在这个环节做云置限速。
所以，如果系统用户量很大，而且是一个“脆皮”时，当有流量突增、抖动，为了损失降到最低，缩小故障恢复时间，先把限速开起来。
所谓道法自然而术变万千，每一个故障都是不一样的，而这六把刀可以组成无数个排列组合，应对不同的故障场景，所以作为一个SRE，还是需要对架构有深入的理解，才能在故障期间联合各方制定出最优的预案，快速恢复业务。
转自：降级预案在同程艺龙的工程实践
现代分布式系统设计中，面向容错、降级熔断设计是常规的、不可或缺的功能。在复杂的业务架构下，例如从商品的搜索、交易到供应链，整体的系统链路会长，系统间的依赖关系非常复杂，由于业务多变性、复杂性的存在，如何简单的切入到整体链路中，帮助系统快速、无侵入的实现降级熔断措施，或是帮助整体链路实现业务降级预案，也随之变得异常困难。在日趋增长的业务下，随之增长的降级措施散落在各个系统代码中，日积月累，降级的治理也变得异常困难，原先的降级措施也逐渐演变成系统中的一个不稳定因素。在这样的需求背景下，需要系统性的、完备的降级治理架构协调运作。同程艺龙结合实践经验，从数据采集、指标计算、资源降级恢复、链路预案管理、故障诊断多个方面，探索服务降级体系化建设的可落地架构。
主要内容
降级预案系统整体设计；
数据采集与计算设计架构；
降级预案治理；
降级策略扩展性设计；
平台自身高可用建设。
