Init

2026-05-24 11:42:38 +08:00
commit 30d312ac35
521 changed files with 146481 additions and 0 deletions
@@ -0,0 +1,160 @@
+---
+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 支持安全的持续交付