阿里云宕机带来的稳定性思考

上个月语雀服务宕机 6+小时，冲上了热搜。作为语雀的深度付费用户，且作为一个 IT 技术从业人员，对这件事还是很关注的。毕竟作为一个日更的技术博主，我的习惯都是在语雀写好草稿，然后复制到公众号等平台发布。

针对语雀服务宕机这件事，我当时还写了一篇文章《语雀服务宕机带来的稳定性思考》，分享了一些我对于稳定性保障的理解和业内比较通用的几点方法。

没成想，上周日晚，阿里系的产品又出问题了，只不过这次，从语雀换成了阿里云。语雀从当事人的角色，变成了事故现场被波及的当事人兄弟，真的有点让人咋舌不已。

这次大规模的产品事故，官方的通告如下：

从事故发现到完全修复，总计不可用时长超过了 3 小时，严格来说是很严重的生产事故。按照业内比较通用的故障定级标准，P0 级的故障定级没跑了。本次故障的直接影响范围包括：云产品控制台、管控 API 等功能，以及 OSS、OTS、SLS、MNS 等产品服务。但间接影响和造成的损失，其实是无法估量的。

首先，目前国内的公有云市场，阿里云还是占据最大的一份市场份额，各行各业服务上云的企业成千上万。几个小时的服务不可用，特别是在双十一这个年底冲业绩的时间节点，影响太大。

其次，云服务这几年逐渐成了事实上的公共基础设施之一。如果说水电煤是现实生活的硬件基础设施，那网络、手机和云服务就是必备的软件基础设施，二者对现代人的重要性不言而喻。

最后，云服务更多的还是直接面向企业提供服务，对个人的服务从量级来说相对较小。但无数个大大小小的企业却是基于云服务为很多个人用户提供购物消费娱乐服务，间接的影响触角，遍布全球。

对于云服务这种基础服务设施，业内有很多的稳定性保障手段和实践案例，比如：生产全链路压测、混沌工程、异地多活、灾备演练。据不完全数据统计，很多的线上服务故障都是由变更导致的，在涉及线上变更操作时，业内也有很经典的三可：可监控+可灰度、可回滚。

阿里内部，关于线上服务稳定性保障，也有经典的 1-5-15 机制(1 分钟发现问题，5 分钟介入问题修复，15 分钟故障恢复)。

当然，只要是人构建的系统，或多或少都会出问题。作为工程师要考虑的，一方面是降低出问题的概率和影响范围；另一方面则是即使出问题也要做到尽快发现和修复。其中还包含一个前提和一个兜底：前提是优先保障业务正常运行，兜底是要求线上服务时刻要有应急措施和手段，即所谓的应急预案来作为服务稳定性保障的兜底。

从事质量保障工作将近十年，前几年我还在某互联网电商企业担任稳定性测试团队的 Leader 一职，团队的主要职责也是保障公司线上服务和基础技术组件的质量以及稳定性。

从个人的实践经验来说，稳定性这个东西，某种程度上是一个薛定谔的猫状态。因为事实证明只要是个系统，就没有不挂的，业内也从没有哪个公司的系统一直稳定运行不出问题；但是从技术手段和标准的变更流程规范来说，基本上所有已经发生的线上问题，都是可以避免的。

换句话说，我们所熟知的各种线上服务故障，基本上都是人为因素导致的，且其中相当大一部分，是没有遵守技术规范和标准流程操作所引起的。只要愿意长期坚持且投入精力去做，稳定性保障，其实并不是一个特别难的事情。

想起以前做稳定性保障工作时候，和同事聊天时说的一个笑话：“每次公司线上出故障，基础架构团队的负责人都要背锅或者要换人”。稳定性保障这件事，严格来说是一个吃力不讨好的事情，做得好了是应该的，做不好就是你的责任。

从技术的长期价值角度来说，稳定性保障就是防患于未然，通过长期的技术投入和迭代优化，不断适应和支撑业务的变化发展。但技术投入这件事本身就没有很稳固的确定性，即投入和产出无法直接画上等号。

遇上降本增效，或者换一个重业务轻技术的领导上台，技术团队就是第一个被砍的。毕竟在国内这种环境，哪儿来的技术导向和工程师文化，不都是营销为王和短期利润为重。

再说，谁让你技术团队是成本部门，而不是利润部门呢？降本，不砍你砍谁！