【周末瞎想】从阿里云故障想到,稳定性问题本质是什么

原创
2023/11/26 08:30
阅读数 30

每周总得有点思考。

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

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

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

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

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

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

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

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

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

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

变成了一系列技术问题。

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

没人敢说可以。

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

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

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

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

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

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

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

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

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

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

稳定性问题?无伤大雅。

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

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

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

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

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

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

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

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

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

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

3、如何解决

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


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

控制合理的人员配比。

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

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

否则只会陷入恶性循环。

建设合理的机制与风气。

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

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

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

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

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

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

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

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






往期热门笔记合集推荐:


原创:阿丸笔记(微信公众号:aone_note),欢迎 分享,转载请保留出处。

没有留言功能的悲伤,扫描下方二维码「加我」聊些有的没的吧~

                                                                              觉得不错,就点个  再看 吧👇



本文分享自微信公众号 - 阿丸笔记(aone_note)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部