前言：止损的必要性

谁都不愿意让出故障，但出故障了也不能自暴自弃。

我们有时要通过放弃部分业务体验，保住核心业务，这就是故障止损。

粗俗点说，止损就是看到你裤子着火了帮你踩灭，你还要跟我说谢谢。

 

 

 

本文在分析故障降级止损问题，我将故障止损分为三类，并对每一类止损策略进行详解。

这些止损策略中最重要的是“未雨绸缪的准备前提”，其次才是“当机立断的触发条件”，IT部门要有外部价值，所以要及时通知业务方。

第一. 分区止损

1-a. 概念解释

分区止损就是放弃对部分用户的访问响应，但其他客户完全不受影响，可以理解成百足之虫的断腿求生。

如果某一网络的用户访问量过大，导致该网络区域的拥塞，甚至访问压力直压中心；如果局部区域资源坍塌，但冗余资源无法承载溢出需求；我们都需要通过分区止损的方式来避免全局雪崩，让一部分客户放弃访问，换取大部分客户正常使用。

1-b. 通知业务方

产研侧要快速说明用户范围和影响时间，并适度说明故障原因、技术修补手段和复现概率，这好让业务方进行实时应对和事后处理。

一个电商样例：

技术说：所有北京联通用户（当时1万人在线），无法登陆XX平台15分钟，故障已修复；

运营说：平台日活掉了1%，应该不影响几个小时后的大促。

一个云厂商的话述样例：

技术说：天津机房断电15分钟，所有虚拟机宕机重启，无法确认客户业务是否自动恢复，客户挂上云监控的业务启动了40%。

售后说：附件是公开故障报告、赔偿方案以及客户列表，请销售进行大客户安抚。

1-c. 未雨绸缪：

分区止损的操作界面一般在前端访问接入层，因为这一层服务是树状向下依赖，不会有同层甚至服务下层的逻辑依赖。切离用户访问的预案，可以是接入层下发IP段拒绝策略，可以是一键关闭某网的Web服务，还可以在局部DNS上做调试。但要注意一点，客户端容错要顽强也要适度，过于顽强的客户端容错机制，会越过止损机制如蝗群一般飞过来。

我们很难在核心数据库和存储做分区止损，是因为后台服务分清“哪个分区的用户”的难度极大，且切割不当会导致拒绝所有用户服务。

1-d. 当机立断：

要触发分区止损，并不是傻瓜式的“宕机立断”，而是分为主动和被动下线两种情况。

主动下线部分区域，就是责任人发现资源水位已经预警，可以预料马上会出现全局雪崩或牵连某些核心用户群，这时责任人将部分异常蜂拥客户或者低优先级客户的访问强制掐掉。

被动触发分区止损，就是维护者发现因资源不足，过度重载的服务已经像个压瘫的骆驼站不起来了，为了打破僵局把一部分用户和业务抛弃掉，把一部分稻草从骆驼身上卸下来。

1-e. 止损复盘：

分区止损一般不涉及修复数据，止损复盘主要是调查为何会出现资源不足。

对于可引导的流量导致的高负载，那就需要运营部门和IT部门建立起联动机制；对于不可引导的流量导致的高负载，公司盲目储备资源是的可行性不大，所以公司可以接受偶发问题下不为例的解释，但也要做好安全防Ddos的准备。

止损失败的复盘主要看两个方面，一方面是各种莫名奇妙的架构耦合，让分区止损变成拔出萝卜带出泥，另一方面就是止损的速度这么慢，肯定是常规预案演练没做好。

 

第二. 还原止损

2-a. 概念解释：

当前系统状态无法正常提供服务，那就要还原系统到一个能正常提供服务的状态，这就是还原止损。还原止损最快的方法是启用备份，没有备份就要手动复原，还原系统期间必然要暂停服务和丢失一部分数据，还原止损的损失极大，一般是失败的上线的余波。

2-b. 通知业务方：

还原止损一般是先还原后通知业务方，业务方要了解数据丢失了的业务线和时间段，以及后续是否能修复丢失的数据。我们通过下列样例可以发现，业务方一听说丢失数据吓得要死，但只要不涉及现金，实际操作有的是便利手段。

游戏公司的样例：

技术说：已升级的20组服务器要回档到X日X时，回档期间有5000个用户登录过；

运营说：给所有涉及的用户发个大礼包，所有交易和爆装都回滚。

电商的话述样例：

技术说：涉及到XXX优惠券的200个订单都处于后台锁定状态。

运营说：我们现在人工审核一遍，对无异常订单放行，异常订单另行讨论。

通用的话述样例：

技术说：有20个改过密码用户，密码都被回档了，预计4个小时内根据日志补好密码；但有2个客户的积分信息被抹掉了也没办法补充。

售后说：好的，把那俩客户的详细信息给我们，他们投诉我们就手动补积分。

2-c. 准备前提：

还原止损的前提是备份策略合理，备份文件有校验、恢复方案有预演。

l 最简单的方法是备份全量数据，但这样环境恢复很慢且丢失数据过多。

l 备份越细理论上是快速还原少丢失数据，但是做“部分还原≈排障+重建”，在故障焦躁时对操作员要求很高，常出现恢复了单独数据表、单独服务，但平台其他组件会无法正常配合，仍旧无法提供服务。

l 还原止损是在丢弃数据，但是通过各服务的日志，我们仍能找回很多数据，做好日志的定义和保存。

2-d. 当机立断：

还原止损的决策人必须是技术负责人。

还原止损其触发条件只有1%的几率是原始运行环境被销毁了，比如机房整体宕机。

还原止损有99%的几率是上线30分钟至4小时的人为判断，发现本次上线的负面作用太大，但新用户新访问又开始写入新数据了，回滚就会业务中断和丢失数据。

如果上线预案里有上线后几分钟就由基层工程师决策回滚，那就不是还原止损而是用线上压力做实验，各公司各服务的内情不同不好直接评价。

 

2-e. 止损后的复盘：

止损成功后做复盘，首先是进一步完善上线评估机制，减少回滚次数才是正道；第二是挖日志追补合并数据，尽量将丢失的数据追补合并回来，给运营同事减小压力。

止损失败的原因，一般就是没做好备份，巧妇难为无米之炊，将故障恢复变成了环境重建。或者是执行人员的还原操作有瑕疵，平日里没时间做预案。

 

第三. 降级止损

3-a. 概念解释：

降级止损就是放弃一部分开销很大、需求复杂的高阶功能，保住基本核心功能。降级止损的操作单位是功能描述，运维更难理解但架构师易于设计。

常见的降级止损举几个例子：

l 放弃个性化推荐和花哨展示，回归朴素404页面。

l 放弃新用户注册，保证老用户的正常使用。

l 放弃广告和推荐系统，保住主页、用户属性和订单管理。

l 放弃动态路由、抓包分析等功能，保证基础网络连通性。

l 直接锁库和导出备份，保护核心数据不会被恶意篡改。

 

3-b. 通知业务方：

降级止损是在调整功能功能，业务方一定能听懂，大部分降级止损操作就是业务方从管理后台上下发的指令。降级止损的时间范围并不好明确，因为业务离资源已经太远了，但只要不是全局锁库性质的降级止损，降级几个小时甚至几天都是可以接受的。

 

3-c. 准备前提和触发条件：

降级止损的准备前提和触发条件密不可分：

l 第一个前提是能把平台状态和具体业务进行定位连接，比如是什么业务占用了大量带宽，是什么业务耗尽了内存。当高负载分布在非核心业务模块时，降级服务能力是比拒绝客户访问更好的选择。

l 第二个前提是明确这些业务关闭不会带来新业务风险，比如广告系统下线只是少赚钱，但反作弊系统下线会被薅羊毛。关闭这些业务系统，最好有业务控制台层级的开关，而不是让工程师们传参数切域名。

l 第三个提前是这些业务系统的技术架构层解耦够彻底，不要前端都关闭业务了，后端还在盲目做业务相关运算。比如“发红包”功能被关闭了，其他活跃的业务系统，不要主动去计算红包金额。

3-d. 止损后的复盘：

降级止损无论成功失败，都应该以此为戒，寻求能否以更小力度去切分和降级服务，粒度越细越容易组织和调度资源，以减少后续出故障的几率。但本建议并不是盲目鼓吹服务拆分，服务拆的过细，一个功能模块要涉及几个几十个服务，也是在把简单问题复杂化。

降级止损失败的原因，通常是高级功能和基础功能没有实现解耦，类似于大脑和心脏长到一起了，还有就是基于业务的切离，操作比较困难。

结语：止损者的荣誉

故障是故障、止损是止损。别人引发了故障，我来力挽狂澜做止损。我自己引发的故障，但我至少完成了止损。

 

荆江分洪区有一支炸堤部队，这支部队已经几十年只有操练没有实战过了。我们和他们一样，永远不想面对故障，但必须做好止损的准备。

 

最后再要说一句，各种云计算方案和运维自动化工具在简化和抽象我们的工作。但这些抽象简化背后，希望大家还是留一道需要人为操控的止损方案。毕竟云厂商和DevOPS软件不懂业务，他们的止损方案不会优雅可能生硬。

本文大量内容思路受到多位资深运维-比如七N云赵成和金S云韩德田的指点帮助，在此鸣谢。