如何衡量系统稳定性的高与低呢？一个常用的指标就是服务可用时长占比，占比越高说明系统稳定性也越高，如果我们拿一整年的数据来看，常见的 4 个 9（99.99%）意味着我们系统提供的服务全年的不可用时长只有 52 分钟！
系统的故障源一般可以分为两大类，一类是人为因素，另一类是自然因素。常见人为因素导致的故障如下：
常见的自然因素导致的故障如下：
稳定性建设主要围绕以下四个方面展开：
- 系统应用测
- 运维测
- 支撑侧（公司基础设施平台）
- 项目管理测
1、应用测（系统架构）
2、运维测
系统要考虑持续迭代发布变更以及线上运维的诉求，做到可灰度、可回滚、可扩展。
2.1 可灰度保障
及时在小流量情况，发现问题，避免引发大范围故障。因此在做系统任何变更时，要考虑灰度方案，特别是大用户流量系统。灰度方式可能有白名单用户、按用户Id固定划分后不同流量比例、机器分批发布、业务概念相关分组分比例（例如某个行业、某个商品、某类商品）等，灰度周期要和结合系统风险和流量做合适设计，重要系统灰度周期可能持续超过一周或更多。
2.2 可回滚
新增功能增加配置开关，当线上出现问题时，可通过关闭功能开关，快速下线最新升级 或部分有问题功能。针对不同出错场景，有配置驱动一些预案，例如降级对某个服务的依赖、提供合适功能维护中公告、切换到备用服务等预案，在特定问题出现时，可以快速做线上止损和恢复。发布功能注意提前考虑出现问题时快速回滚步骤，部分经常发布注意对回滚步骤做演练。
2.3 可扩展
服务无状态，支持动态扩容。
3、支撑侧（或称基础设施平台）
3.1 可监控
要系统性确认是否完备以及保持更新，可能监控项：错误日志前端js错误、用户体验到的性能和白屏率、接口成功率、依赖服务成功率、机器基础负载相关监控（CPU利用率、cpu Load、内存、IO、网络等）、服务基础监控（端口、进程、状态探活、JVM full gc、OOM等）、数据库负载监控、数据库慢请求、流量同比剧烈变化。
3.2 可预警
监控项的报警策略也要根据业务系统特点以及监控项的特点，做不同报警策略设计，例如秒级&分钟级报警、错误率报警、错误日志次数报警、连续出错报警等。核心监控可摘要一个监控大盘，一个大盘快速判断服务稳定性情况。
4、项目管理测
4.1 研发流程
稳定性涉及团队所有不同水平同学、所有系统、研发所有环节、线上时时刻刻，单个同学是无法保障好的，必须建立团队流程机制来可持续保障。
主要流程机制如下：
- 设计Review：不同体量设计安排经验更加丰富同学Review，架构师、主管、外部架构师的Review、定期系统整体Review等。
- 代码Code Review：建立规范和标准，通过CR认证合格同学执行code review动作。
- 单元测试：不同风险的系统设定尽量高的行覆盖 & 分支覆盖率标准，复杂逻辑类追求100%分支覆盖。
- 回归测试：持续积累回归用例，在上线前和上线后执行回归动作；上线前线上引流测试也是一种模拟测试方式，端类型系统还可以用monkey工具做随机化测试。
- 发布机制：设计发布准入和审批流程，确保每次上线发布都是经过精细设计和审核的，上线过程要做到分批、灰度、支持快速回滚、线上分批观察（日志确认）、线上回归等核心动作。建立发布红线等机制，不同系统设计合适发布时段以及发布灰度观察周期。
- 团队报警值班响应机制 （报警群、短信、电话）：确保报警有合适人员即时响应处理，团队层面可定期做数据性统计通晒，同时建立主管或架构师兜底机制。
- 定期排查线上隐患：定期做线上走查和错误日志治理、告警治理，确保线上小的隐患机制化发现和修复。例如在钉钉针对企业用户早晚高峰的特点，设计早值班机制，用于高峰期第一时间应急以及每天专人花一定时间走查线上，该机制在钉钉技术团队持续践行多年，有效发现和治理了钉钉各个线上系统的隐患。
- 用户问题处理机制：Voc日清、周清等。在钉钉也经历Voc周清到日清的持续机制精进。
- 线上问题复盘机制：天内、周内问题及时复盘，确保针对每个线上问题做系统和团队精进。
- 代码质量抽查通晒：定期抽查团队同学代码，做评估和通晒，鼓励好的代码，帮助不好代码的改善。
- 成立稳定性治理专门topic：合适同学每周做好稳定性过程和精进。
- 定期压测机制：定期机制化执行，核查线上容量情况。
- 日常演练机制：预案演练，模拟线上故障的不通知的突袭演练提升团队线上问题应对能力。
流程机制要和团队同学共创达成一致后，配合建立topic负责人机制，对流程机制执行度和执行效果要做好过程监测和通晒，建立明确数字化标准和衡量机制（例如钉钉技术团队针对线上问题设定1-5-10标准，1分钟响应5分钟内定位10分钟内恢复），同时建立对应奖惩机制。流程机制也要根据系统状态进行精简或精进，确保流程机制可执行性和生命力。
4.2 研发人员
每个报警不要放过，每个报警及时响应处理
快速定位和快速恢复是个人以及团队专业能力沉淀，但快速报警响应是每个敬畏线上敬畏用户体验的技术同学可以做到的。
在监控完备和持续前提下，每个报警及时处理即可以降低故障影响范围，也会持续减少小的隐患。报警一些小的实践技巧：报警按照方向收敛报警群，建立报警天级值班机制，报警短信手机设置为震动模式（不打扰同空间家人或朋友情况下，自己第一时间感知），主管要订阅报警作为团队报警兜底处理人，报警响应好的同学和不好的同学要数据化表扬和批评。
从团队角度，报警及时响应必须配合报警治理进行，否则过多无效报警也会让有责任心的同学变得麻木。所以必须控制无效报警的数量，例如单应用无效报警（不需要线上问题进行定位以及修复处理的）不要超过5条，个人维度无效报警天级别不超过10条。
线上问题要复盘，不论是否为定级故障，不论问题大小
小的线上问题也要复盘，复盘准备度可以低于定级故障，但都需要思考反思以及落实优化Action。小的线上问题就是未来线上故障的前兆。我们团队周会上都会有一个环节，上周如有线上问题则会安排对触发人做复盘。
错误日志要重视
要定期分析线上错误日志，隐患的问题是藏在错误日志中的。我们现在技术团队会有早值班机制，每个方向每天都有一个技术同学走查线上，以发现线上隐患问题为导向，走查监控大盘、错误日志、用户反馈，通过这个例行机制，很好地防微杜渐。
每个用户反馈要重视，定位到根本原因
一个用户反馈背后必然有多个实际线上问题，只是这个用户无法忍受，知道反馈路径以及对这个产品有热爱 或强依赖才选择反馈的。彻底定位一个voc，就是修复了一类线上问题。而且到用户反馈的程度，这个线上问题就已经有一定程度用户体验影响了。我们现在技术团队有一个voc日清机制，针对线上voc问题对用户做好日内响应答复，也是一个不错对于这个意识的数字化衡量。
能力培养
单个技术同学个人技术以及稳定性保障能力是团队在每个稳定性任务上拿到结果的执行者和基础，因此技术主管重视识别不同同学个人优势和不足，针对性做工作安排以及培养锻炼。只要线上意识上足够重视，能力对于大部门技术同学是可以培养的。
团队内同学由于入行时间、历史经验等各方面原因，对于当前系统稳定性保障能力是有强弱的差异的，对于个人是正常情况，但对于团队而言，不能因为团队个别同学能力上存在不足而引入团队层面稳定性保障风险。需要主管很好熟悉以及判断同学能力段位，在负责系统和模块、流程机制约束、辅导人等方面做好差异化安排。例如校招同学X个月不做线上发布，前X个月发布有师兄协同发布机制，并发高 或资金交易等等风险高的系统让更加有经验的负责。同时设计培养机制，能力当前不足但有潜力的同学，可以安排由经验丰富的同学指导以及提供一些进阶实操路径，按照节奏从易到难逐渐承担更高风险的系统职责。
能力培养方式有技术Review、代码CR和辅导、参与团队稳定性保障机制、安排合适师兄指导、过程中主管指导、逐渐承担更高职责等。代码层面，对于Java同学来说， 《Java开发手册》是一个很好的实践性指南，超出代码风格，提供了日志、异常处理、集合等库使用、数据库设计、分层设计等多个提升代码质量的实践做法，我们自己团队所有Java研发同学都会100%通过阿里云上阿里巴巴代码认证考试，同时团队有一个团队内新人品码机制，同时钉钉大技术团队层面有一个品码会机制，这些都是不错地培养同学写出好代码的培养方式。
好多小团队、大团队、公司都有很多不错提升稳定性机制和案例，积极主动参考学习以及结合自己业务系统思考践行，是自己提升重要路径。架构上高可用以及架构相关经典书籍自我学习，从理论上做系统性认知也是有必要，相关书籍网上有很多推荐，例如《高性能网站建设》、《大型网站系统与Java中间件实践》等。
少量的同学在主管和团队尽可能帮助和辅导后在稳定性性保障的意识和能力上持续不能达标，这类同学要做好阶段性高风险系统隔离以及坚定做汰换。对业务、客户体验、团队内其他同学负责，及时汰换他以降低这一块稳定性风险。
参考：
