技术干货 | 揭秘两轮车稳定性建设之路
1.
什么是系统的稳定性
通常会用几个9作为指标衡量一个系统的稳定性，这是什么含义？如何准确定义系统稳定性呢？仁者见仁，笔者认为系统的稳定性应该包括四个方面的要求：高质量、（高）可用性、高性能和健壮性。
▌ 高质量
即指代码无逻辑错误，尤其需要注意边界Case。对10月份Bug分析发现接近40%的bug是边界case未覆盖，超过30%的bug是逻辑实现问题、修改引入新问题甚至逻辑遗漏。边界case虽是小概率事件，而线上故障往往是由这类问题引起的。
● 保证质量的主要抓手：（充分的）单元测试、Code review、架构评审、测试用例评审等。
● 流程保障：提测准入准出制度、预发布验证、小流量灰度发布等。
▌可用性
系统可以正常提供服务的时长占总时长的比率，即通常说的几个9，如年度稳定性要求3个9即99.9%，意思是一年时间里该系统99.9%的时间是可以提供服务的。通常更关注系统的不可用时长，如3个9指的是不可用时长占0.1%（即8.76小时）。
为了保证可用性通常手段是横向扩展避免单点问题，主要抓手：
● 接入层：反向代理集群、LVS集群
● 业务服务：分布式服务、弹性扩容等
● 存储层：数据库一主多从、Redis集群方案等
● 机房：多活（同城双活，异地多活，单元化）
▌ 高性能
系统处理用户请求的能力，越快（平响时长）越多（吞吐量）系统性能越好。
主要抓手有：(横向)弹性扩容、分库分表等；（纵向）缓存、异步、算法优化、(存储)引擎优化等。
▌ 健壮性
又称鲁棒性（robustness），衡量的是系统遇到异常或故障时的恢复能力。
主要抓手有：降级、限流、服务拆分、集群隔离等。
本节概要
2.
稳定性建设的体系化思考
体系化思考是一种思考方式（点状或线性思考->结构化思考->（全局性）系统化思考）。业务研发时需应对庞杂的业务领域，体系化建设有助于在深度和广度上理解业务，如营销增长体系、会员成长体系、资产运维体系等。稳定性工作同样可以借鉴这种思考方式。本节以紧急预案体系为例来介绍稳定性建设的体系化思考。
▌ 紧急预案体系
通常质量保障体系（本文未展开讲）保证代码质量，减少故障的发生。一旦故障发生时，紧急预案体系可以通过有损降级保证系统核心链路的稳定（准确讲是上文提及的健壮性）。本节介绍一下紧急预案体系（如下图）。
首要工作是做好关键主链路梳理和服务分级，核心是降级预案演练，基础是小流量集群、放火盲测和全链路压测。降级预案应结合业务场景来制定，并且一定要简单(最好一键操作)。放火盲测用于模拟故障发生，如依赖服务耗时增长、抛出异常等。
在小流量集群中进行故障演练可以有效控制影响范围，对于高并发场景的故障演练则需要依赖全链路压测平台。体系中各组成部分相互依赖构成一个有效的系统化抓手，此外还有质量保障体系、系统感知体系等，本节不再展开介绍。
3.
稳定性建设方法论
工作与学习时总是在实践中反复摸索，抽象总结出具有一定普适性的思想和原则，而这些思想和原则又会指导实践工作，不断迭代认知。这些思想(道)、方法（术）、流程规范（法）和工具（器）形成一套统一有效的方法论。
通常在按照时间的维度（事前、事中和事后）总结稳定性工作，往往会发现这些工作和思考总结的抽象程度是不同的，因此从时间和抽象程度两个维度来总结稳定性工作的方法论，如下图：
4.
这些够了吗
前面章节是站在技术的角度分介绍了对稳定性工作的理解和思考，此外还有一些非常重要却容易被忽视的工作。
降级预案是在用户体验和系统稳定之间权衡，其间的拿捏考察的是对产品的理解，和产品、运营不断的沟通交流才能习得体会的。
故障复盘包括时间轴、问题定位及修复、故障定级、善后补偿、后续改进等。复盘过程一定要邀请业务部门同学参与，并且最好在故障24小时内完成。
▌ 角色分工协作
深入理解业务制定详实的预案，故障时沉着冷静分工协作，与业务部门密切配合才能把稳定性工作做好。
5.
思考题
思考一下：是否存在系统稳定性的成熟度模型？哪些指标可以定义该模型呢？
今年下半年主要精力在两轮车业务的系统稳定性，同时也在协调普惠各业务间的稳定性工作。在这个过程中发现各业务、各端（服务端、客户端、前端等）的稳定性工作参差不齐，很多工作是故障驱动的，没有特别明确的方向。如果根据成熟度模型可以知道本系统处于哪个阶段，便可以明确下一步的重点工作，循序渐进有条不紊的推进完善系统的稳定性。
欢迎一起思考探讨这个问题。
6.
小结
本文介绍了稳定性工作的几个层面的思考和总结，包括对稳定性的理解、体系化思考和方法论，最后又介绍了故障发生时的分工协作和通知上报机制，留了一个正在思考的问题。
稳定性工作应该结合自身业务实际场景作评估和权衡，希望本文对大家的稳定性工作有所帮助。
编辑 | 钱维
-
推荐阅读