SRE
由Google提出的工程实践方法论，将软件工程方法应用于运维领域，关注系统可靠性、可用性和性能，核心实践包括SLO/SLI管理、事故复盘和自动化运维
核心事实
时间轴 (近 90 天)
团队应明确区分“会用 AI 排障”和“能在 AI 失效时独立排障”两种能力层级，并在晋升与培训体系中体现这种区分。
SRE 的工作天然处在“自动化”与“判断力”的交界处：核心价值在于自动化失效时的判断能力。
在团队内部刻意保留一部分需要手动排查的故障演练（如定期无 AI 辅助的故障注入和复盘）有助于维持工程师的判断能力。
在 SRE 语境下，隐性知识表现为对系统行为的模式识别能力，例如从 GC 日志的细微抖动判断内存泄漏前兆。
Postmortem（事后复盘文档）在 SRE 文化中遵循「无指责复盘」（blameless postmortem）原则，聚焦系统与流程缺陷而非追究个人责任。
SRE 实践中修复上线不等于故障结束，需要观察窗口确认错误率、延迟分位数等 SLI 恢复到正常区间并稳定若干分钟。
云平台和低代码工具都在将运维能力封装为内置服务，平台层正在吸收越来越多原本属于 SRE 的工作。
On-call（值班待命）是 SRE/运维和基础设施团队常见的轮值制度，值班流程一般包含确认、分诊、升级与复盘等环节。
MTTR（平均恢复时间）是衡量告警处理流程效率的核心指标，也是 SRE 领域最常被引用的 KPI 之一。
MTTD（Mean Time to Detect / Diagnose，平均检测或诊断时间）是 SRE 与 DevOps 领域常用度量指标，指从问题发生或测试失败被记录到工程师明确识别根因所经历的平均时长。
还有 32 条时间轴事件
全部知识事实 (20)
SRE由Google于2003年创立，核心理念是将软件工程方法应用于运维工作
75%已验证SRE（站点可靠性工程）是Google提出并推广的工程实践，核心思想是用软件工程方法解决运维问题，将系统可靠性量化为SLO并持续度量
65%已验证AI代理更适合承担需要动态判断和容错的环节，稳定、确定性强的核心断言仍可保留传统方式
65%已验证AI运维工具的普及导致工程师逐渐失去对自己所构建系统的直觉与掌控
65%已验证SLI是衡量服务健康度的具体指标，SLO是团队内部设定的目标值，SLA是对外的商业承诺违反时需承担经济赔偿
65%待验证Minions的分层恢复机制借鉴了分布式系统故障分类学（崩溃故障、遗漏故障、拜占庭故障）和SRE领域的工程实践
85%待验证Google在著作《SRE: How Google Runs Production Systems》中将MTTR、MTTD、MTBF等指标体系化
70%待验证MTTR 是 DORA 四大关键指标之一，衡量从故障发生到服务恢复的平均耗时，包括检测时间、响应时间、诊断时间和修复时间
60%待验证团队应明确区分“会用 AI 排障”和“能在 AI 失效时独立排障”两种能力层级，并在晋升与培训体系中体现这种区分。
50%待验证SRE 的工作天然处在“自动化”与“判断力”的交界处：核心价值在于自动化失效时的判断能力。
50%待验证在团队内部刻意保留一部分需要手动排查的故障演练（如定期无 AI 辅助的故障注入和复盘）有助于维持工程师的判断能力。
50%待验证在 SRE 语境下，隐性知识表现为对系统行为的模式识别能力，例如从 GC 日志的细微抖动判断内存泄漏前兆。
50%待验证Postmortem（事后复盘文档）在 SRE 文化中遵循「无指责复盘」（blameless postmortem）原则，聚焦系统与流程缺陷而非追究个人责任。
50%待验证SRE 实践中修复上线不等于故障结束，需要观察窗口确认错误率、延迟分位数等 SLI 恢复到正常区间并稳定若干分钟。
50%待验证云平台和低代码工具都在将运维能力封装为内置服务，平台层正在吸收越来越多原本属于 SRE 的工作。
50%待验证On-call（值班待命）是 SRE/运维和基础设施团队常见的轮值制度，值班流程一般包含确认、分诊、升级与复盘等环节。
50%待验证MTTR（平均恢复时间）是衡量告警处理流程效率的核心指标，也是 SRE 领域最常被引用的 KPI 之一。
50%待验证MTTD（Mean Time to Detect / Diagnose，平均检测或诊断时间）是 SRE 与 DevOps 领域常用度量指标，指从问题发生或测试失败被记录到工程师明确识别根因所经历的平均时长。
50%待验证SRE 实践中建议将续期预警提前到到期日前 7 至 14 天，并附带列表编号、价格、销量、历史续期记录等上下文，使告警可行动。
50%待验证在 DevOps 和 SRE 场景中，一次错误的删除操作或误判的告警处置可能导致生产事故。
50%