12|变更场景(二):一次简单升级竟然损失几千万
白园
你好,我是白园。
上一节课我们分析了基础设施的变更导致的重大故障的案例,今天我们进入第二个案例分析——基础平台的变更导致的重大故障,案例来自某网约车公司。
案例回顾
2023 年 11 月 27 日晚间,某网约车公司的移动应用程序遭遇了一场严重的系统故障,导致了一系列的服务中断问题。这些问题主要包括:司机无法定位到乘客、乘客等待打车的时间异常延长、用户取消已下单的行程以及地图服务长时间显示网络连接异常。这次服务故障持续了整整 12 个小时,成为了某网约车公司近年来所遭遇的最长时间的瘫痪事件。
故障原因
根据该网约车公司官网发布的公告,服务在 28 日恢复正常后,公司立即启动了内部的复盘调查程序。调查的初步结果显示,事故的根本原因是底层系统软件出现了故障,并非如网络传言所说的“遭受外部攻击”。
同时,网络上有关于 Kubernetes 故障的讨论。据分析,这次事故很可能是由于 Kubernetes 在升级过程中出现了问题,导致系统降级。
经过对网络上的传言、某网约车公司官方声明及相关技术资料的综合分析,这里我们可以得出初步结论:这家网约车公司在 Kubernetes 系统升级过程中,可能采取了原地升级的方式。然而,不幸的是,在升级过程中使用了与现有系统不兼容的版本,这一技术失误最终导致了服务的大规模中断。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
1. 某网约车公司的移动应用程序遭遇了严重的系统故障,导致一系列的服务中断问题,持续了整整12个小时,成为了该公司近年来所遭遇的最长时间的瘫痪事件。 2. 故障的根本原因是底层系统软件出现故障,可能是由于Kubernetes在升级过程中出现问题,导致系统降级。 3. 在变更前,实施双人审核机制、平台管控策略和制定清晰可执行的回滚方案,以及进行多次演练,确保尽可能安全、快速。 4. 需要特别关注业务指标,观察是否存在大量重启的情况,以及业务指标是否产生波动,一旦发现异常,就应该马上停止升级,并采取屏蔽措施。 5. 在故障恢复阶段,需要业务层做容灾和逃生,实施流量切换策略,启用逃生机制,以减少故障对用户的影响。 6. 需要做好充分的准备,主要包括变更前的充分检测、严格执行分级发布,还有可靠的升级方案、集群拆分以及快速止损方案。 7. 在Kubernetes层面,可以主动执行服务迁移操作,将受影响的服务从故障区域迁移到健康区域,以恢复服务的正常运行。 8. 应急响应机制包括用户安抚、服务降级、专业团队介入、沟通策略和后续跟进,以维护公司形象和用户信任。 9. 针对K8s的升级,需要制定明确的沟通策略,确保所有信息发布都经过严格审核,避免造成误解或恐慌。 10. 需要避免简单的故障,需要重视变更前、变更中、变更后三个阶段的变更思路和规范。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《SRE 实践:服务可靠性案例课》,新⼈⾸单¥59
《SRE 实践:服务可靠性案例课》,新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
- E这里我们从技术角度和公关角度来看。 ———这里的“公关角度”没讲啊2024-08-09归属地:贵州
收起评论