sli slo and sla understand sli slo and sla in kubernetes

Life shrinks or expands in proportion to one’s courage. - Anais Nin 收拾东西最好的方式，就是扔。东西是，人也是。

K8s 工程师的 “通天河渡劫”：用西游记讲透 SLI/SLO/SLA 的生存法则

作为一名摸爬滚打 5 年的 K8s 老兵，我曾在集群故障的 “妖风暴雨” 中熬夜排查到天亮 —— 直到某天凌晨 3 点，盯着 Prometheus 面板上 API Server 波动的延迟曲线时突然顿悟：这不就是《西游记》里唐僧师徒过通天河的翻版吗？

你看，业务团队要 “西天取经”（上线核心交易系统），K8s 集群就是那 “洋洋光浸月，浩浩影浮天” 的通天河，而 SLI/SLO/SLA 正是帮你避开 “灵感大王”（集群故障）、平安抵岸的 “渡河契约、可靠渡船和航行目标”。今天咱们就借着这段经典剧情，把这三个被技术文档讲得枯燥的概念，聊成一套能直接落地的 “K8s 稳维方法论”。

一、通天河畔的困境：没有 SLA 的合作都是 “口头画饼”

话说唐僧师徒行至通天河畔，望着八百里宽的河面犯了难。陈家庄老者凑上来说：“河中有灵感大王，每年要吃一对童男童女才肯放行，我们帮你们求情试试？”

孙悟空当即怼回去：“求情没用！要渡河可以，先说好‘船怎么开、出故障怎么救、耽误了行程怎么赔’—— 没规矩就是耍流氓！”

这场景简直是 K8s 运维的日常缩影：业务团队说 “我要上支付服务，集群必须稳”，运维团队拍胸脯 “没问题”，可 “稳” 到底是 “99% 可用” 还是 “99.99% 可用”？故障 10 分钟和 1 小时的责任怎么分？这正是SLA（服务水平协议） 的核心价值：它不是冷冰冰的文档，而是跨团队协作的 “法律契约”。

K8s 版 “渡河契约”（SLA）的黄金三要素

陈家庄若真想和师徒达成合作，SLA 绝不能只写 “保证安全渡河”，必须明确可执行的条款：

1. 触发条件：渡船漏水导致航行中断（对应 K8s 核心 Pod 就绪率＜99.9%）且 10 分钟内未恢复；

2. 响应机制：立即启用备用渡船（运维启动 Pod 故障转移 + 节点隔离流程）；

3. 补偿条款：因船工操作失误导致延误（如运维误配 NetworkPolicy），需免费提供 3 天食宿 + 重新规划最优航线（承担业务损失 + 输出配置优化方案）。

我们曾为电商大促制定过这样的 SLA 条款，至今仍在沿用：

若 Ingress 层 HTTP 5xx 错误率持续 5 分钟＞0.1%，运维团队需 15 分钟内定位根因并启动流量切流；若因负载均衡配置错误导致故障，需协助业务完成回滚，并在 24 小时内提交含自动化校验的配置改进方案。

没有 SLA 的协作，就像唐僧轻信灵感大王的 “口头承诺”，迟早要栽跟头。去年我们就吃过亏：业务 Pod 因节点资源预留不足频繁 OOM，业务团队指责运维 “资源给少了”，运维抱怨业务 “没提前申报需求”，吵了三天没结果。直到补签 SLA 明确 “业务需提前 7 天提交资源清单（含峰值预估），运维需保障资源预留率≥90%”，才彻底杜绝了推诿扯皮。

二、造一艘靠谱的船：SLI 是 “渡河的核心零部件”

孙悟空嫌陈家庄的渡船太小太脆，决定亲自造一艘 “抗风浪巨轮”。猪八戒凑过来偷懒：“大师兄，随便砍几棵树钉起来能漂就行！” 孙悟空一棒敲过去：“呆子！船板厚度、龙骨承重、风帆拉力，哪一样不需要量化标准？这些就是SLI（服务水平指标） —— 没有可衡量的零件，船开出去就是送死！”

K8s 集群的 “造船零件清单”（核心 SLI 选型）

造 K8s 这艘 “业务承载船”，绝不能像猪八戒那样 “拍脑袋选指标”。必须聚焦 “影响渡河安全” 的核心维度，就像造船要盯紧 “吃水深度” 而非 “船身彩绘”。我们整理了一套经过实战验证的 SLI 选型框架：

维度	西游记对应场景	K8s 核心 SLI 举例（含采集方式）	核心价值
核心组件	船的龙骨、舵机	API Server P95 响应延迟（kube-apiserver metrics）、etcd 读写成功率（etcd metrics）	组件故障直接导致集群 “停摆”，是生命线指标
业务载体	船舱的承重能力	Pod 就绪率（kube-state-metrics）、容器异常重启次数（cadvisor）	直接反映业务是否 “可用”，是用户最关注的指标
连接通道	船的锚链、缆绳	Ingress 路由成功率（nginx-ingress metrics）、Service 端到端连通性（blackbox-exporter）	网络中断会导致 “服务孤岛”，业务无法对外提供能力
补给系统	船的淡水储备、粮食库存	PV/PVC 挂载成功率（kube-state-metrics）、ConfigMap 同步延迟（自定义探针）	存储 / 配置异常会导致 Pod “启动失败”，业务无法部署

去年双 11 前的压测中，我们就因为漏了 “etcd 磁盘 IO 延迟” 这个 SLI 栽了大跟头：当时只盯着 “读写成功率 99.99%” 达标，没注意磁盘 IO 延迟已从 50ms 飙升至 300ms，结果大促高峰时 API Server 请求超时率突然涨到 15%—— 这就像造船时只检查了 “锚链强度”，却没发现 “锚链生锈卡壳”，关键时刻根本抓不住底。

避坑指南：别把 “边缘指标” 当成 SLI 核心

猪八戒造完船后，非要在船尾装个 “风速计”，说 “能测风向显得专业”。孙悟空骂道：“我们要的是‘船能不能安全到对岸’，不是‘风好不好看’！” 这正是很多 K8s 团队的通病：把 “node_cpu_usage”“pod_network_transmit_bytes” 这类 “边缘指标” 塞进核心 SLI，结果仪表盘上数据爆炸，真正的故障预警却被淹没。

筛选 SLI 的黄金标准只有一个：“业务影响度”。简单说就是：这个指标异常时，用户会不会直接感受到？会不会影响业务收入？比如 “Pod 就绪率” 掉了，用户直接打不开 APP；而 “节点 CPU 使用率 80%” 若没导致 Pod 被驱逐，就没必要放进核心 SLI 监控。

三、设定 “安全渡河” 的目标：SLO 不是 “越严越好”

船造好了，孙悟空召集团队开会定目标：“3 天内渡到对岸，中途船体漏水次数不超过 1 次。” 猪八戒拍胸脯喊：“要不再严点？1 天内到，滴水不漏！” 沙僧却冷静提醒：“大师兄，通天河常有暴风，目标太严会逼得船工冒险；太松又会耽误取经 —— 得留有余地。”

沙僧的话正中SLO（服务水平目标） 的精髓：它是 “基于 SLI 的合理期望”，不是 “拍脑袋的口号”。就像渡河不能追求 “绝对不漏水”，K8s 的 SLO 也绝非 “100% 可用”—— 那既不现实，还会导致资源浪费（比如为了 0.1% 的可用性多买 10 台服务器）。

实战派 SLO 制定方法论

定 SLO 就像规划 “渡河路线”，必须结合 “天气（业务需求）”“船况（集群能力）”“物资（资源成本）” 三方因素，我们总结了三个核心步骤：

1. 按业务优先级 “分层定标”

取经团队里，唐僧的安全是 “核心目标”，猪八戒的零食是 “非核心目标”。K8s 的 SLO 也必须分层，避免 “一刀切” 导致资源错配：

• 核心业务（如支付、订单）：SLI 选 “Pod 就绪率”“接口 P95 响应延迟”，SLO 定 “就绪率≥99.99%，延迟＜300ms”—— 就像 “唐僧不能掉水里”，容不得半点差池；

• 非核心业务（如日志采集、监控告警）：SLI 选 “Pod 运行率”“数据采集延迟”，SLO 定 “运行率≥99.9%，延迟＜5 分钟”—— 就像 “猪八戒的零食丢了能再买”，可接受短期波动。

去年我们给一个游戏客户定 SLO 时踩过坑：一开始没分层，给所有 Pod 都定了 “99.99% 就绪率”，结果为了保障日志 Pod 的可用性，客户额外加了 10 个节点，每月多花 30 万成本 —— 这就像为了保护零食给船加钢板，纯属浪费。

2. 用 “容错时间” 让 SLO 更接地气

很多人觉得 “99.99% 可用性” 很抽象，其实换算成 “每月容错时间” 就一目了然：

• 99.9% = 每月允许 43.2 分钟不可用（适合非核心业务）；

• 99.99% = 每月允许 4.32 分钟不可用（适合核心业务）；

• 99.999% = 每月允许 25.9 秒不可用（仅建议金融级核心业务采用）。

就像渡河 “3 天内到岸” 允许 “中途停靠 1 次休息”，K8s 的 SLO 也该留 “容错空间”。我们给 API Server 定的 SLO 是 “P99 延迟＜500ms”，同时约定 “每小时允许 1 次不超过 1s 的瞬时波动”—— 既保证了整体稳定性，又不会让运维团队因 “偶尔的指标毛刺” 过度紧张。

3. 拒绝 “行业基准绑架”，从实际数据出发

猪八戒听说 “东海龙王的船能‘1 天渡 1000 里’”，非要把咱们的渡河目标改成 “1 天渡 800 里”。孙悟空当场反驳：“东海风平浪静，通天河暗礁遍布，能比吗？”

很多 K8s 团队也会犯类似错误：照搬社区 “最佳实践”，看到 “etcd 官方建议读写成功率≥99.99%”，不管自己集群是 10 节点还是 1000 节点、是测试环境还是生产环境，硬把 SLO 定成这个数。结果小集群还好，大集群因数据量和并发太高，根本达不到目标，最后 SLO 变成了 “摆设”。

正确的做法是：先采集 1-2 周的 SLI 基线数据，再基于实际水平上浮 10%-20% 作为 SLO。比如某集群 etcd 读写成功率基线是 99.95%，就把 SLO 定在 99.96%-99.97%，既留了优化空间，又不会脱离实际。

四、渡河后的复盘：SLI/SLO/SLA 是 “动态迭代的活文档”

师徒四人终于渡到通天河对岸，孙悟空没有急着赶路，而是召集大家围坐复盘：“今天航行中龙骨有点晃（对应 etcd 延迟偏高），下次要加粗材质；船工发现漏水后反应慢了 2 分钟（对应故障响应超时），回去得加强应急培训。”

这正是 K8s 稳维的核心：SLI/SLO/SLA 不是写好就归档的文档，而是需要持续迭代的 “生存法则”。我们团队每季度都会做一次 “三维复盘”，形成闭环优化：

1. SLI 复盘：淘汰 “无效指标”，补充 “缺失指标”。比如我们发现 “node_memory_usage” 对业务可用性影响极小，就从核心 SLI 中剔除；而 “容器镜像拉取延迟” 经常导致 Pod 启动失败，就新增为核心 SLI，并对接了镜像加速服务。

2. SLO 复盘：动态调整目标阈值。有个监控业务的 SLO“Pod 就绪率≥99.9%” 连续半年达标率 100%，我们就把目标提至 99.99%，同时减少了 2 个冗余节点，每月省了 5 万块成本。

3. SLA 复盘：优化条款合理性。之前 SLA 写 “故障后 30 分钟内响应”，业务团队反馈太慢；我们改成 “15 分钟响应”，但要求业务必须提供 “故障时间、影响范围、关键日志” 三要素 —— 双方权责对等，合作更顺畅。

结语：从 “通天河” 到 “K8s 集群”，不变的是 “契约 + 数据” 双驱动

唐僧师徒过通天河的故事，本质上是 “目标（渡河）- 工具（渡船）- 保障（契约）” 的闭环。而 K8s 运维中的 SLI/SLO/SLA，正是这个闭环的技术载体：

• SLI 是 “渡船的核心零件”，用数据告诉你 “集群能不能用”；

• SLO 是 “渡河的航行目标”，用标准明确 “集群该用到什么程度”；

• SLA 是 “渡河的合作契约”，用规则约束 “出问题该怎么办”。

很多团队把 SLI/SLO/SLA 做成了 “应付领导的 KPI 报表”，却忘了它们的本质是 “解决实际问题的工具”。就像孙悟空不会为了 “船身好看” 而忽略龙骨强度，我们也不该为了 “指标漂亮” 而堆砌 SLI、虚报 SLO。

最后送大家一句实战总结：没有 SLA 的 SLO 是 “画饼”，没有 SLI 的 SLO 是 “空谈”—— 要想 K8s 集群稳如泰山，先把这 “三兄弟” 的协同逻辑摸透。下次咱们再深入聊 “如何用 Prometheus+Grafana 打造 SLI 监控体系”，教你快速搭建 “通天河航行雷达”，不见不散！