一、事故以及简要原因分析
- 小红书故障
-
2023/07/27 03:00～06:30 小红书 APP 闪退
- 原因：官方回应系技术故障，需要删除重装新版本 APP 解决。 猜测 APP 本地数据损坏，和服务端失联无法自动修复了。不得不说移动客户端升级和故障修复相对服务端来说确实难搞，老白兔做服务端的，这方面不展开了。
- 阿里故障
-
2023/10/23 14:07～22:00 语雀服务器故障，在线文档和官网无法打开。
- 原因：服务语雀的数据存储运维团队在进行升级操作时，由于新的运维升级工具 bug，导致华东地区生产环境存储服务器被误下线。7～8 小时的故障恢复时间跟存储节点重建、一致性数据校验耗时有关。
-
2023/11/12 17:39～19:20 阿里云产品控制台访问及API调用出现使用异常。
- 原因：密钥访问服务（AK）读取白名单逻辑存在缺陷，造成不在白名单中的有效请求失败。
-
2023/11/27 09:16～10:58 阿里云云数据库控制台和 OpenAPI 访问异常，实例运行不受影响。
- 滴滴故障：
-
2023/11/27 22:20～2023/11/28 07:31 用户端/司机端/单车 APP全面故障。
- 原因：K8S集群版本升级导致（1.12 到 1.20），升级方案有问题。K8S 这类基础架构和服务出问题太致命了，业务全部挂，什么熔断降级全是浮云。
二、个人思考
- 裁员老员工不是主要原因。网上有种说法最近事故原因是把老员工裁员引起，有点拉仇恨的倾向。这是一个原因但不是主因。新人在大厂核心项目几年经验比有的 10 年老白兔经历沉淀都多，这也是事实（我就是那只老白兔）。
- 降本增效是主要原因。人少事多，人员流动性大，新人接手压力大，容易踩坑。IT从业人员应该有体会，自己负责的系统可能是 5 年以上，好几拨人维护过的老系统，各种坑一言难尽。
- 服务器被裁的也不少，没办法，资源使用率也是大佬们年底的 KPI。以滴滴为例，极端来看如果服务器管够，蓝绿发版，有问题也能及时回滚了
- 开始年终总结了，KPI & OKR必须出结果了，变更搞起来。变更是一切万恶之源。
- 为什么出问题的大部分是国内互联网，而传统 IT 行业、金融行业比较少呢？互联网业务强调快速上线、高频灰度迭代试错。业务层这个思路没有问题，基础架构和服务层这么搞风险就比较高了。老外一般有丰富的方法论和流程管理控制比如 ITIL，国内这方面不够重视或者说投入资源不够。
- 不得不说，老马的X 平台（twitter） 真是个奇葩的存在。人数从 7500 裁到不足 2000 人，老马亲自干预设计、代码 review，几次事故后貌似稳定了。老马在带节奏，国内学到了吗？
三、预防措施建议
鉴于事故频发如同击鼓传花，各个大厂负责人也敏锐的察觉到危险的来临。技术稳定保障部门和高可用小组开始轮番总结、巡检和预防。笔者认为，运动式针对上面事故原因进行查缺补漏能缓解中高层的一部分心理焦虑，根本上还是要解决人、资源和流程的问题。
