superior-reliability

卓越的可靠性

确保关键用户结果在预期故障下依然可靠，并能在异常故障后恢复。可靠性工作应以明确的服务目标、真实的故障域和运维责任归属为基础，而不是照单全收地添加重试、断路器或冗余。

定义可靠性约定

提出控制措施前，先明确：

• 关键用户旅程，以及支撑这些旅程的服务或组件边界；
• 可接受的可用性、正确性、延迟、新鲜度和持久性；
• 流量和工作负载特征、峰值情况以及依赖预算；
• 故障域、共享依赖、状态所有权和影响范围；
• 实际存在的 SLI/SLO、错误预算、RTO、RPO、保留期限或合同目标；
• 检测、响应、升级、恢复和决策的责任人；
• 来自事件、遥测、容量测试、架构和运行手册的证据。

不要为了满足模板要求而臆造数值目标。如果尚无已认可的目标，应明确提出暂定的风险问题，并在设计复杂控制措施前收集证据。

根据风险和目标选择工作

定义服务指标、目标、错误预算、故障模式、关键依赖或优先级时，请阅读 references/objectives-and-risk-model.md。

• 保护用户结果，而不仅仅是进程正常运行时间。
• 对指标进行适当细分，以揭示关键用户旅程和受影响严重的用户群体，同时避免遥测难以维护。
• 根据后果、可能性、可检测性和恢复难度，为故障模式排定优先级。
• 仅在目标足以证明成本合理时，才缩小影响范围并消除单点故障。
• 根据实际产品约定处理计划内维护、依赖故障、数据正确性和延迟处理。

设计有界弹性

有关超时、重试、退避、抖动、幂等性、断路器行为、隔离舱、负载削减、队列、回退、冗余和优雅降级，请阅读 references/resilience-and-graceful-degradation.md。

• 设置端到端截止时间，并在各调用之间分配预算；层层叠加的默认值可能超出用户的容忍范围。
• 仅对可安全重复的瞬时操作进行重试，并设置上限及足够的抖动，以避免同步恢复风暴。
• 过载时保持背压和公平性。
• 降级可选功能时，不要将过期、不完整或不安全的结果呈现为完整成功。
• 确保弹性状态可观测，且恢复行为可测试。

如果实例共享配置、凭据、区域、数据存储、配额或部署路径，额外冗余可能会重现同一故障。应验证实例之间是否真正独立，而不只是统计副本数量。

确保恢复可运维

有关告警、运行手册、事件响应、备份、恢复、故障切换、灾难恢复、演练和事件后跟进，请阅读 references/recovery-observability-and-operations.md。

• 针对与用户影响相关或安全余量耗尽的可操作症状发出告警。
• 保留诊断上下文，但不得泄露密钥或敏感负载。
• 通过恢复和完整性检查验证备份，而不能只看作业是否成功。
• 运行手册应说明前置条件、停止条件、责任归属、验证步骤和升级路径。
• 将事件中总结的经验转化为有负责人跟进的整改工作；不要把复盘当作整改。

未经明确授权、未限定影响范围、未设置监控且没有中止路径时，绝不要触发混沌实验、故障切换、恢复、流量削减、生产负载或共享系统故障注入。

验证故障行为

使用能保留故障机制的最小安全环境。验证以下内容：

• 正常行为仍然正确；
• 超时、重试、取消和回退预算按预期组合；
• 依赖项故障不会超出设计边界而级联；
• 过载仍受控，重要工作能获得预期优先级；
• 恢复过程能收敛，且不会产生重复或损坏的影响；
• 告警会针对正确的症状触发，并在恢复完成后解除；
• 在已测试的范围内，运行手册和恢复流程能产生所声称的结果。

报告所用目标、测试的故障模式、环境与影响范围、观察到的降级和恢复情况、未测试的控制措施以及剩余风险。仅凭配置审查，不要宣称系统具备高可用性或灾难恢复能力。

有针对性地组合技能

• 使用 superior-debugging 诊断具体事件或未知故障原因。
• 使用 superior-performance 优化需要大量测量的延迟、吞吐量、饱和度或容量问题。
• 使用 superior-delivery 处理流水线、发布、部署验证和回滚执行。
• 当故障、恢复、并发或韧性测试设计是主要关注点时，使用 superior-testing。
• 使用 superior-database 处理数据存储一致性、复制、迁移、备份机制或数据恢复。
• 当韧性变更会影响领域状态、工作流或副作用契约时，使用 superior-logic。
• 使用 superior-docs 编写持久有效的 SLO、运行手册、恢复、架构或事件相关流程。

未经明确的范围和证据支持，不要将普通实现工作扩大为多区域架构、混沌工程或可观测性平台迁移。