稳定性治理方法论

谈到系统的稳定性治理，我总是想要找到一个“稳定性治理手册”，上面能像一般的软件一样有 Quick Start、Samples 这些拿来即可用的参照。

但是并没有。

谈稳定性治理的文章有很多，有的整体思路是“事前、事中、事后”，有的是“人、工具、预案和目标”，有的围绕软件开发的生命周期，还有的是哪些系统指标需要监控。

这些文章说的都很好，但又很难找到一条线把它们都串起来，因为他们所围绕的出发点就不一样：有的是从管理者的角度看待问题，有的是从普通开发者角度，有的是项目管理者，还有的是运维、测试等等。

既然这样，我们不妨把这些文章都抛到脑后，从一个应用 owner 的角度出发，问自己一个问题：“如果接手一个完全陌生的应用，如何保障该系统的稳定性？”。

第一步 排除隐患

首先是系统的已知问题，这个可以从上一任系统 owner 或者其他人口中直接得知，也是系统一直面临的一些问题。

然后是一些未知问题，需要我们主动去挖掘、排查，下面这个 checklist 可供参考：

第二步 监控预案

排除系统隐患，作用是在预防，是为了能够尽量降低出问题的概率。

而万一系统出现问题，这就是第二步要做的，做好系统问题的发现及预案。

这里有三件事情要做：

1.找到可能问题的地方

2.部署监控及报警

3.部署预案

最大难点在于第一点，难在问题找不全。

系统稳定性风险这件事情本身也是相对的，要想保证系统一定不出问题，那几乎是不可能的。只有在某种程度上，我们多付出多少时间，所带来系统出问题概率的降低，之间的投入产出比是否值当的问题。 在相对比较有必要的地方部署发现、预警及预案能力，而在一些细枝末节上，也不必去钻牛角尖。我们可以搞一个大的兜底：假如系统出现了一些预料之外的功能异常，或者整体的系统崩溃，我们应该怎么去设计这个预案。

另外，针对一些应用系统需要监控的点，以下可作为参考：

第三步 变更管控

如果系统的隐患和监控预案都已经搞定，我们可以认为系统的存量问题已经解决。 接下里要应对的是在不断的线上运行及需求迭代中，“变更”带给我们的挑战。

90%以上的稳定性问题都是由变更引起的。

首先要知道，系统可能存在哪些变更。以下 checklist 可供参考：

变更风险可以融合到软件开发的生命周期中进行管控，比如说项目上线必须有“设计方案评审”、“CodeReview”、“发布计划评审”等环节。

变更风险的管控，部分内容可以参考第二步的监控预案，同样需要“识别风险”、“部署监控与报警”、“部署预案”。因为是增量的功能，其中还要增加一个“灰度”的能力。

这里不得不提到技术风险三板斧“可灰度、可发现、可预案”。

技术风险三板斧

技术风险三板斧是我在蚂蚁金服工作期间接触到的，它是稳定性治理的重要方法论，也是集团的军规。

如果出了稳定性问题，首先问的是有没有遵循“三板斧”原则：如果有，则降级处理；如果没有，罪加一等。 以一次新功能的发布为例，我们可以这样理解：

首先，新的功能会引入新的风险，如果这些可能性在线上出现了，我们要能够有发现风险的手段，此为可发现；

然后，我们要针对可能出现的问题做好预案，当发现了问题后，执行相应的预案，此为可预案；

最后，在发布过程中主动观察是否会有问题产生，也是为了降低发现-预案期间产生的损失，需要逐步开放线上的流量，此为可灰度。

理论上，只要做到了可发现，所有的问题都能够被感知；只要做到了可预案，所有的问题都有应对策略；只要做到的可灰度，所有的问题都不会产生大的损失。三者环环相扣。

可以说，如果这个三做好了，就一定不会有问题；反过来，如果出现了问题，一定是以上三者没做好。

何为有效的发现？

另外，有一个问题曾困扰过我，即如何真正实现“可有效发现”？

比如说，有一个功能，是通知保险机构在他们的系统出单，如果这个功能出了问题，如何发现？

我们的做法是：去实时、或者 t+1 的核对两边的数据，如果一致，则一定没有问题；如果不一致，则一定会有问题。

我的疑问是：如果核对脚本本身错了怎么办，又或是核对平台本身挂了怎么办？如果要写一个程序 check 核对平台有没有挂，那这个 check 程序本身是不是又有可能出问题？如此循环无限的问题，还如何做到“有效的发现”？

是的，没有绝对的“有效发现”，所有三板斧能力的建设都是相对的，这需要取决于我们能够容忍的风险概率，我们对此付出多少。

核对平台是有可能挂，但是当我们部署了核对脚本后，业务功能出异常+核对平台同时挂掉同时发生的概率，使得我们业务的风险大大的降低了。我们可以根据业务的重要性，选择部署多少道发现能力，综合考量出错的概率，归结到几个 9 的稳定性的问题。