原文： mp.weixin.qq.com/s/2e2ovuwDrmwlu-vW0cKqcA
省流版：
故障的原因是云 API 服务新版本向前兼容性考虑不够和配置数据灰度机制不足的问题。
本次 API 升级过程中，由于新版本的接口协议发生了变化，在后台发布新版本之后对于旧版本前端传来的数据处理逻辑异常，导致生成了一条错误的配置数据，由于灰度机制不足导致异常数据快速扩散到了全网地域，造成整体 API 使用异常。
发生故障后，按照标准回滚方案将服务后台和配置数据同时回滚到旧版本，并重启 API 后台服务，但此时因为承载 API 服务的容器平台也依赖 API 服务才能提供调度能力，即发生了循环依赖，导致服务无法自动拉起。通过运维手工启动方式才使 API 服务重启，完成整个故障恢复。
想起了之前传闻某团队修复健康码因为健康码无法展示进不了大楼的事情了

好奇健康码那事后来在哪修复的，门口蹲着？

灰度跟生产不可能一模一样，系统越复杂，差异越是大。在大多数复杂系统中，这个问题是个千古难题。

人家运维公司说不清楚，不知道有没有当时的大佬现身说法了， news.sina.cn/gn/2021-12-22/detail-ikyamrmz0473496.d.html

跟滴滴的那个有点像，升级出现问题后回滚困难。强行回滚时候又发现互相依赖的问题。

随着时间的发展，人员不断流动，系统越来越大，业务越来越复制，代码越来越多，数据越来越多，导致的结果就是没人能了解全局了，所以这肯定不是最后一次故障，以后还是会有的。

结果是因为升级 API 导致的... 是不是该抓一个程序员来祭天

yysy 拉个程序员祭天意义不大 hhh

循环依赖的解决办法不就是再引入一个 C ，解开 AB 的相互依赖？

API 不兼容导致了事故，但灰度机制不足才导致事故扩大到了全网。

贴一下去年阿里云 help.aliyun.com/noticelist/articleid/1064981333.html

挺好的，发一个故障分析，起码态度到位了

复杂度提升导致崩溃度增加。国内 IT 界甚至这届人类体系都是这趋势。

“期间共有 1957 个客户报障” 控制台都打不开了，是怎么报障的，只有有客户经理的才能算受到影响？

有人要打包走人了

估计工单系统还正常吧

＃8 没有用的， 谁都知道问题的解决办法， 但是随着人员流动， 系统越来越庞大， 所有的机制都会维护不到位。

题外话，你们的 100 元代金券到账了吗？

工单在控制台里面,整个控制台当时都 502/504/internal error 了

我看了一个文章，是关于服务状态监控的，他们的服务状态监控就是个摆设，状态有延迟也就算了，还不全（比如服务 A 挂了也影响到了 B ，他们的状态里面没有显示 B 的异常）

相比于国外厂商的 PIR, 这个故障分析很是避重就轻, 避实就虚.

同时回滚到旧版本，并重启 API 后台服务，但此时因为承载 API 服务的容器平台也依赖 API 服务才能提供调度能力，即发生了循环依赖。这是哪个脑残设计的自己把自己锁死在房间里的架构？

100 元代券都还没到账

互联网公司循环依赖太常见了。比如去年 yuque 故障、阿里云故障、滴滴故障，其背后都和循环依赖有关系。一个关键服务挂掉后，其他服务没法直接恢复。

不都这样吗？还记得 Facebook 不，机房的锁也是内网控制的，内网挂了机房连门都进不去。

没进过大厂, 不知道他们备份机制是怎么样的, 我们上线前都会备份当前版本为 docker1, 即将上线的版本是 docker2, 上线完成后的版本是 docker3, 出现依赖问题就全部回滚为 docker1, 几年从没出过问题

＃12 我当时就用的在线客服报障的啊

之前不是有人在吹外国怎么怎么样，国内怎么怎么样。。。听的我直犯恶心，现在腾讯发问了，不知道这类人怎么回复。

100 代金券说好要给,最后都不舍得给,抠门的要死

报告里面说了都嘛，回滚依赖于平台的 API ，而 API 又故障了，最终是靠运维手动回滚的。 你们公司应该就是纯手工回滚 docker2 ， 就不存在这种循环依赖了。

100 代金券未到账，找售后也没反应了

我们是通过企业微信群报的

那就重构 🐶

graphicscardprice.com/ 好简陋的网站

＃8 那以后的 C ，不就成了现在的 B ？

摆设, 肯定是摆设, 1. 状态不及时更新 2. 对外公布异常/故障要层层审批

AB,AC

更正：AC ，BC

这个吗 s.hesudu.com/t/1030870

＃37 所有服务不还是依赖了 C ，难道 C 以后不会迭代更新了？

＃17 没有

点开非法加冯公众号看看有没有新的文章。

mp.weixin.qq.com/s/SpxKyjSb1luCrJ8xIFjylg还真有

似曾相识

草台班子

不知道为什么在周末发，希望不是我的恶意揣测

图 2 那种流量图，是什么工具画的？之前运营商给我流量图也是这种样式的。

对比 cf 的复盘,企鹅的毫无诚意

我的 4 月 12 日给了

为什么在周末发？怕别人不知道你腾讯 996 啊。。

＃32 重构除了引入新的坑之外，然后又会重新走一遍上面的流程。总之就是不停的有坑哈哈哈哈

再也不觉得大厂牛逼了，这么庞大复杂的系统，原来也是草台班子...

国内很多企业不是技术位需求服务，而是为了跟进新技术和显得自己有技术而使用新技术。。。殊不知新技术就是不稳定的。

别说这种大厂了，就是小公司在几年之后，人员流动，系统逐渐复杂，根本没有人会想去了解全局的。大多数人都会直接摆烂，跟着原来的流程逻辑走，能打补丁就打补丁，于是祖传屎山代码就出现了，然后指不定哪天就原地爆炸了。老板们都以为人员迭代业务交接的清清楚楚明明白白是理所当然的，所以在他们看来人员迭代不会有代价的，但事实上培养一个能了解全局的员工是需要大量时间的，有时候倒不是刻意不配合交接，东西太多太杂，交接的时候根本没想起来，那么一个小问题导致故障这种情况就太正常了，剩下的人抓瞎就更正常了。

按照描述我觉得应该是浏览器缓存的旧的前端页面 js ，然后请求改动后的接口，导致异常。

并没有

出这么大事儿 复盘会还没开就敢休息吗。。。这确实也不现实。

我的已经收到了 可以再查询一下

很搞笑： [腾讯云] 您好，您之前提交的代金券申请，经过后端复核您在故障期间未登录控制台，并且未有调用云 API 相关接口记录，因此判断您未受到本次故障的影响，非常抱歉暂无法为您申请代金券。感谢您关注腾讯云，欢迎随时体验相关产品和服务，若您在使用产品时遇到任何问题，请随时联系我们，感谢您的理解与支持！

腾讯云这个月的 kpi 是不是想尽办法少补偿用户

垃圾腾讯云，说好的补偿代金卷，后面又不给了！

＃58 我也收到了。虽然也就 100 ，但感觉好小气哈哈

api 错误会被系统统计到，所以可以得到错误人数，再加上后续主动报障的工单。就算出来了。

没什么搞笑的，估计售后被薅秃了

被判定为薅羊毛了，先自查下，确定自己被影响了，要再多些也没毛病。

是的，拖了 5 天，最后说故障期间没有登录记录，不给券，RTM ，我打算迁移服务到阿里云了

＃64 明知道那时故障了还要去登录，才能代表受到影响？徒增系统负载罢了，看来以后得弄个脚本，每分钟去登录一次控制台

API 循环依赖，一直以为只有草台班子才能够搞出这种

没有，我问了客服，他们说未受到影响。。。。

难道不是 b 站 slb 炸了然后 vpn 连不进去吗（

＃24 cf 去年 11 月 PDX-04 停电故障，据说配电室门禁是由配电室供电的