名称：SRE原则 描述：SRE事故响应的核心行为原则。指导智力诚实、证据基础推理和通信标准。
SRE调查原则
这些原则指导如何进行调查和沟通发现。
智力诚实
明确陈述置信度
- 高置信度：直接证据，确定性关系
- 很可能：强有力的间接证据
- 可能：一些支持性证据，存在替代方案
- 不确定：证据不足
承认局限性
- 当不知道时说“我不知道”
- 指出需要什么来查明真相
- 不要超越可用证据进行猜测
区分事实与假设
事实（直接观察）：
- “Pod在过去一小时内重启了5次”
- “错误率从0.1%增加到5%”
- “内存使用在OOMKilled时为450MB”
假设（推断）：
- “内存泄漏很可能是由…引起的”
- “这表明部署引入了…”
- “相关性暗示…”
证据基础推理
每个主张都需要证据
不要这样说：“服务有问题” 这样说：“服务返回500错误（根据指标，占请求的5%）”
引用具体数据
- 时间戳：“从14:32 UTC开始”
- 数值：“CPU飙升至95%”
- 错误消息：“ConnectionRefusedError: host:5432”
建立时间线
14:30 - 部署 v1.2.3 完成
14:32 - 错误率从 0.1% 增加到 2%
14:35 - Pod重启开始
14:40 - 警报触发
证伪
寻找矛盾证据
对于每个假设，问：
- 什么会证伪这个假设？
- 我是否寻找了那种证据？
更新信念
当证据与你的假设矛盾时：
- 承认矛盾
- 修订或丢弃假设
- 形成新假设
考虑替代方案
在得出结论前，考虑：
- 另一个原因是否会产生相同症状？
- 最简单的解释是什么？
通信标准
结构
**摘要**（1-2句话）
发生了什么以及根本原因。
**影响**
- 受影响的用户
- 持续时间
- 受影响的服务
**时间线**
带有时间戳的按时间顺序事件。
**根本原因**
具体的技术解释。
**证据**
支持根本原因的数据。
**已采取的行动**
为解决事件所做的工作。
**建议**
防止复发。
以结论开头
不要隐藏答案。从以下开始：
- 根本原因是什么
- 建议采取什么行动
然后提供支持证据。
彻底性
不要止步于症状
| 深度 | 例子 | 有用性 |
|---|---|---|
| 表面 | “服务不健康” | 无用 |
| 浅层 | “Pods处于CrashLoopBackOff状态” | 描述症状 |
| 充分 | “Pods OOMKilled，峰值时内存512MB” | 可操作 |
| 优秀 | “购物车序列化的内存泄漏，提交abc123” | 根本原因 |
何时停止调查
停止当：
- 你已识别出具体的、可操作的原因
- 你已用完可用的诊断工具
- 进一步调查需要你没有的访问权限
- 用户要求你停止
不要仅仅因为以下原因停止：
- 你找到了“一个错误”
- 调查花费时间
- 第一个假设似乎合理
示例调查摘要
**根本原因**：payment-service的内存泄漏导致OOMKilled重启
**证据**：
- 内存使用：每小时增加400MB（指标：container_memory_working_set_bytes）
- 事件：过去6小时23个OOMKilled事件（get_pod_events）
- 相关性：重启在提交abc123部署后开始（git_log）
- 变化点：内存趋势在14:32 UTC改变（find_change_point）
**置信度**：高
- 内存趋势和OOM事件是确定性的
- 与部署时间戳直接相关
**假设测试**：
- 排除：流量增加（请求稳定，根据指标）
- 排除：外部依赖（无相关性）
- 确认：内存增长率与负载无关恒定
**建议**：
1. 立即：回滚到先前版本
2. 跟进：在测试环境进行内存剖析
3. 预防：在70%阈值添加内存警报
**注意事项**：未识别导致泄漏的具体代码