可靠性与恢复

将降级模式、故障场景、恢复、灾难恢复和清理作为版本化证据进行规划。

Lenso 的可靠性得到声明、评估和记录。不是推断的 从绿色仪表板。

可靠性合约

自治服务选择可重用的开发、标准或关键 配置文件并可以添加经过验证的覆盖。有效合约规定了限制 用于队列、工作流、依赖项、就绪性、活跃性和降级模式。

该服务评估其自己的本地状态。Runtime Console显示报告， 但控制台的可用性并不决定准备情况或业务完成情况。

故障场景

故障场景是带有预期结果、观察结果的版本化输入， 证明、效果和清理结果。使用以下方法评估一个捕获的输入：

lenso ga failure-evaluate \
  --input ./evidence/api-crash.json \
  --json

一个有用的场景命名了正在测试的业务保证。 “Pod 已重新启动”是 基础设施活动； “已接受的票证工作将被保留并恢复一次” 是恢复的保证。

GA 基线涵盖 API 和 Worker 崩溃、网络分区、依赖性 丢失、控制平面中断和确定性恢复。每个场景都必须离开 cleanupComplete: true 并必须说明生产状态是否发生变化。

备份和恢复

备份属于 Service Store 所有者。证据应具有约束力：

• 服务和商店标识；
• 备份工件和校验和；
• 源模式和合约修订；
• 观察恢复点和恢复时间；
• 恢复命令或受控程序；
• 恢复后业务验证；
• 清理一次性恢复资源。

成功上传并不能证明备份。将其恢复为孤立的目标 并通过服务的公共行为验证业务不变性。

灾难恢复

单区域 GA 需要有界恢复Story，而不是隐含的多区域 主动-主动拓扑。灾难恢复证明应表明该服务 可以从审查的工件、配置参考中重建， 合约，以及 储存回收材料。

将这些问题分开：

• 服务身份保持稳定；
• 工作负载实例和地址可能会发生变化；
• 秘密仍然是参考，而不是嵌入的值；
• 恢复的服务在接受流量之前重新验证合约；
• 操作员记录决定和由此产生的证据。

Durable Workflow恢复

工作流定义按实例固定。重启后，Worker们回收 过期的租约并继续相同的过渡身份。尝试、计时器、 儿童、补偿状态和已完成的影响仍然持久。

如果部署的工作线程不再与固定定义匹配，则执行失败 以明确的下一步行动结束。重用版本字符串无法重新解释 现有状态。

控制平面中断

数据平面保持服务本地运行状况、工作流、Inbox、Outbox和Story 独立于系统平面和 Runtime Console的分段。停电期间：

1. 停止接受新的操作符突变；
2. 根据其可靠性保留服务本地业务执行 合约;
3. 捕捉当地证据和明确的差距；
4. 恢复控制面；
5. 幂等地重播集合而不重写服务历史记录。

这种分离就是系统平面不参与业务流量的原因。

对于围绕这些程序的信任和支持边界，请继续 支持和安全。