从阿里云大故障看稳定性

本文不对阿里云11月12号这次大故障做任何评判，因为同样做稳定性、经历过大故障的我对故障本身、及故障责任团队非常能够感同身受，此时的他们身心一定是在烤火架上煎熬，压力巨大，我不忍心在不知全貌的情况下对事情做不负责任的网络评判。

这两天也看到了大量的报道、评论，有观点中肯，也有跟风造谣的，网络发表言论成本低，传播快，还不用负责任，会产生让人无法控制的威力。比如今天在公司内网，一哥们完全无调研，一上来以狭隘的心理揣摩他人蠢坏，再蹭个热点网络举报，因为热点加持，许多吃瓜路人不明真相纷纷义愤填膺，一瞬间我觉得无比可笑。任何时候，我们不要成为那个被愚弄的无意识的暴力制造者，我们要谨言慎行，保持清醒、独立思考。

作为经历过多次大故障的稳定性老兵，希望我的一些看法，能够让一部分人对稳定性、对故障有更客观的认识。

出现大故障到底是谁的锅？

故障越大，锅就越不是执行变革的一线同学的，为什么呢？因为一个同学的简单变更，能引发超大面上的故障，那说明是雪崩了，从单点风险识别、变更流程管控、架构合理性、应急快反、稳定性意识全部都出现了问题，才能所有的薄弱点全部击穿，触发超大故障。

只要是人写的代码，100%会有缺陷，就会有线上质量问题，触发故障也很正常，但做基础产品、做稳定性的同学会去想办法将故障影响面控制住，就像盖房子，难免有砖块会存在质量问题，但是楼房的地基、承重墙、框架一定要保障好，这样即使出问题也不会有太大风险。同样做高可用系统，一定要识别系统会导致全局性故障的单点风险，要提前从架构设计和流程规范上规避，而不是靠从人上规避。

所以，大故障，责任一定在于上面，没法逃避，这就是做稳定性的管理层压力所在，你需要有全局视角能帮助团队识别面上的关键风险、需要哪怕不被老板认可也有坚定的信念帮助团队笃定在稳定性投入上、需要有非常强的抗压能力应对随时可能的线上故障、需要将团队踏实靠谱责任心强的人充分激发出来、需要有自己清晰的对自己业务稳定性以终为始的思考和路径。

要做好稳定性，最关键的因素是什么？

自上而下的认可

其实这是最重要的却常常被忽略，栽一棵树最好的时间是十年前，然后是现在，三年后平台的高可用做到什么级别取决于当下上层OKR对它的定位，最容易出现超大故障的时候，常常是自上而下业务非常自嗨的时候，有些高层甚至可能都瞧不起被他们类比成水泥匠的稳定性打工人，认为做好稳定性是应该的，做不好就得挨板子，在这种人浮于事的环境下，要把稳定性坚持做好，需要底下管理者和团队非常强的责任心和使命感，但永远不要忽略人性，再强的责任心也需要现实激励去喂养。

自下而上的责任心

做稳定性不像做业务，做业务相对好衡量，事情大多都在面上，而稳定性水下面的投入常常比面上的大得多，比如系分设计、代码开发、链路分析、CR、发布评审、客户问题、风险识别、压测演练等等要做好，充分考虑稳定性，需要有极强的责任心和专业素养。一个经验丰富的稳定性老手，通常有至少3~5年的经历、有重大故障经历（至少所在团队）、本身具备极强的责任心。很多故障触发因其实就是变更人粗心，而在我看来粗心背后本质还是责任心问题，缺乏对客户对稳定性的敬畏之心。

面对大故障怎么激发人性的善而非恶？

有时候超大故障会成为照妖镜，在极致的压力下照出来人性的恶。推诿、指责、放大镜找漏洞、问责等等，没错，这些都可能会来。协作方之间不再相互信任，而是相互提防。

如何在极致压力下激发出善呢？那就是管理层敢于担责，因为当责任大到下面的同学无法承接时，压力自然外溢，他们形成条件反射式的自保，相互推诿便产生了。管理层担责也同样的逻辑，如果每一层管理层都能清晰认识到自己的管理责任，承接住自己可以承接的责任，和大家统一战线上，鼓励大家重心放在发现问题、解决问题而不是问责上，底下执行层有足够安全的环境，忠诚度、责任心、协作会更好。

一定要相信做稳定性（尤其是专业度高、责任心强）的这批人，他们比任何人都紧张线上故障，你创造安全的环境只会让他们激发更多的责任心。

文章来源：从阿里云大故障看稳定性