阿里云大故障后问责机制来了

上一篇《从阿里云大故障看稳定性》提到稳定性要做好很关键的一个点，就是：自上而下的认可

目前看来阿里云在此次大故障后，管理层自顶向下形成了一定的责任机制，将故障和高层管理者的奖金直接挂钩，这或许可以逼着管理层从KPI设定上开始有意识的重视稳定性工作。对自上而下的认可有帮助。

---

一个超级大故障，其实是层层安全防线都被击穿，说明系统脆弱性极强。

第一层：应急快反被击穿

系统优先做好业务和资源的梳理和分级，核心业务一定要配置好监控、告警、演练常态化，形成应急机制、巡检机制，出现问题可快速发现、快速预案、快速恢复；

这一层基本上可以挡掉20%的故障

第二层：规范被击穿

优先提升稳定性意识，做好变更管控、流程规范；

比如变更管控规范、分析设计规范、发布评审规范、CR规范都要非常严谨细致；

这一层可以挡住70%的故障

第三层：架构被击穿

核心业务（会影响到大量客户）设计上尽可能遵循高可用几大原则，比如少依赖原则、弱依赖原则、自保护原则、去单点原则、分散原则、隔离原则、均衡原则；

这一层重点在于规避大故障，理论值上分析是可以最大程度规避超大故障的

---

分享我了解到的几个关于建设稳定性怪象

一、稳定性建设搞成运动式

出一次大故障，从上到下开始各种复盘，纠错，定责，然后再起稳定性战役，领导们以为和营收战役一样，战役包治百病，只要战役一结束，目标达成，这个事情也就成功了结束了。

然而稳定性最关键的还是做在平时，每一次的变更是否充分分析稳定性风险，做好规范约束，架构上有没有破坏高可用原则，全链路有没有引入高风险依赖，这些不是一次战役就能解决的问题。

做成运动式，会导致周期性大故障，一旦运动停了，没人关注了，稳定性又回退了。

二、稳定性做好是应该的做不好得挨板子

稳定性是生命线，所有人都在大喊这句话，似乎很是重视，但在奖惩上又显得异常矛盾，守护如此重要的生命线，只有惩没有奖？不过我作为管理者，对我团队做稳定性的同学，始终坚持自己的理念，充分看见这件事背后的辛苦，对他们只会做奖励上的倾斜，相反一些非低级问题导致的故障却不会追责。

三、稳定性建设要自证价值

很容易被一些不太懂技术的同事问道：你们不是做过稳定性战役吗？怎么还有稳定性的事情？稳定性投入的人力什么时候可以释放出来？

除了有大流量高并发经验的技术同学外，其他人很难理解：稳定性是一个长期持久的事情，只要流量在上涨，客户在增加，业务在丰富，那么稳定性的事情就不会中断。

业务能力建设的价值，只要业务做成了，客户使用了，促进营收，价值自然凸显；

遗憾的是，稳定先建设的价值，没法通过你做好了，不出故障进行证明，因为大家默认这是应该的。通常只有出故障了，才能唤醒大家对稳定性建设价值的认可。

四、稳定性累心累力很难被看见

保障高并发系统稳定运行意味着多少水下面的工作，其实没有体验过是很难理解的，这其中会承受的稳定性高压、繁琐的运维工作、监控告警24小时应急、日常设计全面风险把控等等，这所有的事情都没法像做业务那样容易被看见。

---

最后，稳定性到底该怎么投入？

一、先判断稳定性是否作为产品核心竞争力

如果是，那么就要坚定信念，持续不断地建设

如果不是，没有必要过度投入，还是要充分考虑ROI

二、如何平衡稳定性和业务支撑？

稳定性是底盘，保障一定比例持续投入，比例情况视稳定性水位而定

同时也要支撑好业务发展，毕竟商业的价值是服务客户，产生营收

三、如何激发稳定性建设持续的活力？

尊重和看见是对稳定性人最好的激励

做得好要充分认可和激励

平时小问题不放过、大问题轻轻过

稳定性意识绑在脑门上

文章来源：阿里云大故障后问责机制来了