⭐ 题目日期：

小红书 - 2024/11/11

📝 题解：

当整条链路宕机时，恢复的核心原则是优先保障核心业务的最小可用性，同时快速定位根因。以下是分阶段的恢复优先级和操作步骤：

---

一、第一阶段：快速止血（1-5分钟）

目标

• 恢复用户可见的核心功能（如登录、下单、支付等），而非追求系统全量恢复。

关键操作

1. 确认故障范围
   • 检查监控大盘：确认是单点故障还是全链路崩溃（例如网络中断、数据库主从全挂、中间件集群瘫痪）。
   • 区分基础设施层（如云服务商故障）和应用层问题。
2. 启动容灾预案
   • 流量切换：将流量切至备用机房、冷备集群或云厂商的跨区域冗余服务。
   • 降级策略：关闭非核心功能（如数据分析、推送通知），集中资源保障核心链路。
   • 回滚操作：若故障由近期发布引起，立即回滚至上一稳定版本。
3. 恢复基础依赖
   • 网络层：优先修复负载均衡、DNS、CDN 等入口服务。
   • 认证服务：确保用户登录、鉴权系统可用（如 OAuth、JWT 签发）。
   • 核心存储：重启数据库主节点或切换至从库（若主库不可用）。

---

二、第二阶段：系统性恢复（5-30分钟）

目标

• 逐步恢复非核心功能，修复数据一致性。

关键操作

1. 并行排查根因
   • 通过日志、Metrics、Tracing 定位故障点（如死锁、线程池耗尽、缓存雪崩）。
   • 检查近期变更：代码发布、配置推送、数据迁移等操作记录。
2. 按依赖层级恢复
   • 中间件：重启消息队列（如 Kafka、RocketMQ）、缓存集群（如 Redis）。
   • 辅助服务：恢复日志收集、监控告警系统（如 ELK、Prometheus）。
   • 异步任务：重启定时任务调度器（如 Airflow、XXL-JOB）。
3. 数据修复与补偿
   • 事务补偿：针对宕机期间的失败操作（如支付未到账），通过对账系统修复。
   • 缓存预热：提前加载高频数据到缓存，避免冷启动穿透数据库。

---

三、第三阶段：复盘与加固（故障后24小时内）

目标

• 防止同类故障再次发生。

关键操作

1. 根因分析（RCA）
   • 输出故障报告，明确技术责任（如代码缺陷、架构设计漏洞、运维操作失误）。
2. 架构优化
   • 冗余设计：多可用区部署、数据库多活、无状态服务化。
   • 限流熔断：引入 Sentinel 或 Hystrix 防止级联故障。
   • 混沌工程：定期模拟故障（如 Netflix Chaos Monkey），验证容灾能力。
3. 流程改进
   • 发布审核：加强灰度发布、A/B 测试流程。
   • 监控覆盖：增加业务级 SLA 监控（如订单创建成功率）。

---

恢复优先级总结（从高到低）

优先级	恢复内容	示例操作
1	流量入口和核心业务逻辑	切换负载均衡、重启核心服务
2	基础存储（数据库/缓存）	主从切换、缓存重建
3	中间件和异步任务	重启消息队列、补偿积压任务
4	辅助功能和非关键服务	数据分析、日志系统
5	全量数据一致性修复	对账、事务补偿

---

场景案例

案例：电商大促期间全链路宕机

1. 止血阶段
   • 立即切流量至备用集群，关闭秒杀、优惠券等非必需功能，仅保留购物车和下单。
2. 恢复阶段
   • 优先重启订单服务和支付网关，数据库主从切换后补偿丢失订单。
3. 复盘阶段
   • 根因是 Redis 集群连接池耗尽，后续引入动态扩缩容和连接池监控。

---

总结

• 先保命，再治病：优先恢复用户感知最强的核心功能，再解决长尾问题。
• 自动化优先：依赖预案（如自动切换、弹性伸缩）而非人工操作。
• 数据最后修：在确保服务可用后，再通过异步任务修复数据一致性。