15 预案场景（二）：一次机房故障为何让多位高管被辞退？
你好，我是白园。这节课我来分享一下互联网中比较常见的故障—单机房故障。我们先来看三起故障案例。
2023年3月某电商平台发生P0级故障宕机12小时，业绩损失超亿元，影响客户800多万，故障的主要原因是南沙 IDC 冷冻系统故障，机房设备温度快速升高宕机，线上商城停止服务。由于崩溃时间太长，很多消费者无法正常下单。此次事故暴露出该公司容灾应急预案和风险防范措施不到位，该公司对基础平台部负责人做了免职处理。
2022年7月4日傍晚，一家外卖服务平台发生了大规模的服务中断，用户无法正常下单。经调查，故障的原因是该平台当地数据中心的电力供应出现了问题。尽管数据中心设有柴油发电机作为备用电源，但在此次事件中，发电机未能成功启动。在随后的恢复过程中，还发现监控系统也受到了影响，未能及时检测到问题。此外，在尝试切换到备用系统时，发现之前的切换操作并未按预期进行，这进一步加剧了故障的严重性。
2023年3月，一家知名社交软件公司遭遇了严重的服务中断，起因是其数据中心的冷却系统出现了故障。此次冷却系统的失效直接导致了服务瘫痪，对广大用户的日常使用造成了显著影响。尽管公司有进行常规演练，但这些演练与实际发生的故障情景存在较大差异，导致现有的应对措施效果不佳。事后多名主管被通报批评。这次故障暴露了公司在容灾设计和应急预案方面存在的不足，有关业务部门的风险防范意识不到位。
这三个故障都有一个共同的特点就是机房故障，并且是一个机房发生了故障。所以这节课我们讨论的重点就是如何应对单机房故障。
什么是单机房故障？从故障域的角度来分析，把故障局限于一个机房内的情况就是单机房故障。我们之所以讨论单机房而非多机房冗灾，主要是因为单机房出故障的概率比较大，是互联网行业中一个普遍存在的问题。多机房故障的应对成本会显著增加，而且发生的概率极低。
如何应对单机房类型的故障？
这里我们从三个角度去看，首先是能止损，其次是快止损，最后是损失最小。
能止损
无论是通过人工操作还是自动化平台，实现紧急逃生能力是首要任务。而要达到这一目标，关键在于解决多活建设这个核心问题。多活策略包括异地多活和同地多活两种形式。异地多活的架构更复杂，而且在大多数情况下，为了提高系统的可靠性，如果没有强制的要求，同地多活其实已经足够的。所以这节课我们就重点探讨同地多活这种形式，主要包含 3 个关键动作：单点消除、避免混联、依赖消除。
我们先看消除单点，当系统中存在单一实例或所有实例都部署在同一个物理机房的程序模块的时候，就叫做单点，你可以结合示意图来理解，其中服务 C 就是单点服务，一旦机房或服务本身出现故障，就无法通过流量调度或主备切换等常规手段实现快速止损。
那么怎么解决呢？对于常态请求的处理，必须确保不存在单点问题。而对于那些无法消除单点的提交请求处理场景，比如在有序提交场景中进行ID分配，就需要制定一套完整的备份方案，无论是热备份还是冷备份，都要确保在单机房故障发生时，可以迅速切换到其他机房。
第二个关键动作就是消除混联，也就是上下游服务之间存在常态的跨机房调用。为了解决这个问题，我们可以把服务拆分成若干个不同的逻辑单元，每个逻辑单元处于不同的物理机房，都能提供产品线完整服务。实施严格的程序部署隔离措施，防止不同逻辑单元之间的非授权连接，确保故障都被限制在单一逻辑服务单元内。
第三个动作就是依赖解耦，上下游服务使用固定IP或固定机器名进行直接连接。单机房故障发生时，关联的上下游之间无法进行快速的流量调度止损。
这个问题怎么解决呢？线上服务关联不允许使用固定IP或机器名连接，需要使用具备流量调度能力的上下游连接方式以实现上下游依赖解耦，下游服务发生单机房故障，可以快速调整路由比例实现止损。实现上下游服务之间的松耦合，提升系统的灵活性和可维护性。确保上下游服务能够独立进行流量调度和自动切换，不依赖于对方的状态，从而提高系统的鲁棒性和自适应性。这里我们可以采用业务最常用的服务网格技术进行调度。
快判断、快决策、快执行
快速判断
当出现故障的时候或者报警的时候，就需要在3分钟内做出判断，是不是误报，我遇到过几次都是监控平台本身的问题引发了误判。为了防止误报，我建议你用多个监控平台对比一下。如果只有一个监控平台，那就用脚本设置一个非常简单的测试，来做个校验。
在确定不是误报之后，我们就要确定故障范围了，判断故障是局部的还是整个机房的问题。这可以通过平台来实现，快速定位故障的范围。接下来进一步分析故障类型，是单机问题、单网段问题还是单机房问题。最后检查IP列表，查看故障IP列表的网段分布情况。如果IP地址聚集，可能表明是交换机等网络设备引起的问题；如果IP地址分散，可能意味着机房本身存在问题。
快速决策
为了最小化故障对业务的影响，我们需要精心设计预案的组合策略。关键在于判断是否需要执行流量切换，以及哪些服务需要进行切换。重要的是，并不是所有服务都必须进行流量切换操作。在这个过程中，应该进行细致的影响评估，确保切换仅限于那些确实受到影响的服务，避免引起不必要的扩散。
在问题发生后，必须立即关注系统的容量状况。过快的流量切换可能导致系统过载，从而引发二次故障和更多问题。因此，切流操作需要谨慎进行，以免加重系统的负担。
在执行切换操作时，应该确保系统的容量能够满足N+1的需求，就是至少有一个额外的容量单元以应对故障或过载情况。考虑到成本因素，即使在降级后，系统还是应该保持N+1的冗余容量。
为了实现这个目标，我们可以通过月度在线压力测试来验证系统在高负载下的表现，并确保容量规划的合理性；还要进行实时监控，在检测到容量过载的时候，能够及时触发熔断信号，防止系统崩溃。
快速执行
我们需要构建一个平台化的预案执行机制，其中包括常用的流量切换手段。这种切换可以是多层次的，包括接入层、服务层、存储层以及依赖服务和中间件的切换。平台化的建设旨在解决元信息管理等关键问题。这里我给你一个预案平台的逻辑框架，供你参考。
了解现状
在故障发生时，需要迅速掌握以下信息：
- 哪些业务已经实现了多活？
- 业务采用的是哪种多活类型，是同城双活还是异地单元化？
- 哪些URL规则支持多活，目前的多活流量调度策略是什么？
多层切流策略
将流量调度分为几个层面，包括：
- 接入层：处理从外网用户发起的请求，使用DNS技术实现外网流量的调度。
- 服务层：服务层之间常见的切流方式就是服务网格或者是利用LB进行内网调度。
- 存储层：包括数据库的主从切换，在切换的同时我们要保证数据的一致性。
更加详细的介绍你可以参考一下前面基础篇预案的部分。
如果容量实在不足可以把非核心服务进行降级。这种降级策略可以释放资源，提高系统的容错能力。同时需要考虑紧急扩容的事宜。
除了采取必要的技术手段来应对故障外，我们还可以在非技术层面采取措施。
- 运营层面安抚用户：运营团队应该及时与用户沟通，提供故障发生的原因、当前的处理进展以及预计的恢复时间。透明的沟通有助于减少用户的焦虑和不满。
- 公关管理：公关团队应该迅速响应，准备恰当的公关声明，正确引导公众舆论，维护公司的品牌形象。同时，公关团队还需要监控舆论动态，及时应对可能出现的负面消息。
最优化决策
另外在执行切量过程中并不是一蹴而就的，可能需要根据实际的情况做第二次判断，包括容量，延迟和失败率等等，这个过程非常复杂，容量判断不准确可能会引发更大的问题。这个我们会在后面AIOps部分中介绍。
演练和盲测
在完成单机房容灾能力的建设后，一定要确保这个能力的可靠。为了验证业务线是否真正具备这种能力，以及能力是否会随时间退化，我们需要这里可以采用盲测验收的方法也就是常说的混沌工程。这种方法通过模拟或实际制造故障来测试不同业务线的故障响应和止损效率。这个方式分为三种。
第一种是无损盲测，只在监控数据层面模拟故障，业务线可以根据这些模拟的监控故障来进行逃生。这种测试对业务服务本身没有实际影响，主要用来验证故障处理流程是否符合预期，以及验证相关的预案是否完整。
其次是提前通知有损盲测，在这种测试中，会在网络或者服务器基础设施层面实际植入故障，这会对业务服务造成一定损害。目的是在接近实战的条件下，验证产品线各个组件的逻辑隔离性和故障应急处理能力。在进行这种测试之前，会提前告知业务线测试时间和可能的影响，方便相关人员准备相应的止损措施，减少因容灾能力建设不完善而造成的潜在损失。
最后是无通知有损盲测，在业务线的单机房容灾能力建设完成后，会进行不提前通知的有损盲测。这种测试对业务线来说，与真实发生故障的情况完全相同，用来真正地检验业务线在单机房故障情况下的止损和恢复能力。
小结
为有效应对单机房故障，我们需要先从架构层面着手，构建一个具备多活特性的系统。在构建多活架构的过程中，需要重点解决以下三个关键问题：单点故障消除、混联消除和服务解耦。
此外，在能力层面，应确保能够快速进行判断、决策和处理。整合多个监控平台的数据，提高故障判断的准确性，避免因误报导致的不必要的应急响应。
在决策阶段，重点在于进行全面的风险评估和容量评估，选择最合适的应对策略。在处理阶段，根据实际情况灵活选择流量切换、系统扩容或服务降级等一个或多个措施，实现快速有效的故障响应。
思考题
如果你们老板觉得目前双活建设的重要程度不高，但是你觉得非常重要，你有什么办法来解决这个问题吗？ 欢迎你把你的答案分享到评论区，也欢迎你把这节课的内容分享给其他朋友，我们下节课再见！
- includestdio.h 👍（0） 💬（2）
我觉得用故障概率和故障损失预估，核算故障可能会导致的直接成本，并与双活需要的成本进行比较，如果双活成本小于故障损失，应该还是比较有说服力的
2024-08-27