系统故障后如何快速降低故障时长？
面试场景
面试官：”假设你的线上系统出了问题，怎么能在最短时间内恢复？”
这道题考察的是故障应急响应能力，也叫降低MTTR（Mean Time To Recovery，平均恢复时间）。
核心指标：MTTR
MTTR = 发现时间 + 定位时间 + 恢复时间
因此，降低故障时长的核心思路：快速发现 → 快速定位 → 快速恢复
策略一：监控告警体系
分层监控
| 层级 | 监控内容 | 工具示例 |
|---|---|---|
| 基础设施层 | CPU、内存、磁盘、网络 | Prometheus + Node Exporter |
| 中间件层 | MySQL、Redis、MQ指标 | Grafana Dashboard |
| 应用层 | QPS、RT、错误率、业务指标 | SkyWalking、CAT |
告警策略
- 分级告警：P0（电话）、P1（短信+钉钉）、P2（钉钉）
- 告警收敛：避免告警风暴，同类告警合并
- 告警关联：根因分析，避免盲目响应
关键指标告警阈值示例
# 错误率告警
- alert: HighErrorRate
expr: error_rate > 0.01 # 错误率超过1%
for: 1m
labels:
severity: P0
# 响应时间告警
- alert: HighLatency
expr: p99_latency > 500 # P99超过500ms
for: 2m
labels:
severity: P1
策略二：熔断降级
熔断（Circuit Breaker）
当下游服务不可用时，快速失败，避免请求堆积导致级联雪崩。
正常状态（Closed）
↓ 错误率达到阈值
熔断状态（Open）→ 直接返回fallback，不调用下游
↓ 熔断时间窗口结束
半开状态（Half-Open）→ 放部分请求试探
↓ 试探成功率达标
回到正常状态（Closed）
降级（Degradation）
主动关闭非核心功能，保障核心链路可用。
| 降级类型 | 示例 |
|---|---|
| 读降级 | 查询异常时返回缓存数据 |
| 写降级 | 消息入库失败时先写本地日志 |
| 功能降级 | 关闭评论、推荐等非核心功能 |
代码示例（Sentinel）
@SentinelResource(
value = "getOrder",
fallback = "getOrderFallback",
blockHandler = "getOrderBlockHandler"
)
public Order getOrder(Long orderId) {
return orderService.queryById(orderId);
}
// 熔断后的降级逻辑
public Order getOrderFallback(Long orderId, Throwable t) {
return orderCacheService.getFromCache(orderId);
}
策略三：快速回滚
代码回滚
发布后出现问题，第一时间回滚，而不是尝试修复。
# K8s环境回滚
kubectl rollout undo deployment/order-service
# 传统发布系统
# 保持上一个稳定版本的制品包，支持一键回滚
配置回滚
动态配置热更新导致的问题，需要配置版本管理。
// Nacos配置监听，记录配置变更历史
@NacosConfigListener(dataId = "order.properties")
public void onConfigChange(String newConfig) {
log.info("Config changed: {}", newConfig);
// 配置变更后的兜底校验
validateConfig(newConfig);
}
数据回滚
- 写操作前记录操作日志，支持逆向操作
- 数据库binlog回放
策略四：预案演练
核心思想
不要等故障发生时才慌乱，定期演练让团队熟悉应急流程。
演练内容
| 演练类型 | 内容 |
|---|---|
| 故障注入 | ChaosBlade注入延迟、异常 |
| 主备切换 | 数据库主从切换演练 |
| 容灾演练 | 多活机房流量切换 |
ChaosBlade故障注入示例
# 对order-service注入3秒延迟
blade create dubbo delay --time 3000 --service com.xxx.OrderService --method getOrder
故障响应最佳实践
故障分级
| 等级 | 定义 | 响应时间 | 恢复目标 |
|---|---|---|---|
| P0 | 核心功能不可用 | 5分钟内响应 | 30分钟内恢复 |
| P1 | 核心功能受损 | 10分钟内响应 | 1小时内恢复 |
| P2 | 非核心功能异常 | 30分钟内响应 | 4小时内恢复 |
应急响应流程
告警触发 → 确认问题 → 拉群协作 → 止血操作 → 根因分析 → 复盘改进
↓
优先止血，后续再分析根因！
面试答题要点
- 给出MTTR公式：发现时间+定位时间+恢复时间
- 分层阐述：监控告警（快速发现）→ 熔断降级（快速止血）→ 回滚预案（快速恢复）
- 强调止血优先：先恢复服务，再分析根因
- 举例说明：能讲出一个真实的故障处理案例更佳
总结
降低故障时长的核心策略：
| 阶段 | 策略 | 目标 |
|---|---|---|
| 快速发现 | 分层监控 + 分级告警 | 缩短发现时间 |
| 快速止血 | 熔断降级 | 控制影响范围 |
| 快速恢复 | 代码/配置/数据回滚 | 恢复业务 |
| 预防演练 | 故障注入、容灾演练 | 提前验证恢复能力 |