161 lines
6.1 KiB
Markdown
161 lines
6.1 KiB
Markdown
---
|
||
tags: [microservice, sre, slo, error-budget, postmortem]
|
||
create time: 2026-05-05
|
||
---
|
||
|
||
# SRE 实践
|
||
|
||
## 概述
|
||
|
||
站点可靠性工程 (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 | 对外契约：达不到就赔钱 | 法务 + 商务 | 按合同约定 |
|
||
|
||
### 实用性比例对照表
|
||
|
||
| 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 小时的不可用**——这在生产环境中基本等于没有可用性目标。
|
||
|
||
## Error Budget (错误预算) 深度解析
|
||
|
||
### 计算方式
|
||
|
||
```
|
||
可用率 = (总时间 - 故障时间) / 总时间 × 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 分钟
|
||
```
|
||
|
||
### 基于错误预算的决策矩阵
|
||
|
||
```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
|
||
```
|
||
|
||
### 错误预算告警联动
|
||
|
||
```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 已破线，冻结非紧急变更"
|
||
```
|
||
|
||
## SRE 心法
|
||
|
||
1. **用户视角定义 SLO** — 不是"API P99 < 200ms"，而是"用户在正常网络下加载页面 < 2s"
|
||
2. **错误预算用完 = 停止功能开发** — 全力修 bug、加稳定性
|
||
3. **Blameless Postmortem** — 不问"谁干的"，问"流程哪里可以改进"
|
||
4. **自动化一切重复劳动** — 手动操作一定会出错
|
||
5. **接受一定程度的失败** — 在可控范围内快速迭代，比追求完美更重要
|
||
|
||
## 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 (行动 ②) |
|
||
|
||
## 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** — 恢复服务的平均时间
|
||
|
||
## 关联笔记
|
||
|
||
- [[04-可观测性/04-告警管理]] — SLO/Error Budget 与告警体系的联动
|
||
- [[05-部署运维/02-Kubernetes]] — K8s HPA 弹性伸缩支撑 SLO 保障
|
||
- [[05-部署运维/03-CICD与GitOps]] — GitOps 支持安全的持续交付
|