_{🧠 图解记忆：违约复盘从影响和时间线出发，跨数据、模型、工具与流程找根因，再验证纠正措施；点击图片可查看原图。}

💡 答案要点

SLA 违约场景分类：

展开 Python 代码示例（31 行）

# SLA 违约类型与响应级别
SLA_BREACH_TYPES = {
    "availability": {
        "sla": "99.9% 月可用率",
        "breach": "< 99.9%",
        "impact": "用户无法访问",
        "response_time": "15 分钟",
        "severity": "P1"
    },
    "latency_p99": {
        "sla": "P99 < 2s",
        "breach": ">= 2s",
        "impact": "用户体验下降",
        "response_time": "30 分钟",
        "severity": "P2"
    },
    "task_completion": {
        "sla": "任务完成率 > 95%",
        "breach": "< 95%",
        "impact": "业务指标下降",
        "response_time": "1 小时",
        "severity": "P2"
    },
    "cost_overrun": {
        "sla": "日成本 < $200",
        "breach": ">= $200",
        "impact": "财务损失",
        "response_time": "2 小时",
        "severity": "P3"
    }
}

复盘模板（五步法）：

展开 Markdown 代码示例（30 行）

## SLA 违约复盘报告

### 1. 事件概述
- **时间**: 2026-05-14 14:30 - 15:15
- **持续**: 45 分钟
- **影响**: 3,420 用户受影响，任务完成率从 97% 降至 72%
- **SLA 类型**: P99 延迟超标（P99 = 4.8s > SLA 2s）
- **严重程度**: P1

### 2. 时间线（Timeline）
| 时间 | 事件 |
|------|------|
| 14:30 | 监控系统触发 P99 > 2s 告警 |
| 14:32 | SRE 收到 PagerDuty 告警 |
| 14:35 | 开始排查，发现向量检索延迟异常 |
| 14:42 | 确认 Milvus 服务 CPU 100% |
| 14:50 | 尝试扩容，Pod 无法调度（资源不足） |
| 15:00 | 触发降级预案，切换到本地缓存检索 |
| 15:10 | 服务恢复，P99 恢复到 1.5s |
| 15:15 | 解除告警，通知业务方 |

### 3. 根因分析（Root Cause）
**直接原因**: Milvus 索引碎片化导致查询性能下降

**根本原因**:
1. HNSW 索引没有设置 `maxSegments`，导致段数过多
2. 监控缺失：没有设置 segment count 告警
3. 扩容策略不当：HPA 设置的 maxReplicas 太小

**技术细节**:
```sql

-- 问题：segment 数量从 5 增长到 156 SELECT segment_name, num_segments, memory_usage FROM milvus.segments WHERE collection = "user_knowledge" ORDER BY num_segments DESC;

-- 原因：连续写入 48 小时没有触发合并

### 4. 修复措施（Fixes）
| 措施 | 负责 | 状态 | 完成时间 |
|------|------|------|----------|
| 设置 `maxSegments=20` | @SRE-张工 | ✅ 已完成 | 2026-05-14 |
| 添加 segment count 监控 | @SRE-李工 | ✅ 已完成 | 2026-05-15 |
| 扩大 HPA maxReplicas 5→20 | @K8s-王工 | ✅ 已完成 | 2026-05-14 |
| 制定定时 segment 合并 cron | @SRE-张工 | 🔄 进行中 | 2026-05-16 |

### 5. 预防措施（Prevention）

┌─────────────────────────────────────────────────────────────┐ │ 预防措施清单 │ ├─────────────────────────────────────────────────────────────┤ │ ✅ 已添加：segment 数量监控（> 30 触发告警） │ │ ✅ 已添加：HNSW merge 操作 cron（每日凌晨 3 点） │ │ ✅ 已添加：HPA maxReplicas 扩容到 20 │ │ 🔄 进行中：降级预案自动化（超时自动切换缓存） │ │ ⏳ 待完成：故障演练（每月一次） │ └─────────────────────────────────────────────────────────────┘

### 6. 影响评估
- **用户影响**: 3,420 用户 × 平均 5 分钟延迟 = 17,100 分钟
- **业务损失**: 约 120 次任务失败，估计影响收入 $2,400
- **已补偿**: 向受影响用户提供 VIP 会员 3 天

### 7. 责任人签收
- SRE Lead: _______________ 日期: _______________
- Engineering Manager: _______________ 日期: _______________

### 8. 下次审查时间
2026-05-21（1周后复查预防措施执行情况）

复盘会议话术：

复盘话术模板 = """
1. 首先承认问题（不要甩锅）
   "这次 SLA 违约是我们的责任，我代表团队道歉。"
   
2. 明确影响范围（不要轻描淡写）
   "45 分钟内影响了 3,420 用户，有 120 个任务失败。"
   
3. 说明直接原因（技术细节要清晰）
   "Milvus HNSW 索引的 segment 数从 5 增长到 156，
   导致查询性能严重下降。"
   
4. 解释根本原因（不要只说表层原因）
   "根本原因是监控缺失——我们没有监控 segment 数量，
   也没有设置阈值告警，导致问题累积了 48 小时才爆发。"
   
5. 说明已采取的措施（展示行动）
   "我们已经：① 设置了 segment 数量上限；
   ② 添加了定时合并 cron；③ 扩容了 HPA maxReplicas。"
   
6. 承诺预防（展示闭环）
   "我们承诺：1 周内完成故障演练，
   确保同样的问题不会再发生。"
"""

面试话术：

"复盘应包含影响、时间线、检测与响应、促成因素、止血、根因假设的证据以及带负责人和期限的行动项。时限由组织事件流程决定；重点是无责学习和验证改进是否有效，而不是为了凑一个唯一根因或承诺问题永不再现。"