resilience-and-recovery

韧性与恢复

设计、演练并验证系统及其依赖项的韧性与恢复行为。此技能将故障模式、依赖项行为、降级选择、恢复测试、灾难恢复、演练日、故障转移、数据完整性和恢复沟通整合为一套方法，产出有演练依据的韧性计划，而不只是设计文档。

适用场景

触发条件	涵盖内容
“为此系统设计韧性计划”	故障模式映射、依赖项分析、降级选择、RTO/RPO 决策记录、恢复计划模板
“开展演练日或恢复测试”	演练设计、场景定义、证据记录、后续工作台账
"评估我们的灾难恢复准备情况"	根据演练证据审查灾难恢复计划、差距分析、数据完整性验证
“如果此依赖项发生故障会怎样？”	依赖项丢失场景、降级路径、断路器与回退策略
“定义我们的 RTO 和 RPO”	根据具体情境制定决策记录并分析权衡，而非给出普遍适用的规定
“验证恢复后的数据完整性”	恢复后验证流程、校验和与一致性检查、核对协议
“规划一次故障转移演练”	故障转移演练设计、前置条件、成功标准、回滚/故障切回计划、证据记录

不适用场景

• 线上事件指挥或事件响应：转至 site-reliability-engineering，了解事件指挥系统、值班运维和实时事件管理。此技能负责事件发生前的韧性设计与演练证据方法；SRE 负责线上响应。
• 基础设施实现细节：转至 platform-engineering，了解基础设施即代码、CI/CD 流水线实现、容器编排和服务网络。此技能负责韧性要求与演练证据；平台工程负责具体实现。
• 发布部署与回滚机制：转至 release-engineering，了解渐进式交付、金丝雀部署、功能标记和回滚运行手册。此技能通过演练负责验证这些机制的韧性。
• 备份实现与流水线运维：转至 data-engineering，了解备份策略实现、WAL 归档和快照管理。此技能负责恢复测试证据和数据完整性验证协议。
• 安全事件遏制与取证：转至 secure-software-engineering，了解安全事件响应和威胁遏制。此技能负责安全事件中的韧性方面，确保发生安全事件后仍具备恢复能力。
• 事件后的学习与验证：转至 incident-learning，将事件调查结果转化为有验证依据的后续工作，并提供关闭证据。此技能将演练和灾难恢复测试的调查结果提交至 incident-learning 流程。

加载指南

文件	加载时机
references/failure-modes-and-dependencies.md	梳理故障模式、分析依赖丢失或设计降级路径时
references/recovery-plan-template.md	使用结构化字段制定或审查弹性／恢复计划时
references/exercise-design-and-evidence.md	设计演练日、恢复测试、故障切换演练或记录演练证据时
references/rto-rpo-decision-record.md	根据具体情境的权衡因素定义 RTO/RPO 并使用决策记录模板时
references/data-integrity-verification.md	在恢复或故障切换后验证数据的正确性和一致性时
references/recovery-communication.md	规划恢复事件期间通知对象和通知时间时
references/follow-up-work-ledger.md	将演练发现转化为有负责人跟进的实施、测试和运维工作时
references/discovery-brief.md	了解与相邻技能之间的职责边界时

核心原则

韧性要通过演练来验证，而非靠设计证明。 从未经过测试的恢复计划只是期望，并非能力。每项韧性声明都必须有演练证据支撑：故障演练日、恢复测试、故障切换演练或混沌实验。仅有设计文档并不足够。恢复计划需要演练证据，而不只是设计声明。证据标准是演练结果，而不只是设计文档。

高可用性不等于可恢复性。 HA（冗余、故障切换、集群）可在组件故障时让系统继续运行。恢复（备份、还原、灾难恢复）则是在系统故障后重建系统。HA 不能替代恢复：冗余系统仍可能遭遇数据损坏、逻辑错误或跨副本传播的级联故障。一个可用性达到 99.99% 却没有经过测试的还原能力的系统，并不具备韧性——它只是可用，却无法恢复。HA 和恢复两者都不可或缺，互不替代。

RTO 和 RPO 取决于具体情境，并非放之四海而皆准。 恢复时间目标和恢复点目标取决于系统的作用、数据分类、用户影响、监管要求和成本。不存在通用的“RTO 应小于 1 小时”。支付系统、内部 Wiki 和批量分析流水线的 RTO/RPO 特征截然不同。应通过决策记录为每个系统定义 RTO/RPO，明确权衡，而不是照搬模板值。结构化模板请参阅 RTO/RPO 决策记录参考。

依赖关系决定故障影响范围。 每个上游和下游依赖项都是一种故障模式。若韧性计划未考虑依赖项在故障时的行为，就不完整。梳理每个依赖项不可用、性能下降或响应缓慢时会发生什么，以及在每种情况下系统向自身使用者作出什么承诺。

优雅降级，而非彻底失效。 当依赖项或内部组件发生故障时，系统应继续以精简但可接受的模式运行，而不是彻底失效。明确可接受的降级路径：哪些功能会停用、哪些功能会保留，以及用户体验会如何变化。并非每次故障都需要全面停机。

演练中暴露的问题是宝贵发现。 当演练暴露出缺口——例如还原耗时过长、故障切换导致数据丢失，或依赖项丢失引发意外的级联故障——这些发现就是资产。将每项演练发现转化为后续工作，明确指定负责人、目标日期和验证方法。若演练未发现任何缺口，则说明演练不够彻底，或系统尚未经过测试。

恢复沟通也是恢复工作的一部分。 恢复期间，利益相关者需要了解：发生了什么、受到哪些影响、正在采取什么措施、预计何时解决，以及应联系谁。提前准备沟通模板、通知渠道和升级路径。恢复期间的沟通失误会加剧技术故障。

韧性模式

模式 A：优雅降级

当某个组件或依赖发生故障时，系统以能力有所缩减但仍可接受的模式继续运行。这并非全面中断，而是有意舍弃非关键能力，同时保留核心功能。

降级决策标准：

• 故障组件是否为系统核心功能所必需？如果是，降级可能无法接受——系统可能需要采取默认拒绝或故障安全策略。
• 剩余能力能否在预期恢复时间内为用户提供可接受的服务？如果用户无法完成主要任务，降级就没有发挥作用。
• 继续以降级模式运行的影响范围有多大？降级运行是否会带来数据损坏、安全暴露或级联故障风险？

示例：

• 电商结账系统的推荐引擎发生故障，但仍可接受订单。舍弃推荐功能，保留下单功能。
• 仪表板的实时指标数据流发生故障，但仍显示上次刷新的缓存数据，并标注“数据可能已过时”。舍弃实时性，保留可观测性。
• API 网关的下游微服务发生故障，于是返回缓存响应或平稳降级的备用负载，而非 500 错误。舍弃新鲜度，保留可用性。

按级别舍弃功能：

• 第 1 级（保留）： 核心功能——系统存在的根本理由。必须保持可用。
• 第 2 级（必要时舍弃）： 增强功能——改善使用体验，但并非必不可少。优先舍弃。
• 第 3 级（尽早舍弃）： 可有可无的功能——非关键的点缀。压力下立即舍弃。

模式 B：基于恢复的恢复

当故障无法通过冗余或降级缓解时，从备份、快照或副本恢复系统。此模式适用于灾难恢复、数据损坏恢复和全系统重建。

恢复决策标准：

• 故障类型是否超出高可用（HA）的应对能力（数据损坏、逻辑错误、区域丢失、勒索软件）？
• 经验证的 RTO 是多少——恢复需要多长时间，是否经过测试？
• 经验证的 RPO 是多少——会丢失多少数据，备份是否经过验证？
• 是否已端到端演练恢复流程，包括数据完整性验证？

示例：

• 主数据库所在区域丢失。系统故障切换至灾难恢复（DR）区域，并从最近一次经过验证的跨区域备份中恢复。根据决策记录评估 RTO 和 RPO。
• 逻辑数据损坏（错误部署、程序错误）传播到所有副本。高可用无法提供帮助——每个副本都已损坏。系统从损坏事件发生前的时间点备份中恢复，并在恢复后验证数据完整性。
• 勒索软件事件加密了主数据存储和副本数据存储。系统从物理隔离的不可变备份中恢复。恢复测试已确认能在决策记录中定义的 RTO 内完成恢复。

恢复测试要求：

• 必须进行完整的端到端恢复演练，不能只验证备份。
• 恢复后必须验证数据完整性：校验和、行数和应用层一致性检查。
• 必须根据 RTO 决策记录衡量恢复情况。纸面上满足 RTO、实际操作中却未达到的恢复流程，仍存在差距。
• 必须记录恢复流程、对其进行版本管理并明确负责人。负责人须对演练结果负责。

韧性计划模板字段

每项韧性计划都必须包含以下结构化字段：

字段	说明	必需证据
系统边界	本计划的范围内和范围外内容	架构图或边界文档
故障模式	系统可能发生故障的方式：组件、依赖项、区域、数据、操作员错误	故障模式分析，包括发生可能性和影响
依赖关系图	本系统依赖的上游系统；依赖本系统的下游系统	具名系统、各依赖项的故障行为、使用方契约
降级选项	每种故障场景下要舍弃和保留的内容	层级分配及其依据、用户影响评估
RTO/RPO 决策记录	针对每个系统和场景制定的具体恢复目标	包含权衡因素的决策记录模板，而非硬编码数值
数据完整性	恢复后如何验证数据的正确性和一致性	恢复后验证流程、校验和、对账协议
恢复流程	包含前置条件和成功标准的分步恢复流程	带版本的流程、负责人分配、最近演练日期
沟通计划	每种恢复场景期间要通知哪些人、何时通知以及通过哪些渠道通知	通知模板、利益相关方名单、升级联系人
演练计划	每种恢复场景最近一次演练的时间以及下次演练的时间	演练证据：日期、场景、结果、发现的问题
后续工作台账	将演练发现的问题转化为明确负责的实施、测试或运维工作	每项发现的问题对应的负责人、目标日期、验证方法、状态

路由和相关技能

此技能整合并路由至以下能力：

• site-reliability-engineering — 事件指挥、值班运维、SLO/SLI 框架、错误预算。Resilience-and-recovery 负责事件发生前的设计和演练证据；SRE 负责实时事件响应。
• platform-engineering — 基础设施实施、CI/CD、容器编排、服务网络。Resilience-and-recovery 负责韧性要求；platform engineering 负责满足这些要求的实施工作。
• data-engineering — 备份策略实施、WAL 归档、快照管理。Resilience-and-recovery 负责恢复测试证据和数据完整性验证协议。
• secure-software-engineering — 安全要求、威胁建模、安全设计。Resilience-and-recovery 负责安全事件中的韧性维度，确保在安全事件发生后仍具备恢复能力。
• release-engineering — 渐进式交付、金丝雀部署、回滚运行手册。Resilience-and-recovery 通过演练验证这些机制，并将证据纳入发布就绪评估。
• incident-learning（wave 5）— 将事件和演练中的发现转化为有验证证据的后续工作。Resilience-and-recovery 将演练和 DR 测试中的发现输入 incident-learning 流程，以进行跨事件模式分析。

此技能作为组成能力，为 production-excellence 组合（wave 6）提供支持：韧性证据——演练结果、RTO/RPO 决策记录、后续工作台账——将纳入 production-excellence 证据包，用于支持 go/no-go/defer/exception 就绪决策。