阿里云史诗级故障已经过去差不多两周了。

使用阿里云产品的公司也难以幸免，有所波及。最近听说了一些公司内部的故障复盘，感触颇多。

想到一个问题，稳定性问题的本质到底是什么？

1、它是一个技术问题，但又好像不是

从网上的各种“空穴来风”到阿里云给出的故障复盘报告，大家基本上对这个故障原因有了一些大致的了解。

是一个鉴权服务的白名单变更，没有做好容错处理，导致了灾难发生。

阿里云也给出了相关改进技术措施的说明。

所以，这是一个技术问题。

有的公司受到阿里云故障的波及，可能变成了一场真实的故障演练，暴露出其他额外的问题，比如容灾失效、降级失效等等。

从一个故障，能定义出几个额外的故障，并且列出若干改进措施。

变成了一系列技术问题。

但是，这一系列改进措施未来能够避免故障发生吗？甚至有人能保证不出现类似故障的发生吗？

没人敢说可以。

所以，稳定性问题好像又不是一个技术问题。

至少，不是一个用技术能够完全解决的问题。

2、稳定性问题的本质是什么？

“发展能解决一切问题，不发展一切都是问题。”

其实，稳定性问题的本质也是“发展”的问题。

当业务高速发展的时候，谁有空关心稳定性？

业务真正高速发展的时候，大家忙着开新项目提高营收，“敏捷至上”，哪有什么稳定性问题。

甚至不需要什么设计文档，直接CRUD一把梭上线。出了问题直接在线Debug，在线改代码。

只要能提高营收，这些都不是问题。

公司赚大钱，员工升职加薪。

稳定性问题？无伤大雅。

当业务发展停滞了，开始“降本增效”了，高度重视稳定性。

降本怎么做？最直接有效的方式就是砍服务器资源，砍人员计划。一个人多干两到三个人的活。

业务发展停滞，不代表产品需求停滞。

业务发展停滞，不代表线上运行的服务、组件停滞。

业务发展停滞，不代表历史Bug、技术债停滞。

所以，活不一定会变少，只能是一个人多干两到三个人的活。或者美其名曰，按优先级处理，进一步提高人效。

这种情况下，必然导致故障频发。

这个时候，故障往往又能带来直接的“降本”，比如低绩效甚至直接走人。

这种环境下，故障会进一步被“放在显微镜下观察“，每个人要从中找到别人的锅。流程问题？系统问题？可观测性缺失？有什么漏洞都尽量甩出去。

毕竟甩锅给别人，扣的是别人的绩效，走的是别人的人，是不是根本原因或者有效的改进措施又有什么关系呢。

3、如何解决

公司高速发展，稳定性问题不攻自破。

如果不能高速发展，应该如何解决稳定性问题？

控制合理的人员配比。

如果真的要通过缩减人员降低成本，也应该控制合理有效的业务需求，保证人员的配比是合理的。

不要试图改变客观规律，或者自欺欺人。

否则只会陷入恶性循环。

建设合理的机制与风气。

不管业务是否高速发展，其实对待稳定性问题的态度应该是一致的。

除非是明确违反流程规范引起的故障，其他问题不应该跟直接奖惩挂钩。

每次故障复盘，应该真正反思的是，能不能从架构设计、流程、机制、工具角度找到真正原因，去避免下次同类型的错误。

通过奖惩来高压控制，只会带来甩锅风气，掩盖真正有效的改进措施。

对稳定性保持长期合理的投入。

避免运动式治理稳定性，只在故障发生后的一周或者一个月有重视。

随着系统不断迭代，整体稳定性水平一定会处于一种“熵增状态”，逐步恶化。

所以，稳定性任务，应该持续贯穿在全年，按照合理的比重，与业务功能迭代任务一起评估考量，才能确保长期处于相对高的稳定性水平。