终身学习、乐于分享、共同成长！

一、前言二、故障源的分类三、稳定性建设四要素四、稳定性建设四个方向五、总结

前言

什么是系统稳定性？

系统稳定性是指系统在受到外部环境变化或内部参数变化时，能够保持其功能和性能的稳定性。

它是一种系统的性能指标，可以用来衡量系统的可靠性和可控性。系统稳定性的高低可以反映出系统的可靠性和可控性，从而为系统的设计和运行提供参考。

那么如何衡量系统稳定性的高与低呢？一个常用的指标就是服务可用时长占比，占比越高说明系统稳定性也越高，如果我们拿一整年的数据来看，常见的4个9（99.99%）意味着我们系统提供的服务全年的不可用时长只有52分钟，5个9（99.%）意味着我们系统提供的服务全年的不可用时长只有5分钟。

故障源的分类

前面我们提到可用时长占比一般是4个9（99.99%）或5个9（99.%），为什么没有%呢？

因为系统故障基本是不可消除的，没有任何一个系统可以做到%的无故障，尤其是随着我们服务的用户量越来越多，系统复杂度也越来越高，在目前流行的分布式微服务架构下，要提高服务的稳定性将面临更大的挑战。

既然故障不可消除，那我们首先得识别出来故障有哪些？

从宏观层面看，故障可以分为两类：

人为因素自然因素

常见的人为因素如下图：

人为因素我们要尽可能的事前（故障发生前）避免，因为这些原因引发的事故很可能会导致数据丢失或错乱、资金受损等较严重后果，而且除了重启或修复后重新上线外没有过多有效的止损手段。人为因素导致的故障往往会导致软件工程师的内心受到严重打击，工作和专业能力受到质疑，造成“人财两空”的后果，“我拼了老命来产出，结果却给自己挖了个坑”是故障责任人内心的真实写照。

再来说自然因素，自然因素受很多客观因素的影响，往往不受控制，无法避免。常见的自然因素：

自然原因导致的故障可大可小，虽然无法避免，但由于没有第一责任人，避免了“人性拷问”，软件工程师可以和运维部、安全部的同学协作起来处理故障。

稳定性建设四要素

墨菲定律是一种社会定律，它指出：“任何事情都有可能发生，即使它发生的可能性很小。”这个定律的本意是提醒人们，即使一件事情发生的可能性很小，也不能完全忽视它，而应该采取预防措施，以防止可能发生的不良后果。

残酷的墨菲定律预示着我们对自己系统提供的服务不要太乐观，既然不乐观，那我们就要想想如何建设系统稳定性。

人为因素的根源一方面是专业能力不足，经验不足，另一方面很多都是无心之失，所以需要通过流程、规范来保住“底线”，减少人为因素导致的故障，而自然因素导致的故障往往具有突发性，需要联合多个团队协作来解决故障。

稳定性建设四要素：人、工具、预案和目标。

第一要素：人

所谓系统稳定性建设，其实质背后都是关于对人的管理，人是系统的核心建造者。关于“人”，首先要搞清楚4个问题：

谁应该参与稳定性建设？

稳定性建设工作需要老板支持，它的实施一般需要开发、测试、运维、安全还有产品等同学参与，而且主导方应该是开发、测试和运维。

确定了参与方后，就可以做关键的一步：“参与稳定性建设的每个团队都需要在OKR中背负一部分稳定性指标”，这也是为什么说稳定性建设工作需要老板支持，因为和绩效考核相关。

如何降低犯错的概率？

稳定性工作，规范先行

要降低犯错的概率需要参与建设的人都必须遵循公司制定的流程规范，开发与测试要根据公司的当前技术体系去建设开发规范、提测规范、测试规范、上线规范、复盘规范等。

对于开发来说，开发规范是对开发人员的要求，让开发人员知道什么是必须要做的、什么是推荐的、什么是应该避免的。通常开发规范至少应该包括如下几个部分：

编码规范：对外接口命名方式、统一异常父类、业务异常码规范、对外提供服务不可用是抛异常还是返回错误码、统一第三方库的版本、哪些场景必须使用内部公共库、埋点日志怎么打、提供统一的日志、监控切面实现等，编码规范除了能规范开发的编码行为、避免犯一些低级错误和踩一些重复的坑外，另一个好处是让新入职的同学能快速了解公司的编码原则，这点对编码快速上手很重要。

公共库使用规范：为了能对通用功能进行定制化改造和封装，公司内部肯定会有一些公共库，例如日志库、HTTP库、线程池库、监控埋点库等，这些库都“久经考验”，已经被证实是有效且可靠的，这些就应该强制使用，当然为了适应业务的发展，这些公共库也应该进行迭代和升级。

项目结构规范：为了贯彻标准的项目结构，一方面我们需要为各种类型项目通过“项目脚手架”来创建标准的项目结构原型，然后基于这个项目原型来进行开发，统一的项目结构一个最显著的好处是让开发能快速接手和了解项目，这种对于团队内维护多个项目很重要，人员能进行快速补位。

数据库规范：数据库连接资源堪比CPU资源，现在的应用都离不开数据库，而且通常数据库都属于核心资源，一旦数据库不可用，应用都没有太有效的止损手段，所以在数据库规范里，库名、表名、索引、字段、分库分表的一些规范都必须明确。

如何提高稳定性意识？

有了OKR、规范和考核机制，加上我们定期宣导，相信各成员的稳定性意识会有显著提高。

如何定责？

事故定责一般是比较复杂的过程，除非事故原因非常简单明了，但实际上事故原因常常涉及多个团队，如果责任分摊不合理，难免会引发跨团队的争吵

第二要素：工具

工欲善其事必先利其器

要做好稳定性建设，强大的支持工具和平台是不可缺少的，常见的工具和平台包括：日志采集分析检索平台（比如阿里云的SLS）、监控告警平台（阿里云的监控告警体系）、分布式链路追踪（SkyWalking）、CI/CD工具（Jenkins、Docker、K8S）等等。

强大的工具主要解决下面3个关键问题：

能做什么？做到什么程度？如何降低稳定性工作成本？

工具本质上是手段，它能降低我们在稳定性工作上投入的成本，例如有了监控告警平台，我们就不需要专人时刻盯着日志或大盘，有了分布式追踪系统，问题定位会更有效率，有了降级系统，一些故障能自动控制和恢复，不用我们再上线一次。要想做好稳定性工作，工具必不可少，没有工具，稳定性建设总是低效的。

第三要素：预案

故障不可避免，当故障发生时，我们要有一套应对故障发生的紧急预案，它作为处理故障的行动指南，这在故障可能涉及到多个团队、故障进展需要通知到多个团队时特别有用。

完善的紧急预案能解决如下4个问题：

故障发生时我们该做什么？谁来指挥？谁来决策？我们如何善后？

当一个不那么容易定位的故障发生时，你应该做的第一件事应该是什么？这在不同公司、同一个公司同一个团队的不同成员恐怕都会给出一个不同的答案。

当这一步做完以后，一般就会有一部分同学加入问题排查和止损，然而介入的人多了，排查和止损的效率不一定会成比例的提升，这时候协调者很重要，协调者要避免介入的同学在做重复工作，协调者还需要持续和客服、上游业务开发等影响方沟通。

对于排查问题和止损的同学来说，要操作某个开关，有可能还要去查代码看开关的名字是什么，还有可能关掉一个功能需要操作多个开关，这些在紧急时刻都有可能由于慌乱而出错。而且什么条件下才能操作开关，谁能决定应不应该操作开关，恐怕在当时很难去做最正确的事情，而这一切都应该提前写到预案中！

紧急预案一般要包含如下内容：

预案很重要，完备的预案能降低故障定位和止损的时间，提升协作效率。

第四要素：目标

如何衡量稳定性建设工作是有价值的？如何考核稳定性建设工作达没达标、做的好不好？这些都能在稳定性建设的目标中找到答案。

稳定性建设的目标包括两个方面：

稳定性工作的价值是什么？稳定性工作如何考核？

稳定性建设工作的价值不仅需要团队所有成员认可，更重要的是需要老板的认可，没有老板的认可，稳定性建设工作只是团队内部的“小打小闹”，难以去跨团队来体系化运作。

稳定性建设工作的年度目标可以拿服务可用时长占比来定，也可以拿全年故障等级和次数来定。像我们公司会将故障等级分成了P0至P5六个等级，P0、P1、P2属于重大事故，是需要消耗服务不可用时长的（根据全年定的服务可用时长占比指标来计算出某个部门的全年服务不可用总时长），一旦年底某个部门的全年服务不可用时长超过年初设定的阈值，就会有一定的处罚，并影响部门绩效。

总结一下：

稳定性建设四个方向

前面阐述了做好稳定性建设的四个关键点，那么在实际工作中应该如何落地，主要在四个方向。

第一个方向：根基要抓牢

稳定性建设工作重在预防，至少6成线上故障都可以在预防工作中消除，我们需要投入45%的精力来做根基建设，所谓根基建设，就是把开发、测试、上线这三大流程做透！

主要在于以下几个关键点：

CodeReview

CR其实是一个很重要的环节，当一个开发整个编码和提测都可以自己闭环搞定时，时间一长就容易产生懈怠，这时候写隐患代码的几率会大大提高，CR的过程并不是diss的过程，这个一定要在团队内拉齐，相反，CR是一次很好的团队沟通和塑造自己影响力的机会。我就很佩服那些代码写得质量高并且能把整个流程讲顺的人。可以在团队内规定，大于等于4人天的项目需要进行小黑屋CR。CR还可以让其他成员来检测该代码实现是否遵循了开发规范，毕竟“先污染后治理”的成本太高，记住，CR一定是一个相互学习的过程。

设计评审

再也没有比糟糕的设计更有破坏力的东西了，设计评审和CR可以放在一起做，先评审设计再进行CR，有人就会说，都编码完了才进行设计评审是不是晚了？其实这要看情况而定，如果团队内部经常产出“糟糕设计”，那么我觉得设计评审就应该编码之前来做，但如果团队成员专业能力和经验都还不错，那么我们允许你在编码之后再做设计评审，而且编码的过程其实也是设计的过程，可以规避提前设计而导致后续编码和设计不一致的问题。设计评审的原则是，既要讲最终的设计方案，也要讲你淘汰的设计方案！

提测标准

写完代码就可以提测了？当然不是，至少得完成补充单元测试、完成自测、完成开发侧的联调、通过测试用例（如果QA提前给了测试用例的话）、补充改动点和影响点（便于QA评估测试范围）、补充设计文档这些步骤才能说可以提测了。当然，提测标准理论上是QA同学来定义的。

测试流程

测试的全流程覆盖最好能做到全自动化，很多测试用例可以沉淀下来，用来做全流程回归，当然这需要系统支持。我们公司有太多因为QA没精力进行全流程回归而导致问题没有提前发现而产生的事故，所以测试的原则是尽可能自动化和全流程覆盖，让宝贵的人力资源投入到只能人工测试的环节。

上线流程

上线也是一个风险很高的操作，部署平台需要支持灰度发布、小流量发布，运维要做到一旦有问题，能快速回滚（当然要

转载请注明:http://www.aideyishus.com/lkjg/5204.html