13 变更场景（三）： 连续绊倒两个云厂商的故障
你好，我是白园。接下来我们进入变更的第三个场景——程序和数据类型的变更。今天我就来给你分享一种非常有意思的故障，这种故障连续绊倒了两个云厂商。
故障回顾
2024年4月8日，某云团队收到告警信息，云API服务处于异常状态。随即在某云工单、售后服务群以及微博等渠道开始大量出现某云控制台登录不上的客户反馈。经过故障定位发现，客户登录不上控制台是由于云API异常导致的。云API是云上统一的开放接口集合，客户可以通过API以编程方式管理和操控云端资源。
故障发生后，依赖云API提供产品能力的部分公有云服务，也因为云API的异常出现了无法使用的情况，比如云函数、文字识别、微服务平台、音频内容安全、验证码等。此次故障一共持续了近87分钟，期间共有1957个客户报障。
同样的事情也发生在另一家云上，不过是在2023年，云产品控制台访问及管控 API 调用出现异常。原因代码的逻辑缺陷，生成了一份不完整的白名单，进而影响了整个云API服务。
案例解析
原因解析
故障的原因是云API服务新版本向前兼容性考虑不够，以及配置数据灰度机制不足的问题。本次API升级过程中，由于新版本的接口协议发生了变化，在后台发布新版本之后对于旧版本前端传来的数据处理逻辑异常，导致生成了一条错误的配置数据，由于灰度机制不足导致异常数据快速扩散到了全网地域，造成整体API使用异常。
重启API后台服务，但此时因为承载API服务的容器平台也依赖API服务才能提供调度能力，即发生了循环依赖，导致服务无法自动拉起。只能通过运维手工启动方式才能使API服务重启成功，完成整个服务恢复。
从客户的视角来看，云服务大致可以分为数据面和控制面，数据面承载客户自身的业务，控制面负责操作云上不同产品。比如目前使用最广泛的IaaS服务基本上都是以直接面向数据面为主，控制面仅在客户购买或需要对资源层面进行调整操作时会用。此次发生的故障就在控制面。通俗来讲，如果把云服务类比为酒店，控制台相当于酒店的前台，是一个统一的服务入口。一旦酒店前台发生故障，会导致入住、续住等管理能力不可用，但已入住的客房不受影响。
问题解析
- 检查机制的缺失： 在全面推广前，似乎未进行充分的检查工作。从故障发生的角度来看，数据格式的错误是首要问题。在发现错误后，似乎没有检查和灰度测试的步骤，而是直接将数据推送到了生产环境。在数据上线前，缺乏必要的审核和分阶段部署机制，未经筛选的数据被直接全面推送，这影响了所有用户。
- 数据隔离策略的不足： 尽管服务层面采取了隔离措施，但在数据层面，却未能实施有效的隔离策略。这使得数据被错误地广泛传播。
- 循环依赖问题： 存在一个循环依赖的设计缺陷，其中预案和服务相互依赖。当API服务发生故障时，这种依赖关系阻碍了预案的及时启动。
- 升级与回滚问题： 在最近的升级中，API版本和配置数据都进行了更新。然而，在发生故障的时候，回滚操作只会滚了服务版本，没有在第一时间回归配置数据。
优化措施
我们应该从三个关键方面进行考量：首先，探讨是否有可能预防问题的发生，以及预防的具体方法；其次，评估是否能够加快处理流程，并探索可能的加速手段；最后，想想还有哪些其他方面存在优化空间。
预防数据格式错误
深入探究数据格式错误的根本原因，特别是程序缺陷，并针对性地增强程序健壮性，以彻底解决问题。建立一套严密的数据校验体系，以确保所有数据在推送至生产环境前都经过了全面的审查。重点检查数据格式是否与现实标准相匹配。只有通过这一校验的数据才能继续进入后续流程。
控制上线影响
采用分阶段的灰度发布方法，逐步引入新功能或配置更改。这一策略旨在通过在有限的用户群体中先行部署，快速识别潜在问题，并在必要时迅速执行回滚操作。例如，可以增设一个模拟线上环境进行详尽的测试和验证。这不仅有助于在早期发现并解决线上问题，同时也能提前识别线上环境中可能出现的故障。
这个案例里的回滚策略不够明确，初期仅对程序进行了回滚，忽略了配置数据的同步回滚，从而加剧了问题的扩散。更为妥当的做法是同步回滚程序和配置数据，确保系统恢复到一个已知的稳定状态，而不是单一地选择回滚程序。
我建议采用分阶段、区域化的方法更新。先在选定的试点地区（如北京）引入新功能或进行更新。然后，监控一段时间，验证新功能或新版本的稳定性。一旦确认试点地区的更新无误，再逐步将更新推广至其他地区的集群，最终实现全面部署。这种策略有助于控制更新风险，防止所有地区同时爆发。
我们可以部署一个自动化的异常检测与熔断机制，以实现对系统异常的即时响应。该机制能够在识别到任何异常时，迅速采取行动，中断当前的变更流程。例如，如果在区域1发现问题，该系统将自动触发暂停部署的措施，有效遏制问题蔓延至其他区域。
提升恢复速度
首先，我们需要评估故障发生后的响应时间。例如，在一次故障中，定位问题耗时23分钟。在问题出现时，虽然立即执行了程序回滚，但配置数据没有一并回滚，这导致初步恢复措施没能奏效。如果程序和配置都已经更新，就必须同时进行回滚，确保系统恢复到稳定状态。所以，定期进行变更策略的模拟演练至关重要，这有助于确保在真实故障发生时，团队能够迅速启动恢复流程，将服务中断时间降到最低。
在配置和程序需要同时更新的情况下，应避免同时进行变更。我建议先完成一项变更，再进行下一项，确保过程清晰、可控。
简化API服务中的预案，减少API间的循环依赖，从而增强各服务单元的独立性并提升整体系统的稳定性。这样，在遇到问题时，可以确保系统能够安全地执行回滚操作。此外，还需要为API服务设计并实施逃生通道机制，确保在系统故障发生时，能够迅速切换至备用路径。
值得学习的地方
他们在对外公告方面的表现值得称赞，不仅提供了详尽的事件细节，还对各种情况给出了清晰的解释，从而获得了公众的广泛好评。在故障通知中，明确指出了受影响的业务范围、故障的根本原因以及预计的修复时间，保持信息的透明度和及时性，这一点也得到了大家认可。
故障处理流程也有值得学习的地方，在复盘的文章中给出了每一步的思考和决策，目前来看没有大的失误。
小结
这节课我们重点分析了数据变更中需要关注的点，同时我把别人做得好的地方和不好的地方整理了一个表格供你参考。
至关重要的一点是，我们必须认真吸取他人的经验教训。对此问题应持有严肃认真的态度，避免任何冷漠或嘲讽的情绪。面对类似事件时，我们应积极思考如何进行改进和优化。回顾去年，某云服务在遭遇另一云服务提供商的故障时，似乎未能吸取教训或采取必要的整改措施，结果导致自身服务也出现了问题。
思考题
假如你需要进行配置变更、代码发布、数据更新，那么你的执行顺序是什么？另外你平时有学习别人的案例吗，说说如何把别人的经验应用到自己的业务上。欢迎你把你的答案分享到评论区，也欢迎你把这节课的内容分享给其他朋友，我们下节课再见！