阿里云史诗级故障已经过去差不多两周了。
使用阿里云产品的公司也难以幸免，有所波及。最近听说了一些公司内部的故障复盘，感触颇多。
想到一个问题，稳定性问题的本质到底是什么？
1、它是一个技术问题，但又好像不是
从网上的各种“空穴来风”到阿里云给出的故障复盘报告，大家基本上对这个故障原因有了一些大致的了解。
是一个鉴权服务的白名单变更，没有做好容错处理，导致了灾难发生。
阿里云也给出了相关改进技术措施的说明。
所以，这是一个技术问题。
有的公司受到阿里云故障的波及，可能变成了一场真实的故障演练，暴露出其他额外的问题，比如容灾失效、降级失效等等。
从一个故障，能定义出几个额外的故障，并且列出若干改进措施。
变成了一系列技术问题。
但是，这一系列改进措施未来能够避免故障发生吗？甚至有人能保证不出现类似故障的发生吗？
没人敢说可以。
所以，稳定性问题好像又不是一个技术问题。
至少，不是一个用技术能够完全解决的问题。
2、稳定性问题的本质是什么？
“发展能解决一切问题，不发展一切都是问题。”
其实，稳定性问题的本质也是“发展”的问题。
当业务高速发展的时候，谁有空关心稳定性？
业务真正高速发展的时候，大家忙着开新项目提高营收，“敏捷至上”，哪有什么稳定性问题。
甚至不需要什么设计文档，直接CRUD一把梭上线。出了问题直接在线Debug，在线改代码。
只要能提高营收，这些都不是问题。
公司赚大钱，员工升职加薪。
稳定性问题？无伤大雅。
当业务发展停滞了，开始“降本增效”了，高度重视稳定性。
降本怎么做？最直接有效的方式就是砍服务器资源，砍人员计划。一个人多干两到三个人的活。
业务发展停滞，不代表产品需求停滞。
业务发展停滞，不代表线上运行的服务、组件停滞。
业务发展停滞，不代表历史Bug、技术债停滞。
所以，活不一定会变少，只能是一个人多干两到三个人的活。或者美其名曰，按优先级处理，进一步提高人效。
这种情况下，必然导致故障频发。
这个时候，故障往往又能带来直接的“降本”，比如低绩效甚至直接走人。
这种环境下，故障会进一步被“放在显微镜下观察“，每个人要从中找到别人的锅。流程问题？系统问题？可观测性缺失？有什么漏洞都尽量甩出去。
毕竟甩锅给别人，扣的是别人的绩效，走的是别人的人，是不是根本原因或者有效的改进措施又有什么关系呢。
3、如何解决
公司高速发展，稳定性问题不攻自破。
如果不能高速发展，应该如何解决稳定性问题？
控制合理的人员配比。
如果真的要通过缩减人员降低成本，也应该控制合理有效的业务需求，保证人员的配比是合理的。
不要试图改变客观规律，或者自欺欺人。
否则只会陷入恶性循环。
建设合理的机制与风气。
不管业务是否高速发展，其实对待稳定性问题的态度应该是一致的。
除非是明确违反流程规范引起的故障，其他问题不应该跟直接奖惩挂钩。
每次故障复盘，应该真正反思的是，能不能从架构设计、流程、机制、工具角度找到真正原因，去避免下次同类型的错误。
通过奖惩来高压控制，只会带来甩锅风气，掩盖真正有效的改进措施。
对稳定性保持长期合理的投入。
避免运动式治理稳定性，只在故障发生后的一周或者一个月有重视。
随着系统不断迭代，整体稳定性水平一定会处于一种“熵增状态”，逐步恶化。
所以，稳定性任务，应该持续贯穿在全年，按照合理的比重，与业务功能迭代任务一起评估考量，才能确保长期处于相对高的稳定性水平。
往期热门笔记合集推荐：
- HBase原理与实战笔记合集
- MySQL实战笔记合集
- Canal/Otter源码与实战笔记合集
- Java实战技巧笔记合集
原创：阿丸笔记（微信公众号：aone_note），欢迎 分享，转载请保留出处。
