CI/CD和移动应用程序的冗余故障转移

您很可能是在发布过程中遇到这个问题时。构建是绿色的，移动团队准备推送，一个边缘节点开始丢弃流量或一个后端路径变得足够奇怪以使回滚不安全。在这种情况下，'备用'并不是同样有一个系统可以继续为用户服务的系统。

这是一个 冗余切换 这其实是关于冗余的。冗余为您提供了备用路径、组件或状态副本。切换是决定和协调将工作转移到这些备用之一的过程，尤其是在发生故障时。

对于移动和CI/CD团队来说，这比大多数基础设施清单承认的要重要得多。一个实时更新平台不仅仅是一个发布工具，它是一个路由、签名、存储、边缘交付、设备检查和回滚行为的链条。如果链条中的任何一个环节无法清晰地进行故障转移，整个发布路径仍然可能会崩溃。

目录

• 什么时候备份不够
• 冗余和故障转移的定义
  • 一个厨房的类比
  • 每个团队应该问的四个问题
• 常见的架构模式和何时使用
  • 每种模式的优势
  • 每种模式的缺点
• 加权故障转移和渐进阈值
  • 为什么二进制思维导致抖动
  • 如何加权健康检查改变决策
• 将故障转移应用到CI/CD和实时更新交付
  • 将管道视为服务路径
  • 将回滚纳入交付中，而不是作为例外
• 边缘更新平台作为故障转移链
  • 为什么边缘应该在恢复路径中
  • 什么样的用户群频道可以为你带来好处
• 在需要它之前测试故障转移
  • 为什么边缘 myths survive
  • 在实践中应该进行的重演
• 团队实时更新交付的实用检查清单

When a Backup Is Not Enough

一个看似无害的发布引发了一个非常常见的事件。应用程序包通过阶段通过，部署系统正常工作，团队预计会有一个例行发布。然后一个区域边缘节点发生故障，一条路径开始返回坏的健康信号，发布必须暂停，而每个人都会问同一个问题，“我们能否在这种失败中存活下来，还是只是检测它？”

这就是拥有备份基础设施和真正 冗余故障转移 设计之间的差距。一个备用服务器坐在一个机架上并不能帮助，如果路由层从未指向用户，认证服务无法访问它，或者部署过程不知道何时切换。微软的架构指南使这个差距变得明显，它建议测试和验证冗余组件，同步前端和后端故障转移，并使用自动故障转移和手动故障恢复，因为简单的复制并不能保证恢复从头到尾工作。

一个没有被 anybody 练习过的备份只是希望加上一个预算线。

有用的模型有四个部分。 冗余 回答什么是复制或替代路径。 故障转移 回答系统如何移动到它。 恢复协调 回答了链条的其余部分如何恢复到正常状态的问题。 验证 回答了是否在真实条件下整个系统正常工作的问题，而不是仅仅在白板上工作。

移动团队在实时更新交付中清晰地看到这一点。如果一个服务在部分停机后无法签名、存储、路由和验证包，平台可能在一个狭窄的层面上看起来是冗余的，但仍然在生产环境中会让用户失望。通常，失败不是一个单独的故障箱，而是箱子之间的交接或假设有人会注意并切换。同样的逻辑也适用于事故响应，第一分钟比架构图更重要，正如__CAPGO_KEEP_0__的事故响应指南中所描述的那样。 来自Capgo的事故响应指南.

Networking2000的冗余建议 强调了相同的教训，仅仅是重复并不能帮助，除非系统的其余部分可以切换到它。 冗余和故障转移定义为一对

冗余和故障转移经常被认为是同一个东西。它们不是。

冗余 是指有多个可以完成相同工作的组件的存在。 __CAPGO_KEEP_0__ [Failover] [failover是指将责任从故障组件转移到健康组件的过程。]

[一个生动的厨房类比]

[想象一下一个繁忙的餐厅厨房。如果有多个厨师可以烹饪相同的菜单，那就是冗余。如果主厨看到一个人筋疲力尽并立即将下一个订单分配给另一个人，那就是failover。]

[厨房仍然需要更多的人。它需要一种方法来检测故障，一种规则来决定谁接管，以及一种方法来保持订单流动而不混淆前台。因此，冗余而没有failover只是闲置的容量，而failover而没有冗余只是恐慌。]

[区分的重要性在于，团队经常只购买或建立备用组件就停止了。他们会问自己是否有两个服务器，两个区域，或者两个数据副本，然后认为自己已经被覆盖了。在生产环境中，真正有用的问题是系统是否能够快速检测到问题，切换而不导致第二次故障，并且在原始路径恢复时切换回去。]

[每个团队都应该问的四个问题]

[一个实际的failover设计的生死在于四个评估标准。]

• [检测时间][系统知道什么是错误的速度。]
• [切换时间], how long does it take to move work to the backup path.
• Data consistency数据一致性
• Reversibility, can the system return to the preferred path without making things worse.

可逆性

Common Architecture Patterns and When to Use Them

The easiest way to reason about failover is to ask where the decision is made. Some teams let hardware absorb the problem. Others push the decision into software, a load balancer, or a global routing layer. Each choice handles a different kind of failure, and each one creates a different set of blind spots.

那些问题同样适用于数据库、负载均衡器和实时更新管道。区别在于交接点的位置。在移动发布系统中，交接点可能位于通道、边缘或版本之间，而不是应用服务器之间。逻辑相同，健康的备用系统必须存在，系统必须能够根据正确的原因选择它。

常见的架构模式和何时使用它们 works well when the failure is local and obvious, like a device, card, or node going down. It’s simple to understand, which is why it shows up early in platform maturity. The downside is that hardware alone doesn’t solve orchestration. If the higher layers don’t know what happened, traffic may still point at the wrong place.

Software redundancy 将重点提升到更高的层次。相比仅仅复制盒子，你复制的是服务、进程或应用层中的容量。对于云原生系统来说，这通常是一个更好的选择，因为软件可以更聪明地做出健康、版本和状态的决策。

active-active 表示多条路径同时提供服务，单个故障不会导致冷启动。系统可以承受并发处理，数据模型可以保持一致性，这是一个强大的选择。 active-passive 表示一条路径提供服务，另一条路径等待。它更容易理解，通常适用于权威状态，但你需要为不可见的容量支付费用。

区域故障转移 帮助解决更大范围的故障影响。如果整个站点或区域出现问题，流量可以转移到其他区域。 DNS驱动的策略 通常用于让客户端感知到故障转移的发生，而 负载均衡驱动的策略 则将决策推向更靠近请求路径的位置。

每种模式都有哪些局限性

每个模式都会在某个地方出现问题。硬件冗余可以掩盖上游依赖项仍然共享的事实。主动-主动模式如果状态模型没有为并发性构建，就会变得混乱。主动-被动模式可能会长时间处于空闲状态，导致人们对被动侧是否仍然有效的信心丧失。区域故障转移可以被跨同一故障域的共享服务所击败。DNS驱动的控制可以慢于反映变化，而负载均衡驱动的控制只有当平衡器本身是健康的时才有帮助。

对于移动更新平台来说，这意味着故障转移层可能同时位于多个层次上。构建服务器可能是冗余的，工件存储可能是复制的，边缘交付可能是负载均衡的，但关键问题是哪一层决定应该移动发布。如果您希望更广泛的部署视图， Capgo 的多区域部署指南是一个实用的伴侣，因为它展示了区域思维如何改变发布可靠性的形状。

从拥有用户影响的层开始，然后向外工作。如果用户只在更新离开边缘后才感觉到更新，那么边缘就是故障转移故事的一部分。

正确的模式不是最复杂的，而是匹配您要生存的故障的模式。小团队通常从主动-被动模式开始，添加明确的验证路径，然后在证明下层可以信任时才添加更多的并发性。

权重故障转移和渐进阈值

A failover decision does not need to be a pure yes or no switch. Binary logic is one reason systems flap, because the service keeps bouncing between healthy and unhealthy states as soon as a single signal crosses a line. Weighted failover handles the same situation with more context, by treating failures as signals with different levels of impact.

为什么二元思维会导致系统的波动

Juniper的 chassis-cluster 模型提供了一个具体的例子。每个冗余组都从一个阈值开始 255,然后减去每个监控对象的分配权重，当该对象失败时。只有当阈值达到零时，才会发生故障转移，这让运营商决定单个接口或组件损失的重要性Juniper chassis-cluster冗余组故障转移).

这种设置比硬切换更符合生产现实。一个受损的连接可能会令人恼火但仍然可用。一次监控的多个部分同时失败可能会讲一个不同的故事，因为组合的影响可能足够大，以至于可以证明切换的必要性。这种情况很重要，因为部分降级是常见的，而立即切换可能会中断比原始故障更多的流量

如何加权健康检查改变决策

Weighted failover也会在外部网络设备中显示出来。断路器、加权流量池和分段出流量控制都遵循相同的理念，不要在第一条警告时惊慌，但也不要忽视重复的迹象。策略保持可调节，因为切换有成本。过早的故障转移可能会破坏会话，复杂化状态重新协调，并将一个事件转化为两个事件。

对于移动团队来说，相同的逻辑也适用于部署控制。实时更新路径可能仍然足够健康，以便为部分观众提供服务，而较小的切片已经受损。如果可观察性足够细致，系统可以继续从边缘提供服务，直到风险超过您定义的阈值。边缘是这个决策的一部分， 边缘网络模型从Capgo 帮助解释为什么最后一个跳转的重要性与中心管道一样。

一段短视频可以使心理模型更容易掌握。

Weighted failover改变了您如何框定问题的方式。您不再问一个组件是否存活或死亡，而是开始问路径中剩余的信心有多少。这是一个更真实的问题，在系统中，部分故障是正常的，而坚持不懈往往比强制进行匆忙的交换更好。

将故障转移应用到CI/CD和实时更新交付

发布管道是一种交付系统，但它也是一个恢复系统。一旦您这样看待它，设计选择就变得更加清晰。构建服务器、工件存储、签名服务和发布渠道都成为重复故障转移的地点。 故障转移和重复 必须明确。

将管道视为服务路径

如果一个构建运行器死亡，冗余性只有在另一个运行器可以接管工作时才有用。如果存储库不可用，管道需要另一个副本或另一个到包的路线。如果发布到达一个坏状态，系统必须停止发送更新，防止问题扩散。

这就是CI/CD和实时更新交付与普通发布脚本的区别。成熟的管道需要知道发布是否安全继续，安全暂停，还是安全逆转。管道中的 Capacitor OTA更新触发器指南 因为它位于思考的中间，构建过程变成一个用户可见的分发事件。

通常的发布链条需要三个保护机制。

• 构建冗余以便一个运行器或一个队列故障不阻塞发布。
• 存储冗余以便签名包不是单点故障。
• 通道保护栏所以，一个糟糕的发布可以在完全暴露之前被包含在内。

这些并不是分开的关注点。它们是同一个恢复故事，在路径的不同点上。

回滚应该成为交付的一部分，而不是例外

回滚是应用层面的恢复反弹。系统将用户从坏路径上移开，然后在问题被理解或修复时返回到稳定的路径。如果回滚仅存在于手动的火灾演练中，它通常会来得太晚。

可观察性使这一点成为可能。每个设备的日志、采用信号和故障事件告诉你更新路径是否足够健康以继续。没有这种反馈，团队就像在黑暗中飞行，任何故障转移决策都是猜测。

回滚路径应该像发布路径一样无聊。如果在事故期间它感觉新颖，那么它就没有设计得够好。

Capgo 在这个模型中作为一个选项，适用于实时更新CapacitorJS或Electron的团队，因为它支持签名的Web包、基于通道的分发、每个设备的日志和自动回滚保护。这些功能对于故障转移很重要，因为它们为平台提供了检测、隔离和反转一个糟糕的发布的方式，而不必等待商店审查周期。

重点不是一个工具解决了所有问题。重点是你的交付管道应该像一个可靠的系统一样运作，而不是一个单向广播。

边缘更新平台作为故障转移链

在世界上，更新路径会在仪表板说之前就出现问题。一个捆绑从构建到签名，然后进入存储，然后通过可能跨区域的边缘网络，最后到达可能离线、慢或只部分连接的设备。如果链条中的任何一步失败，更新就没有进行故障转移。它已经停止了。

为什么边缘网络应该在恢复路径中

延迟、一致性、签名捆绑和设备日志是传递的关键部分。无法验证的签名捆绑是一个死路，因为设备应该拒绝信任它。服务不同内容的边缘节点，根据请求的位置可以触发故障转移事件，即使应用程序本身是健康的，这会将传递问题转化为可靠性问题。

边缘网络遵循经典基础设施的逻辑。分布式边缘网络成为传递的冗余层，故障转移目标是下一个健康的节点，可以回答请求。如果您曾经与路由表或数据库副本打过交道，这个模式会感到熟悉。移动分布会将故障隐藏在更新逻辑中，使得断裂的步骤更容易忽略。

为了更广泛的介绍关于传递层的内容 边缘网络在实践中做了什么 有助于解释为什么在移动更新系统中，故障的局部性如此重要。同样的想法也与 在网络边缘处理数据，当本地处理改变了性能和故障行为时。

什么样的频道会为你带来收益

基于观众的频道，例如beta、staging、生产环境或客户特定流，允许团队在整个舰队都依赖它之前测试恢复路径。这样做很重要，因为同一个包在不同设备组合、网络质量或发布时间下可能表现出不同的行为。

从那一刻开始，会有几个实际的后果。

• beta频道 帮助你在更广泛的暴露之前验证更新路径是否稳定。
• staging频道 让你在受控环境中确认回滚和重新获取行为是否正常工作。
• 生产频道 应该在早期路径显示链路完整后才接收发布。
• 客户特定频道 可以在一个观众需要不同的补丁节奏时隔离风险。

重要的教训是，边缘交付不是你的构建系统的被动镜像。它是一个主动的故障转移层。如果最接近的健康节点无法服务，系统必须选择下一个一个。如果包无法验证，平台必须回落到一个更安全的发布状态。

它是基础设施和移动交付之间的桥梁。故障转移目标并不总是另一个服务器，它也可以是下一个可信的边缘包。

测试故障转移之前

冗余的谎言存活下来是因为快乐路径看起来很可信。团队看到的重复基础设施，认为这是一个有韧性的系统，忽略了在实际故障时会崩溃的隐藏依赖。简单来说，冗余的部分需要被测试和验证，前端和后端的故障转移需要保持一致。

为什么冗余的谎言存活下来

谎言通常从共享依赖和弱物理分离开始。两个系统如果依赖于相同的隐藏路径、相同的签名服务或相同的工件存储，实际上并不是真正分离的。

这就是为什么仅仅检查备份是否存在的测试可以通过，而实际的故障转移路径仍然会失败的原因。

这对于移动交付和边缘系统来说尤其重要，因为链条跨越了多个层次。回滚看起来在仪表板上是健康的，但设备无法从备份边缘位置重新获取包。区域故障转移看起来成功，直到签名服务、工件存储或认证路径暴露了共享的故障域。同样的模式出现在 测试Capacitor OTA更新中，更新路径需要在设备上、通过边缘层和回到可信的发布源上工作。

在实践中应该练习什么

A useful failover test forces the actual recovery path, not a fake one. The team should rehearse the complete sequence under realistic conditions, then watch where the chain bends, stalls, or breaks. A broader edge perspective helps here, because 边缘网络处理数据 改变了“恢复”意味着什么，尤其是当本地条件成为故障故事的一部分时。

A practical checklist looks like this:

• 混乱演习,故意移除或降级一个组件，以查看系统是否可以清晰地转移。
• 跨区域的合成事务,确认请求可以在一个站点不可用时仍然完成。
• 计划区域故障转移,验证路由、认证、存储和更新传递都可以一起移动。
• 阶段性回滚,确保坏的实时更新可以在真实网络条件下停止并替换。
• 移动回滚验证, 确认已签名的捆绑包可以从备份边缘位置重新获取。

如果测试从未触及实际的fallback路径，它只证明监控仪表板工作。

最强大的团队将故障转移测试视为一种重复的运营习惯。他们不会等待审计来确定备份链是否有效。他们演练最重要的故障模式，然后不断提高交接手续，直到系统可以在没有手动混乱的情况下恢复。

团队实时更新的实用检查清单

实时更新可能会在数据库或负载均衡器失败的同一位置失败，只是移动设备上的爆炸半径看起来不同。一个坏包，一个破坏的边缘节点或一个陈旧的fallback通道可以让用户卡在旧版本上，而应用程序看起来健康。

如果您本周正在实时更新，请从发布路径开始。

• 绘制弱点，识别DNS、边缘和源层的单点故障，然后写下哪一个负责用户影响。
• 确认备用路径，确保每个关键组件都有一个健康的备份路径，而不是仅仅在纸上有一个副本。
• 使用通道护栏为了避免一个错误的发布导致整个fleet的事件，
• 需要签名的捆绑包因为无法验证的捆绑包不是一个有效的备份路径
• 监控每个设备的信号使用日志和采用数据作为检测机制，告诉你何时应该触发故障转移
• 模拟回滚不要等到真正的事件发生才能发现最后一个良好版本无法清洁地恢复
• 运行一个预定的混乱演习故意将一部分路径从服务中移除，观察链条是否真正转移
• 验证故障恢复因为返回到首选路径是系统的一部分，而不是一个额外的功能

那些能够追踪从源代码到设备的发布，并指出它可以失败的确切位置的团队，能够很好地恢复。他们不把冗余视为额外的副本。他们把它视为在压力下必须工作的决策链条、检查链条和传递链条，包括边缘更新层，位于发布管道和用户设备之间。

如果发布出了问题，应事先准备好应对措施。应急清单应与你的故障排除手册放在一起，应连接到你的团队在生产环境出现问题时使用的应急指南。 应急指南 当备份不足时