vault backup: 2026-05-18 00:17:59
This commit is contained in:
@@ -0,0 +1,77 @@
|
||||
---
|
||||
tags: [sre, slo, sli, sla, service-level]
|
||||
create time: 2026-05-18 00:50
|
||||
---
|
||||
|
||||
# SLI / SLO / SLA 详解 — 可靠性量化基础
|
||||
|
||||
## 概述
|
||||
|
||||
站点可靠性工程 (SRE) 把运维问题看作**软件工程问题**。它的核心理念是用 SLI/SLO/SLA 来量化服务质量，避免"我觉得系统很慢"这类模糊描述。本文将详细拆解三层模型和实际应用方法。
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
User["用户体验"] --> SLI{"实际测量"}
|
||||
SLI -->|"达标"| SLO_OK["✅ SLO 达成"]
|
||||
SLI -->|"不达标"| Budget["消耗错误预算"]
|
||||
|
||||
Budget --> Left{"预算剩余?"}
|
||||
Left -- "> 50%" --> Ship["快速迭代 🚀"]
|
||||
Left -- "< 10%" --> Stabilize["稳定优先 ❄️"]
|
||||
|
||||
style User fill:#e3f2fd
|
||||
style SLO_OK fill:#e8f5e9
|
||||
style Ship fill:#fff3e0
|
||||
style Stabilize fill:#ffebee
|
||||
```
|
||||
|
||||
## SLI / SLO / SLA 三层模型
|
||||
|
||||
| 术语 | 全称 | 定义 | 谁制定 | 变更频率 |
|
||||
|------|------|------|--------|---------|
|
||||
| **SLI** | Service Level Indicator | 实际度量：用户请求的成功率是多少？ | 观测系统自动产出 | 持续更新 |
|
||||
| **SLO** | Service Level Objective | 内部目标：我们承诺达到 99.9% 可用性 | SRE + 研发 | 季度回顾 |
|
||||
| **SLA** | Service Level Agreement | 对外契约：达不到就赔钱 | 法务 + 商务 | 按合同约定 |
|
||||
|
||||
> [!question] 三者有什么区别？
|
||||
>
|
||||
> - **SLI** = 仪表盘上的真实数字（"今天成功率 99.87%"）
|
||||
> - **SLO** = 内部团队的目标线（"我们要 ≥ 99.9%"）
|
||||
> - **SLA** = 给客户的承诺条款（"达不到赔偿 10% 月费"）
|
||||
>
|
||||
> SLI < SLO → 团队内部关注；SLI < SLA → 客户开始投诉。
|
||||
|
||||
### 实用的类比
|
||||
|
||||
| 层级 | 生活类比 | 技术场景 |
|
||||
|------|---------|---------|
|
||||
| SLI | "我体重秤显示 72kg" | Prometheus 返回的 P99 延迟 230ms |
|
||||
| SLO | "我要保持 70kg 以下" | 研发团队内部追求 P99 < 200ms |
|
||||
| SLA | "健身合约：每周少于 3 次到店扣费" | 对客户提供 99.9% 可用性，否则退款 |
|
||||
|
||||
## 实用性比例对照表
|
||||
|
||||
| SLO | 每年停机时间 | 每月停机时间 | 适用级别 |
|
||||
|-----|-------------|-------------|---------|
|
||||
| **99%** | ~87.6 小时 | ~7.2 小时 | 内部工具（几乎无意义） |
|
||||
| **99.9% ("三个九")** | ~8.76 小时 | ~43 分钟 | 大多数后端服务 ✅ |
|
||||
| **99.95%** | ~4.38 小时 | ~21 分钟 | 核心交易链路 |
|
||||
| **99.99% ("四个九")** | ~52.6 分钟 | ~4.3 分钟 | 金融级 / 支付系统 |
|
||||
| **99.999%** | ~5.26 分钟 | ~26 秒 | 电信级，极难实现 |
|
||||
|
||||
> [!warning] "三个九"是底线
|
||||
>
|
||||
> 如果团队宣称 SLO = 99%，这意味着每月可以容忍近 **7 小时的不可用**——这在生产环境中基本等于没有可用性目标。
|
||||
|
||||
## 补充：如何为你的服务设定合适的 SLO
|
||||
|
||||
1. **从用户视角出发** — 不是"API P99 < 200ms"，而是"用户在正常网络下加载页面 < 2s"
|
||||
2. **参考行业标准** — 内部工具 99.9%，用户-facing 服务 99.95%+
|
||||
3. **考虑成本收益** — 从 99.9% 到 99.99% 可能需要 5~10 倍的基础设施投入
|
||||
4. **先设定保守目标再逐步提升** — 一个达不到的 SLO 比没有 SLO 更有害（团队会习惯打破它）
|
||||
5. **绑定到具体指标** — 每个 SLO 必须有对应的 SLI 自动采集数据支撑
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[../02-错误预算深度解析]] — Error Budget 的计算与应用
|
||||
- [[../hhs/MS/05-部署运维/04-SRE实践]] — SRE 总体概览
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
tags: [sre, error-budget, budget-allocation, sre-alerting]
|
||||
create time: 2026-05-18 00:50
|
||||
---
|
||||
|
||||
# Error Budget 深度解析 — 稳定性与速度的平衡杠杆
|
||||
|
||||
## 概述
|
||||
|
||||
Error Budget（错误预算）是 SRE 体系中最具实操价值的概念之一。它将抽象的"SLO 目标"转化为具体的可消耗量，为产品迭代的快慢提供量化依据。更多背景见 [[../04-SRE实践/01-SLI-SLO-SLA详解]]。
|
||||
|
||||
## 计算方式
|
||||
|
||||
```
|
||||
可用率 = (总时间 - 故障时间) / 总时间 × 100%
|
||||
错误预算 = 1 - SLO
|
||||
|
||||
SLO = 99.9% → 错误预算 = 0.001
|
||||
每月可容忍故障 = 30 × 24 × 60 × 0.001 = 43.2 分钟
|
||||
每周可容忍故障 = 7 × 24 × 60 × 0.001 = 10.1 分钟
|
||||
|
||||
SLO = 99.99% → 错误预算 = 0.0001
|
||||
每月可容忍故障 ≈ 4.3 分钟
|
||||
```
|
||||
|
||||
> [!tip] 理解错误预算的本质
|
||||
>
|
||||
> 错误预算不是"允许出错的额度"，而是"**允许不完美的空间**"。它回答了一个关键问题：在当前的可靠性要求下，团队还能冒多大的风险？
|
||||
|
||||
## 基于错误预算的决策矩阵
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Ratio["错误预算使用率 = 已消耗 / 总预算"]
|
||||
|
||||
Ratio -- "< 50%" --> Green["🟢 绿灯阶段<br/>预算充足: 可以大胆发布<br/>新功能、尝试激进方案<br/>常规发布节奏"]
|
||||
Ratio -- "50~90%" --> Yellow["🟡 黄灯阶段<br/>预算紧张: 收紧发布频率<br/>增加人工审查<br/>暂停非关键功能开发"]
|
||||
Ratio -- "\> 90%" --> Orange["🟠 橙灯阶段<br/>严重不足: 冻结发布<br/>专注稳定性修复<br/>全员 On-Call"]
|
||||
Ratio -- "\> 100%" --> Red["🔴 红灯阶段<br/>预算耗尽: 禁止所有<br/>功能性变更<br/>SLO 事故复盘"]
|
||||
|
||||
style Green fill:#c8e6c9
|
||||
style Yellow fill:#fff9c4
|
||||
style Orange fill:#ffe0b2
|
||||
style Red fill:#ffcdd2
|
||||
```
|
||||
|
||||
### 各阶段的典型行动清单
|
||||
|
||||
| 阶段 | 功能发布 | 技术债处理 | 人员安排 |
|
||||
|------|---------|-----------|---------|
|
||||
| 🟢 绿灯 | 正常节奏 | 按计划推进 | 按需 On-Call |
|
||||
| 🟡 黄灯 | 减少 50%，需额外审批 | 启动专项清理 | 增加第二响应人 |
|
||||
| 🟠 橙灯 | 冻结（仅 Hotfix） | 全员投入修复 | 负责人值班 |
|
||||
| 🔴 红灯 | 全面冻结 | Postmortem + 专项改进 | 全员待命 |
|
||||
|
||||
## 错误预算告警联动
|
||||
|
||||
```yaml
|
||||
# Prometheus 告警规则示例
|
||||
groups:
|
||||
- name: error-budget
|
||||
rules:
|
||||
- alert: ErrorBudgetBurnRateHigh
|
||||
expr: |
|
||||
sum(rate(http_requests_total{status=~"5.."}[1h])) /
|
||||
sum(rate(http_requests_total[1h])) > 0.001
|
||||
for: 1h
|
||||
labels:
|
||||
severity: warning
|
||||
budget_phase: yellow
|
||||
annotations:
|
||||
summary: "错误预算消耗加速"
|
||||
message: "当前错误率 {{ $value }}% > SLO 阈值 0.1%"
|
||||
|
||||
- alert: ErrorBudgetExhausted
|
||||
expr: |
|
||||
(sum(rate(http_requests_total{status=~"5.."}[24h])) /
|
||||
sum(rate(http_requests_total[24h]))) >= 0.001
|
||||
labels:
|
||||
severity: critical
|
||||
budget_phase: red
|
||||
annotations:
|
||||
summary: "错误预算已耗尽！"
|
||||
message: "本月 SLO 已破线，冻结非紧急变更"
|
||||
```
|
||||
|
||||
> [!info] Multi-window Burn Rate Alerting
|
||||
>
|
||||
> Google SRE 推荐的做法是使用**两个窗口**来检测预算消耗速度：
|
||||
> - **短窗口（1h/5m）**：检测突发大量错误的情况（立即触发黄灯）
|
||||
> - **长窗口（半天/一天）**：检测慢性缓慢泄漏的情况（防止温水煮青蛙）
|
||||
>
|
||||
> 只有当两个窗口同时超限时才亮红灯，这样可以避免误报导致的警报疲劳。
|
||||
|
||||
## 补充：多服务 Error Budget 管理策略
|
||||
|
||||
当集群中有几十上百个服务时，不能把所有预算分配给同一个 SLO。推荐分层策略：
|
||||
|
||||
| 层级 | 示例 | 预算分配 |
|
||||
|------|------|---------|
|
||||
| P0 核心链路 | 支付、登录 | 99.99% → 极低容错 |
|
||||
| P1 重要服务 | 订单、搜索 | 99.95% → 中等容错 |
|
||||
| P2 一般服务 | 后台管理、报表 | 99.9% → 较高容错 |
|
||||
|
||||
> [!tip] Error Budget 分配实战技巧
|
||||
>
|
||||
> 将月度预算**均匀摊分到每周**作为基线。例如月预算 43 分钟 → 每周预算约 10 分钟。这比月末一次性清算更有操作性——你可以在周报中直接看到本周预算余量。
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[../04-SRE实践/01-SLI-SLO-SLA详解]] — SLI/SLO/SLA 三层模型基础
|
||||
- [[../04-SRE实践/03-SRE心法与事故复盘]] — Blameless Postmortem 模板
|
||||
- [[../hhs/MS/05-部署运维/02-Kubernetes]] — K8s HPA 弹性伸缩支撑 SLO 保障
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
tags: [sre, postmortem, blameless, dora-metrics, incident-management]
|
||||
create time: 2026-05-18 00:50
|
||||
---
|
||||
|
||||
# SRE 心法与事故复盘 — 文化和方法论
|
||||
|
||||
## 概述
|
||||
|
||||
SRE 不仅是技术指标和告警规则，更是一种工作文化。本章介绍 Google SRE 提出的五条核心心法，以及事故复盘的标准流程和 DORA Metrics 效能评估框架。更多 SLO/Error Budget 理论参见 [[../04-SRE实践/01-SLI-SLO-SLA详解]]。
|
||||
|
||||
## SRE 五条心法
|
||||
|
||||
### 1. 用户视角定义 SLO
|
||||
|
||||
> 不是"API P99 < 200ms"，而是"用户在正常网络下加载页面 < 2s"。
|
||||
|
||||
技术指标可能欺骗你——P99 延迟低不代表用户体验好。一个前端图片加载慢 3 秒的服务，后端再快也无法让用户满意。**永远从用户的感知出发定义质量**。
|
||||
|
||||
### 2. 错误预算用完 = 停止功能开发
|
||||
|
||||
当 Error Budget 耗尽时，团队必须全力修 bug、加稳定性，而不是继续发新功能。这不是惩罚，而是**资源重新分配的客观依据**。
|
||||
|
||||
### 3. Blameless Postmortem
|
||||
|
||||
不问"谁干的"，问"流程哪里可以改进"。责备个人只会让团队成员隐瞒问题，最终酿成更大的事故。
|
||||
|
||||
### 4. 自动化一切重复劳动
|
||||
|
||||
手动操作一定会出错。无论是回滚、扩容还是配置变更，能脚本化的绝不人工执行。这不仅仅是效率问题，更是**可靠性问题**。
|
||||
|
||||
### 5. 接受一定程度的失败
|
||||
|
||||
在可控范围内快速迭代，比追求完美更重要。Google 的"可控失败"理念认为：**小规模的失败是发现系统性问题的最佳途径**。
|
||||
|
||||
## Blameless Postmortem 模板
|
||||
|
||||
| 字段 | 填写内容 |
|
||||
|------|---------|
|
||||
| **事件名称** | `2026-05-05 支付服务超时事故` |
|
||||
| **影响范围** | 约 15% 的支付请求失败，持续 23 分钟 |
|
||||
| **发现时间** | 14:32 (On-Call 接到告警) |
|
||||
| **恢复时间** | 14:55 (回滚后确认恢复) |
|
||||
| **根本原因** | 某次变更后支付网关的连接池大小从 50 降到 10 |
|
||||
| **时间线** | 14:00 发布 v1.2.3 → 14:30 错误率开始升高 → 14:32 收到告警 → 14:35 开始排查 → 14:45 定位根因 → 14:50 回滚 → 14:55 完全恢复 |
|
||||
| **改进行动** | ① 连接池参数变动必须经过压测验证；② 监控中补充连接池活跃数指标 |
|
||||
| **跟进人** | @zhangsan (行动 ①)、@lisi (行动 ②) |
|
||||
|
||||
> [!tip] 什么是真正的 "Blameless"？
|
||||
>
|
||||
> Blameless ≠ 不追究责任。它的意思是：**聚焦于系统和流程缺陷，而非个人的失误**。人类会犯错，这是物理定律级别的现实。好的 Postmortem 应该揭示为什么系统设计允许一个简单的配置变更导致大规模故障。
|
||||
|
||||
### Postmortem 写作原则
|
||||
|
||||
| 原则 | 做法 |
|
||||
|------|------|
|
||||
| **事实先行** | 按时间线罗列发生了什么，不掺入主观判断 |
|
||||
| **5 Whys 分析法** | 连续问 5 次"为什么"，直到触及根因 |
|
||||
| **行动项可追踪** | 每个改进措施都要有负责人和截止日期 |
|
||||
| **公开透明** | Postmortem 全文共享给全公司，不隐藏信息 |
|
||||
| **闭环验证** | 改进措施完成后回顾是否真正预防了同类问题 |
|
||||
|
||||
## SRE Metrics 看板
|
||||
|
||||
除了 SLO，SRE 还需要关注以下运营指标：
|
||||
|
||||
| 指标 | 说明 | 目标 |
|
||||
|------|------|------|
|
||||
| **MTTR** | Mean Time To Recovery | 核心服务 < 30min |
|
||||
| **Change Failure Rate** | 变更导致故障的比例 | < 5% |
|
||||
| **Lead Time for Changes** | 代码提交到上线的时间 | < 2h |
|
||||
| **Deployment Frequency** | 日均部署次数 | > 5 (大规模团队) |
|
||||
|
||||
> [!tip] DORA Metrics
|
||||
>
|
||||
> Google 提出的四大 DevOps 指标，广泛用于评估工程效能：
|
||||
> - **部署频率** — 交付速度
|
||||
> - **变更前置时间** — 从代码提交到生产部署需要多久
|
||||
> - **变更失败率** — 多少部署导致了故障或回滚
|
||||
> - **MTTR** — 恢复服务的平均时间
|
||||
|
||||
### 四种绩效等级的 DORA 表现
|
||||
|
||||
| 等级 | 部署频率 | 变更前置时间 | 变更失败率 | MTTR |
|
||||
|------|---------|-------------|-----------|------|
|
||||
| 🏆 精英 (Elite) | 每日多次 | < 1 小时 | < 5% | < 1 小时 |
|
||||
| 🥈 高 (High) | 每周 1-6 次 | < 1 周 | 6-15% | 1-7 天 |
|
||||
| 🥉 中 (Medium) | 每月 < 1 次 | 1-4 周 | 16-30% | > 1 个月 |
|
||||
| ⬜ 低 (Low) | < 每月 1 次 | > 6 个月 | > 30% | > 6 个月 |
|
||||
|
||||
> [!info] 关于 DORA 的提醒
|
||||
>
|
||||
> DORA Metrics 的价值在于**纵向对比自身演进**，而非横向攀比。一个创业团队追求"精英级"可能过度工程化。关键是看趋势——如果你的 Change Failure Rate 从 20% 降到了 10%，这就是实质性的进步。
|
||||
|
||||
## 补充：事故分级标准
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
P0["🔴 P0 - 灾难性<br/>全站不可用 / 资金损失<br/>CTO 级别通知<br/>2h内必须恢复"] --> P1
|
||||
P1["🟠 P1 - 严重<br/>核心功能受影响<br/>负责人 + SRE 紧急会议<br/>4h内必须恢复"] --> P2
|
||||
P2["🟡 P2 - 一般<br/>部分功能降级<br/>工作时间处理<br/>24h内必须恢复"] --> P3
|
||||
P3["🟢 P3 - 轻微<br/>非核心问题<br/>下个迭代处理"]
|
||||
|
||||
style P0 fill:#ffcdd2
|
||||
style P1 fill:#ffe0b2
|
||||
style P2 fill:#fff9c4
|
||||
style P3 fill:#c8e6c9
|
||||
```
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[../04-SRE实践/01-SLI-SLO-SLA详解]] — SLI/SLO/SLA 三层模型
|
||||
- [[../04-SRE实践/02-错误预算深度解析]] — Error Budget 告警联动
|
||||
- [[../hhs/MS/05-部署运维/02-Kubernetes]] — K8s 自愈能力与 SLO 保障
|
||||
Reference in New Issue
Block a user