系统稳定性建设之我见

每一次故障都是对客户信任账户的透支，如果频繁出现故障，除了会对公司和公司的客户带来实质的损失外，还可能带来三方面的影响， 一是增加客户对服务稳定性的质疑，二是增加公司其他部门对技术团队技术能力的质疑，三是技术团队产生自我怀疑。

如何降低故障的影响呢？ 我也试图去寻找这个问题的答案。

说到这里，想起扁鹊三兄弟的故事：

扁鹊有两个哥哥，三兄弟都精通医术。

大哥医术最高，二哥其次，扁鹊在三兄弟中是最差的。

大哥能在人还没有生病的前兆时，预测到病，并及时预防。

但由于没有人相信，认为自己一点也没有生病的迹象，故认为自己很健康，不相信自己不久的将来会生病，故都认为扁鹊的大哥是骗子。

二哥能在人有一些生病的迹象后能发现病的严重性并及时医治。

但由于刚发病，病情很轻，大家或者不医治，或者以为是小病，即使二哥将他们的病治好了，他们也认为医生能治好这种小病是在平常不过了。

故也不以二哥的医术为多高明。

扁鹊只能在病人病情明显时才发现病情，并医治。

由于人已重病，在扁鹊的医治下恢复，人们认为他是神医，能起死回生，故认为扁鹊的医术最高。

故三兄弟中唯有扁鹊出名。

孙子兵法里也说： “善战者无赫赫之功,善医者无煌煌之名”。

真正厉害的是防患于未然，尽可能减少损失，获得更好的收益。我想系统的稳定性也是如此。

如果能在故障发生前就开始行动，必然能够“治病于初始”。 故障发生前能做什么事情呢？ 以下是几个可以做的事情：

1. 针对业务系统各个模块的健康度进行监控，方便快速跟踪和诊断系统的可用性，可以引入可观测系统，比如观测云 guance.com

2. 引入业务变更审计自动化流程，及时发现和纠正问题

3. 系统配置版本管理，方便系统配置的快速管理和回滚

4. 建立必要的流程的规范，比如 code review 制度来把控代码质量，变更计划审核来评估变更操作是否符合规范

5. 在正式发布到生产环境前，在测试环境对功能做充分的测试

如果前面的准备工作都做了很充分了，那么理论上不会出现大的问题，但是天有不测风云，测试环境也无法完全和生产环境保持一致，可能还是会有考虑不到的情况，另外就是人是最不可控的因素，如果这时候还是出现了故障，怎么办呢？ 这时候能做的是尽可能的缩短系统恢复正常的时间。 在这之前，我们一样要提前做应对策略。

1. 需要提前建立接口，功能，模块的地图，方便在故障时能够快速评估影响范围

2. 提前对常见的故障进行分级分类，并形成故障处理手册，方便 on call 的工程师有序进行处理，而不是手忙脚乱，如果是在发版产生的故障，第一时间根据回滚计划进行回滚

3. 还有一个就是将手动处理流程自动化，比如写成处理脚本或者整合到业务系统里进行自愈，这个也能缩短故障处理时间

故障发生和处理之后，并不是事情就结束了。 我们还需要对故障进行复盘，写详细的 case study，并形成后续一系列的改进措施。另外还要有对应的奖惩制度，这样大家才会对生产环境产生敬畏之心。

前面在故障前，中，后都做了很多的工作，最终导向一个目标，就是提升系统的可用性，降低客户对故障的感知，对公司和客户的影响。 希望还需要加上量化的指标，就是实现 1-5-10（1 分钟发现，5 分钟定位，10 分钟恢复）， 核心服务可用性 SLA 99.9%。

以上是我对系统稳定性建设的思考。

未完待续