故障驱动开发 Outage Driven Development

昨天阿里云发生了一次史诗级故障。看到群里有讨论是否要从阿里云润，我觉得是反过来的，正因为有了这次的大故障，阿里云接下来一段时间的稳定性反而会更有保障。

道理也很简单，稳定性工作一直就没有刷业务有存在感，而真把稳定性做好了，又表现为善战者无赫赫之功的样子。日常工作中，组织内是缺少要素去推动稳定性建设的。稳定性建设的最佳时机都在大故障发生之后。

像支付宝的高可用是在一次光缆挖断事故后建起来的，而整个的资金对账是在一次因第三方集成 bug 导致的资损后开始做的。支付宝内部每年到了当年发生事故的这两个日子，还会组织一系列的技术活动，一方面是让大家铭记敬畏历史上发生的这两次事故，一方面也是对过去一年的稳定性工作进行检验和演练。支付宝事故发生的比较早，稳定性建设起步的时间也比较早，才有了现在不少方面不仅仅是在国内，在整个业界也是领先的地位。

我们自己做 Bytebase，最核心的价值主张就是数据库的变更安全。

我们时不时会碰到失联很久的用户，突然诈尸出现，要加紧配合他们做测试。再问一下，无一例外，都是刚发生了因为数据库变更操作失误，导致的重大故障。

确实偶尔会碰到未雨绸缪的客户，每次碰到这样的团队，我都会在心里为他们决策者的前瞻性点个赞。但同时我也理解剩下的绝大多数。碰到进行中的商务卡住，我常说那我们就等待一个时机吧，而这个时机指的就是一次数据库变更引发的故障。这虽然有点像狐狸等着乌鸦把肉掉下来的感觉，但整个机制就是这么运转的。DBA 和一线研发想引入我们的产品，但只要公司没有出故障，他们就申请不到预算来采购。所以我们只能先在对方那挂个号，然后在他们因为发生过了故障要引入数据库变更管理工具时，成为最好的那个选项。

说回阿里云的故障，看问题是出在用户访问系统上，之前 Google Cloud 也出过相同系统导致的全面故障。

我相信这次故障对于阿里云来说短期利空，长期利好。内部可以借着这次的契机，把系统稳定性提升一个台阶。

从业 15 年，自己也做过不少基础设施，稳定性和研发效能工作。一个有点无奈的事实是，最好用的招还是故障驱动开发 (Outage Driven Development)。