第 4 章 稳定性核心指标与 SLA 设计
核心观点：SLA 不是数学题，而是基于成本、体验、技术的三方权衡。面试官期望你理解指标背后业务含义，而非死记硬背公式。
回答框架图：SLA 设计决策路径
加分项：在回答中主动提到“SLA 是服务等级协议，SLO 是目标，SLI 是指标”，区分三者的面试者通常能拿到更高评价。
面试问答卡片
Q1：如何定义搜索引擎的可用性？99.9% 和 99.999% 的差异是什么？
面试官考察点：是否理解可用性定义边界（如是否包含计划内维护）、对高可用架构成本的理解。
回答框架：定义 → 区分可用性窗口 → 计算差异 → 成本与风险权衡
简短示例回答：可用性 = 实际服务时间 / 总时间 × 100%。99.9% 允许年停机约 8.76 小时，适合非实时列表页；99.999% 仅 5.26 分钟，需多活架构和自动故障转移，成本高 3-5 倍。面试时要强调“对用户感知的影响比数字更重要”。
可能追问：“如果业务要求 99.999% 但预算只有 50 万，你怎么办？”
避坑提醒：不要只背公式。面试官更在意你是否考虑过维护窗口、故障切换时间是否计入可用性计算。
Q2：SLA 计算公式是什么？请给出搜索引擎延迟 SLA 设计的例子。
面试官考察点：是否了解 SLO 与 SLI 的关系，能否将延迟转化为可监控的指标。
回答框架：选择指标（P50/P99）→ 定义良好事件 → 计算达标率 → 设定窗口期和统计方式
简短示例回答：延迟 SLA = 请求中 P99 延迟 ≤ 200ms 的请求占比。例如“一个月内 95% 的查询，P99 延迟 ≤200ms”，指标使用 Prometheus 的 histogram 分桶统计。注意要排除健康检查流量，否则数据会被稀释。
可能追问：“如何定义‘不良事件’？多个指标如何组合成一个 SLA？”
可迁移话术：“我通常先区分‘错误’和‘慢’两个维度——错误率 SLA 和延迟 SLA 是独立的，可以设置两个 SLO。”
Q3：线上监控发现错误率 SLA 违规，如何处理与内部沟通？
面试官考察点：故障响应流程、指标分析能力、与业务方协商技巧。
回答框架：确认告警真伪 → 划分严重等级 → 定位根因 → 修复或降级 → 事后复盘与 SLO 补偿
简短示例回答：第一时间确认是否为真实流量触发（排除压测或爬虫），若确认有效则记录违规时长，启动应急流程。同时通知业务方当前影响范围，给出预计恢复时间。事后根据复盘结果调整告警阈值或增加冗余。
可能追问：“如果违规原因是某个上游依赖超时，SLA 责任如何划分？”
避坑提醒：不要直接回答“立刻修代码”。面试官希望看到你有流程意识：先止血（降级/熔断），再救火（根因修复）。
项目案例模板
| 维度 | 内容 |
|---|---|
| 项目名称 | 搜索引擎缓存层 SLA 设计方案 |
| 业务背景 | 搜索结果延迟要求 P99 < 100ms，但后端索引库压力大，需引入 Redis 缓存层并定义服务承诺。 |
| 规模指标 | QPS 峰值 8 万，日均查询 30 亿，缓存命中率 92%，可用性目标 99.99%。 |
| 技术栈 | Prometheus（指标采集）、Grafana（仪表盘）、Elasticsearch（日志）、Redis Cluster（缓存层） |
| 核心难点 | 1. 缓存穿透导致后端雪崩；2. 如何定义缓存层 SLA 而不与搜索层耦合。 |
| 面试高频追问 | “缓存命中率下降时，你们是否自动降级？降级后的 SLA 怎么调整？” “若缓存节点故障，如何处理读写请求？” |
| 可迁移回答话术 | “我们在缓存层和搜索层分别定义 SLI：缓存命中时延迟 ≤5ms，未命中时延迟 ≤100ms。SLO 设定为 95% 的请求满足延迟 ≤5ms——反映缓存设计的有效性。” |
面试官加分记忆点：提到“SLA 的制定需要业务、技术、运维三方签字确认”的面试者，往往表现出跨团队协作意识。