关于稳定性和故障的一点思考，每个互联网公司都吃过这个亏！

作者：丁浪，目前在创业公司担任高级技术架构师。曾就职于阿里巴巴大文娱和蚂蚁金服。具有丰富的稳定性保障，全链路性能优化的经验。架构师社区特邀嘉宾！

---

引发故障的原因主要有几种：

1. 遗留系统的坑和技术债务。这些隐患就像一个个地雷，搞不清什么时候会爆炸。比如以前的架构设计问题，模型设计问题，代码实现的问题，性能瓶颈等。追究起来大家都会说是"历史问题"，或者叫"有人生，没人养"

2. 由变更引发。为了追求所谓的"敏捷"和"快速交付"匆忙上线，结果是带着问题上线的，自身就存在缺陷甚至还可能引发其他问题。开发或优化A功能上线后结果引发了B功能的潜在bug最终导致故障，得不偿失

3. 其他因素。比如人肉的误操作，比如运行环境不规范，比如系统相互依赖、部署和公共资源隔离不彻底等

多数公司遇到的其实都是些很基本的技术问题，并不是像电商、金融类、微博的一些复杂场景性、超大规模性的技术问题（例如：突发大流量）。解决起来往往是受限于资源不足、跨组织推动困难、一线开发人员意识薄弱和积极性不高等

关于遗留系统和技术债务的应对措施

1. 见招拆招，不止是解决表面问题，而是遇到问题后得找到根本原因并解决，学会举一反三的解决类似问题。周期长，见效慢，是一种相对被动的方式

2. 主动审视既有系统的坑，分优先级去推动解决。修缮式的做法资源投入相对可控，可验收阶段性的成效

3. 重构或重写。拆迁式的做法对技术人员来说最爽，但资源投入比较多，很容易耽误业务发展更新，而且没有人敢保证重新做一套就完全没问题。以目前的现状推倒重写的可能性很小，当然，必要时小范围重构是可以的

根据经验，挖坑只需要一天，而填坑则可能需要一周。规范、设计等往往在项目初期和推进过程中有效，而事后再去做则很难补救，最多只能扼制产生更多的坑，现实就是如此残酷

关于变更

1. 新开发功能或者重构是需要有设计和方案评审，形式不限、简单实际，目的是搞清楚为什么要做、打算怎么做（关键实现）、以及这么做有什么风险和关键注意事项。要开始尝试去做，否则永远都是停留在纸上的模板

2. 需要补充测试用例覆盖，合并代码和上线前都需要回归，上线有也需要验证主链路。这个过程很漫长，但是日积月累的。测试用例也需要审查和长期治理的，不能是为了应付"覆盖率"这些指标而做

3. code review ，静态代码扫描... 这些不是灵丹妙药，但关键系统要先做起来

4. 发布窗口收紧，节假日前禁止发布，必要时走紧急发布窗口。系统趋于稳定后，自动化体系和工具链也成熟了，控制权将逐步移交给业务域的架构师和TL

5. 可灰度、可回滚、可监控 这是金融核心系统保障稳定的"三板斧"。灰度和引流的能力可能现在并不具备，但是也要考虑，哪怕是实现的龊一点。至少要有优雅停机的能力。快速回滚的能力目前是具备的，但是比较依赖人肉。监控和日志，这个目前做的也不太好，需要改进

发布后除了产品验收交付的新功能，技术人员一定要验证主链路，盯监控，盯日志，发布完就闪这是红线

关于故障应对和管理

1. 不要幻想"完全没有故障"。我们要做的是怎么尽可能避免故障，以及怎么缩短故障影响时间、缩小故障的影响范围等

2. 故障应急处理的原则是第一时间快速止损而非彻底解决，无法快速解决的故障应该升级到更高层面(例如：通知运营、客服、销售、公关等团队)。原则上是要快速解决和应急，但技术需保留现场(如日志、dump信息等)以便分析根本原因并彻底解决。过程通常包含：发现问题、定位问题、解决问题、消除影响（比如技术的恢复降级开关、客服通知客户并安抚客户等）、复盘问题等阶段。应当杜绝"重启治百病"的盲目操作，不要放过任何一个"神奇的问题"

3. 故障应该被管理，要有定级、定责、复盘等。定级、定责的原则这些都要写清楚，避免扯皮、推诿

4. 复盘的根本目的是为了从故障中吸取经验教训。应该记录处理过程，多问为什么并分析清楚根本原因，参考价值，以及后续改进计划。过程公正、透明，不要形式主义，参与者不做"围观者"和"事后诸葛亮"。要学会举一反三并避免类似问题在其他地方再出现，总之学费不能白交。定期审视系统的健康状况有助于改进系统

5. 定责和惩罚是两回事，对事不对人。鼓励做事，应尽量避免让一线人员产生"做的多错的多"的误解从而打击到大家做事的积极性

6. 制定明确的红线、高压线，宣传和提高大家的意识,很多问题是意识薄弱导致而并非技术人员能力不足

7. 需要沉淀一些应急预案，即使系统趋于稳定后也需要不定期做一些"线上故障演练"

对于触碰高压线或者态度恶劣的这种应该受必要的惩罚。但不建议将故障和绩效强挂钩，应该阶段性的看问题，如果某人是偶尔的犯错，态度良好且后续表现有明显改进，这种就不该影响到整体绩效。如果是频繁犯错，未见改进，这种在绩效沟通时可以就事论事

提倡的和不提倡的

1. 优先通过技术手段解决问题，标准化、自动化、可信赖。例如：增加蓝绿发布来控制受影响范围从而降低变更引发的风险，通过自动化用例覆盖来回归现有的功能，通过完善的监控和日志来预知故障并缩短问题的排查解决时间...

2. 特殊时期才加入必要的流程管控，比如新增流程节点、doublecheck等。这里要区分常规流程和非常规流程。codereview、QA确认之类的属于日常发布的常规流程，而"总监/副总审批"则属于非常规流程，一般只有封网等特殊时期才会启用，不能是常态

3. 如上所说，"一刀切"的处罚手段并不能真正改善系统质量和稳定性现状，还会打消一线技术人员的积极性，是应该尽量避免的

4. 直视问题并解决，而不是想办法"绕过去"。例如：下游某个基础的服务经常不稳定，应该是花力气好好优化掉，而不是让上游的一些应用来花费很大精力想办法怎么绕开和避免

5. 优秀的工程师应当思维严谨，对技术问题要刨根问底。不要出问题就找出"网络抖动"等虚无缥缈且毫无说服力的原因

文化

• 鼓励做正确的、有价值的事情;

• 与那些想做事的、愿意共同成长的人相互成就;

• 信任、授权、ownership;

• 敬畏生产、质量意识、荣辱感;

最需要做的

1. 单元测试、静态代码检查、技术设计和评审、code review、故障复盘等。通过这些手段扼制既有系统产生新的坑，并持续改善

2. 明确故障定级标准、定责原则、开发/运维的高压线等等。提升一线人员的意识，激发责任心和积极性，逐步建立起以应用为核心的owner制

3. 各业务线 + 运维 需要有作战地图和值班机制，除了降低故障发生的几率，也要努力降低故障影响范围和缩短影响时间，逐步沉淀应急手段和预案

4. 主动审视和识别现有系统中的一些隐患，短期内无法彻底解决的需给出应急预案，以及后续的治理方案和大致计划

5. 推广devops文化，建立devops平台，配置管理（CMDB），paas平台等提升研发效能和质量有些功夫是需要长期修炼的，不一定立马就见效，但长期来看是很有效的
   没有银弹，没有灵丹妙药，也没有一劳永逸

codeReview

1. Leader、架构师主动抽查/审查代码，直接指明存在的问题

2. 可以是小团队在会议室"晒代码"，由开发人员自己讲出来，评审的人给出建议

3. 禁止手工直接合并主干代码，在gitlab中通过Merge Request来做合并主干，发布集成前强制指定人CR确认

对于1，2这种主动审查的，目前没有专门的工具去记录，可以先记录在本地，对于一些典型的问题和建议可以放confluence，具体实施时可以再看

静态代码扫描
1.开发人员本地ide中安装插件、模板等，自行做扫描和修复
2.借助sonarqube等平台来实现，和jenkins等CI平台流程整合，构建后生成报告。对系统设定阶段目标，定期检查报告查看达成和改善情况
3.优先关注和接入核心业务系统
该阶段主要关注：明显的bug、潜在的风险、代码坏味道、不规范、安全漏洞等，以及单元测试的覆盖率

单元测试
1.优先关注和覆盖核心系统，主业务流程
2.关注"通过率"、"行覆盖率"、"分支覆盖率"等指标。也需要关注用例的执行效率、用例执行的的稳定性
3.单元测试也是要抽查和治理的。对于一些无用的、滥竽充数的测试用例要及时指出，必要时团队内"通晒"

技术红黑榜
1.对于一些写的好的代码，写的不好的代码，象征性的晒出来，激发技术人员的荣辱感
2.故障记录、公告、盘点统计
3.性能问题定期统计和公告，问题应用、问题接口、问题数据库等直接排出来
...

文档知识库
1.业务领域的一些产品文档，业务知识文档等
2.业务领域的一些架构文档、系分设计文档、技术方案文档、规范等
3.公司级的规范、基础技术、架构大图等
...

对owner的理解
业务域的owner：规划业务发展方向和目标，制定计划，衡量投入产出，拿结果 需要具备产品、技术、业务等多维度能力

应用系统是owner的孩子，需要负责其"生老病死"，作为合格的owner至少需要掌握如下信息:

• 应用名和概述（是web应用还是领域服务、spring mvc还是spring boot、所属业务领域、核心能力、关键职责）

• 部署架构（线上部署情况、部署那些机器、用的tomcat还是jetty、运行端口、JVM参数、系统资源负载情况、容量水位）

• 运行状态（当前业务量、应用及关键接口吞吐量、99线/95线/90线响应时间、错误数，未来的业务量评估和容量规划）

• 关联的数据库、缓存中间件等

• 关键的服务接口和能力

• 上下游情况（主要被谁依赖 and 主要依赖了谁）

• 关键模型（业务模型/数据模型）

• 关键的配置（业务配置项、开关、监控项等）

• 包含的定时任务

• 包含消息topic/队列

• 系统存在问题、应急手段、长期治理方案和计划

长按订阅更多精彩▼

如有收获，点个在看，诚挚感谢