name: operating-production-services description: | 用于生产服务可靠性的SRE模式：SLO、错误预算、事后分析和事件响应。适用于定义可靠性目标、撰写事后分析报告、实施SLO告警或建立值班实践。不适用于初始服务开发（请改用脚手架技能）。

生产服务运维

生产可靠性模式：衡量重要指标，从失败中学习，系统性地改进。

快速参考

需求	前往
定义可靠性目标	SLO与错误预算
撰写事件报告	事后分析模板
设置SLO告警	references/slo-alerting.md

SLO与错误预算

层级关系

SLA (合同) → SLO (目标) → SLI (测量)

常见SLI

# 可用性：成功请求数 / 总请求数
sum(rate(http_requests_total{status!~"5.."}[28d]))
/
sum(rate(http_requests_total[28d]))

# 延迟：低于阈值的请求数 / 总请求数
sum(rate(http_request_duration_seconds_bucket{le="0.5"}[28d]))
/
sum(rate(http_request_duration_seconds_count[28d]))

SLO目标现实检查

SLO %	每月停机时间	每年停机时间
99%	7.2小时	3.65天
99.9%	43分钟	8.76小时
99.95%	22分钟	4.38小时
99.99%	4.3分钟	52分钟

不要追求100%。 每增加一个9，成本呈指数级增长。

错误预算

错误预算 = 1 - SLO目标

示例： 99.9% SLO = 0.1% 错误预算 = 43分钟/月

策略：

剩余预算	行动
> 50%	正常开发速度
10-50%	推迟高风险变更
< 10%	冻结非关键变更
0%	功能冻结，修复可靠性

查看 references/slo-alerting.md 获取Prometheus记录规则和多窗口燃烧率告警。

事后分析模板

无责原则

追责导向	无责导向
“谁导致了这个问题？”	“什么条件允许了这个问题发生？”
惩罚个人	改进系统
隐藏信息	分享学习成果

何时撰写事后分析

SEV1/SEV2事件
面向客户的停机时间 > 15分钟
数据丢失或安全事件
可能很严重的侥幸事件
新的故障模式

标准模板

# 事后分析：[事件标题]

**日期**：YYYY-MM-DD | **持续时间**：X分钟 | **严重性**：SEVX

## 执行摘要
一段话：发生了什么、影响、根本原因、解决方案。

## 时间线（UTC）
| 时间 | 事件 |
|------|-------|
| HH:MM | 首次告警触发 |
| HH:MM | 值班人员确认 |
| HH:MM | 根本原因确定 |
| HH:MM | 修复部署 |
| HH:MM | 服务恢复 |

## 根本原因分析

### 5个为什么
1. 为什么服务失败？ → [答案]
2. 为什么[1]发生？ → [答案]
3. 为什么[2]发生？ → [答案]
4. 为什么[3]发生？ → [答案]
5. 为什么[4]发生？ → [根本原因]

## 影响
- 受影响的客户：X
- 持续时间：X分钟
- 收入影响：$X
- 支持工单：X

## 行动项
| 优先级 | 行动 | 负责人 | 截止日期 | 工单 |
|----------|--------|-------|-----|--------|
| P0 | [立即修复] | @姓名 | 日期 | XXX-123 |
| P1 | [防止再次发生] | @姓名 | 日期 | XXX-124 |
| P2 | [改进检测] | @姓名 | 日期 | XXX-125 |

快速模板（次要事件）

# 快速事后分析：[标题]

**日期**：YYYY-MM-DD | **持续时间**：X分钟 | **严重性**：SEV3

## 发生了什么
一句话描述。

## 时间线
- HH:MM - 触发
- HH:MM - 检测
- HH:MM - 解决

## 根本原因
一句话。

## 修复
- 立即：[做了什么]
- 长期：[工单 XXX-123]

事后分析会议指南

结构（60分钟）

开场（5分钟） - 提醒：“我们在这里是为了学习，而不是追责”
时间线（15分钟） - 按时间顺序回顾事件
分析（20分钟） - 什么失败了？为什么？什么条件允许了它？
行动项（15分钟） - 确定优先级、分配负责人、设定日期
结束（5分钟） - 总结学习成果，确认负责人

引导技巧

将责任引向系统：“什么让这个错误成为可能？”
为离题话题设定时间限制
记录不同意见
鼓励安静的参与者发言

反模式

不要	替代做法
追求100% SLO	接受错误预算的存在
跳过小事件	小事件揭示模式
孤立行动项	每个项目都需要负责人+日期+工单
责备个人	问“什么条件允许了这件事发生？”
创建无意义的行动	行动应防止再次发生

验证

运行：python scripts/verify.py

参考资料

references/slo-alerting.md - Prometheus规则、燃烧率告警、Grafana仪表板