SRE
由Google提出的工程实践方法论，将软件工程方法应用于运维领域，关注系统可靠性、可用性和性能，核心实践包括SLO/SLI管理、事故复盘和自动化运维
核心事实
时间轴 (近 90 天)
DevOps更偏向文化、流程与工程实践的整合，强调开发与运维协作、CI/CD、自动化与快速反馈；SRE（Site Reliability Engineering）则更侧重于通过软件工程方法解决运维问题，关注可靠性、SLO和自动化。
Manish认为AI无法回避，应把AI作为提升交付速度和质量的工具，而非竞争对手，且DevOps和SRE目前仍是高需求、高薪酬的方向。
Google SRE 的统计经验表明，生产环境故障中约七成由某种变更引发——新部署、配置推送、依赖升级、扩缩容策略调整都算。
Postmortem 是故障恢复之后撰写的复盘文档，通常包括故障时间线、影响范围、根因分析、处置过程以及防止复发的改进项，强调「对事不对人」。
在跨国协作的 SRE 场景中，统一以 UTC 记录事件时间线是行业惯例。
传统RCA依赖'5个为什么'和鱼骨图等结构化方法逐层追溯因果链
SRE评测需要与活跃的运行时环境交互，其状态管理和副作用控制的复杂度高于SWE-bench
SRE工作是一个涉及观测、假设、验证、修复的闭环过程，而非一次性的代码生成
SRE通过日志、指标、链路追踪三大支柱（可观测性）来理解系统内部状态
针对运维场景的专门AI Agent评测基准相对稀缺，当前评测大多集中在编程、问答、推理等通用任务上
还有 16 条时间轴事件
全部知识事实 (20)
AI代理更适合承担需要动态判断和容错的环节，稳定、确定性强的核心断言仍可保留传统方式
65%待验证Minions的分层恢复机制借鉴了分布式系统故障分类学（崩溃故障、遗漏故障、拜占庭故障）和SRE领域的工程实践
85%待验证Google在著作《SRE: How Google Runs Production Systems》中将MTTR、MTTD、MTBF等指标体系化
70%待验证DevOps更偏向文化、流程与工程实践的整合，强调开发与运维协作、CI/CD、自动化与快速反馈；SRE（Site Reliability Engineering）则更侧重于通过软件工程方法解决运维问题，关注可靠性、SLO和自动化。
50%待验证Manish认为AI无法回避，应把AI作为提升交付速度和质量的工具，而非竞争对手，且DevOps和SRE目前仍是高需求、高薪酬的方向。
50%待验证Google SRE 的统计经验表明，生产环境故障中约七成由某种变更引发——新部署、配置推送、依赖升级、扩缩容策略调整都算。
50%待验证Postmortem 是故障恢复之后撰写的复盘文档，通常包括故障时间线、影响范围、根因分析、处置过程以及防止复发的改进项，强调「对事不对人」。
50%待验证在跨国协作的 SRE 场景中，统一以 UTC 记录事件时间线是行业惯例。
50%待验证传统RCA依赖'5个为什么'和鱼骨图等结构化方法逐层追溯因果链
50%待验证SRE工作是一个涉及观测、假设、验证、修复的闭环过程，而非一次性的代码生成
50%待验证针对运维场景的专门AI Agent评测基准相对稀缺，当前评测大多集中在编程、问答、推理等通用任务上
50%待验证SRE评测需要与活跃的运行时环境交互，其状态管理和副作用控制的复杂度高于SWE-bench
50%待验证SRE通过日志、指标、链路追踪三大支柱（可观测性）来理解系统内部状态
50%待验证在SRE诊断场景中，LLM可能以自信的口吻给出错误根因判断，把工程师引向错误方向，反而延长故障时间
50%待验证SRE（站点可靠性工程）是Google提出并推广的工程实践，核心思想是用软件工程方法解决运维问题，将系统可靠性量化为SLO并持续度量
50%待验证Google SRE体系中的Postmortem文化要求每一项事故后续行动必须有且仅有一个具名负责人与截止日期，而非笼统地归属于某个团队
50%待验证SRE 实践中将无指责文化的公开 Postmortem 视为提升系统可靠性的核心手段之一
50%待验证Harness Engineering 可类比于传统软件工程中的可靠性工程（SRE），但聚焦于以大模型为核心的智能体系统
50%待验证Agent Reliability的核心思路是把SRE（站点可靠性工程）的可靠性度量方法迁移到AI Agent评测中
50%待验证SRE强调用错误预算（error budget）量化可靠性目标，并将toil的比例控制在工程师工作时间的50%以下
50%