SRE别再当救火队了：ITIL v5 的这套框架，其实是在帮你把可靠性变成工程能力

很多组织引入站点可靠性工程（SRE）的时候，心里想得很美：

有了SRE，稳定性会提升，重大事件会减少，夜战会变少。

可过半年你再去问SRE同学，他们常常会苦笑：

“我们成了高级运维。”

“警报太多，天天在救火。”

“事故复盘写了很多，重复问题还是一堆。”

这不是SRE不行，而是组织把SRE放在了一个很尴尬的位置：既要你当工程师把系统做稳，又要你当救火队把锅接住；既要你改架构、补可观测性，又不给你参与转换和变更实施的授权；既要你对结果负责，又缺少可审计性的决策链条。最后SRE只能靠英雄主义撑着，撑着撑着就撑不动了。

ITIL 第5版在我看来给了一个很好的“翻译器”：它把管理对象扩展到数字产品与数字服务，用八个阶段活动把全生命周期讲清楚，还强调治理、问责、可审计性，以及人工智能与自动化的边界。你把这些和SRE的工程理念结合起来，SRE就不该是救火队，而应该是把可靠性变成组织能力的那支队伍。

一、为什么第5版更适合和SRE一起用

ITIL 第5版相对 ITIL 4 的核心升级要点如下：

• 管理对象从服务扩展到数字产品与数字服务

• 八个阶段活动的全生命周期：发现、设计、获取、构建、转换、运营、交付、支持

• 体验写入价值定义，稳定与透明本身就是体验

• 治理强调授权、问责、可审计性与纠偏

• 人工智能与自动化纳入体系，能力越强越需要边界

SRE追求的可靠性，本质上也是体验的一部分：可用性、性能/绩效、恢复速度、可预测性。第5版的贡献在于：它让这些目标不再只是SRE的技术追求，而能被放进治理体系与生命周期里，让组织在关键节点做对选择。

二、SRE和传统运维最大的区别：不是更能救火，而是更懂“让火少起来”

如果SRE每天都在救火，那说明你只用了SRE的“运维那一半”，没用上“工程那一半”。工程那一半是什么？

• 把重复劳动自动化

• 把警报的准确性提升

• 把可观测性补齐

• 把瓶颈做成可预测

• 把事故复盘变成持续改进举措

这些事情要做到，SRE必须能影响的不只是运营阶段，还要能影响：设计、构建、转换、变更实施。否则你只能在后半段拼命兜底。

ITIL 第5版的全生命周期视角，正好能把SRE的影响力“合法化”：把可靠性需求前置，把验证与转换做扎实，让SRE不再只在事故里出现。

三、先把几个词对齐：事态、警报、事件、重大事件，SRE和ITIL说的是同一件事

很多组织SRE和ITIL团队沟通不顺，其实是术语不对齐。你可以用一套简单的映射：

• 监控和事态管理实践关注的采集与分类

• 警报（alert）是从事态里筛出来的信号

• 事件（incident）是已经影响或即将影响服务价值的中断或质量下降

• 重大事件（major incident）是高影响、需要指挥与协调的事件

SRE的告警、on-call、incident response，其实就是这条链路。第5版强调能见度范围、准确性、可审计性，本质是在要求这条链路更清晰、更可控、更能复用。

四、能见度范围：SRE最怕什么都归我，最需要边界

很多SRE被累垮，不是因为工作量大，而是因为边界不清：

• 任何警报都@SRE

• 任何性能问题都找SRE

• 任何上线翻车都叫SRE救场

• 任何用户申告都要求SRE解释

这不是SRE的职责设计，这是组织在把复杂性丢给一个团队。第5版强调治理和问责，本质上就是要把边界讲清楚：

• 哪些服务属于SRE的能见度范围

• 哪些关键指标必须被可观测

• 哪些问题需要产品团队负责，SRE只提供指导

• 哪些变更需要SRE参与风险评估与验收标准定义

能见度范围定清楚，SRE才有可能把时间从救火挪到工程化改进上。

五、把SRE前置到“转换”和“变更实施”：这是减少夜战的关键杠杆

很多事故发生在转换之后的头24小时，原因往往不是代码错，而是：监控没接、警报不准、容量评估没做、回滚不可用、支持没口径。

ITIL 第5版的变更实施实践与转换活动，为SRE提供了一个非常明确的介入点：

• 在变更实施里参与风险评估

• 在变更模型里定义可靠性验收标准

• 在转换就绪度里检查可观测性、回滚与容量

• 在发布日程里定义监控重点与警报节奏

你把这些做扎实，SRE的值班会轻很多。因为事故会少，问题会更快被定位，支持也更能接得住。

六、度量与报告：SRE别只盯技术指标，要把指标变成治理语言

SRE最常见的一类误区是：只讲技术指标，讲到最后没人听得懂，也没人愿意为指标负责。

ITIL 第5版的度量与报告实践给你一个更“治理化”的表达方式：把指标变成选择依据。

你可以把指标分三层，沟通会顺很多：

• 服务体验层：可用性、延迟、吞吐量、恢复速度、关键接触点是否稳定

• 风险与变更层：变更失败率、回滚次数、发布后事件数、交付周期（lead time）

• 运营效率层：警报准确性、误报率、平均定位时间、重复事件比例

这些指标要能支撑问责与可审计性：出事后能解释“为什么”、改进后能验证“有没有变好”。指标不是为了证明你忙，是为了让组织做更好的决策。

七、重大事件与复盘：别让复盘停在“事故作文”，要变成持续改进举措

SRE通常很重视复盘，但复盘容易走偏：写得很深刻，却没有改动落地。第5版强调持续改进实践与治理纠偏，就是要把复盘结果变成“能执行、能验证”的改进举措。

我建议每次重大事件复盘至少产出三类行动：

• 可观测性补齐：哪些日志、指标、链路追踪缺失导致定位慢

• 变更与转换改进：哪些验收标准缺失导致风险没被看见

• 支持与沟通改进：哪些口径与升级路径缺失导致体验崩盘

每一类行动都必须有负责人、截止时间、验证方式。否则复盘就是情绪宣泄，下一次还会重演。

八、人工智能能帮SRE什么：先帮你提高准确性，再谈自动化处置

人工智能在SRE场景很有用，但必须在治理边界内使用。更稳的方向是：

• 聚类事态与警报，提高准确性，减少噪音

• 关联配置项 (CI)、变更、事件，辅助定位

• 生成重大事件通告草稿，提高沟通一致性

• 提示高风险变更模式，辅助风险评估

但不要让人工智能替你承担问责。高风险动作仍需要授权与回退机制，尤其涉及回滚、降级、权限变更这类操作。

IT组织在引入ITIL 5的过程中，我建议你做一个很具体的转变：

把SRE的目标从“处理了多少事件”转成“减少了多少重复事件”。

你可以用几个很硬的度量指标来验证：

• 重大事件数量下降

• 重复事件比例下降

• 警报误报率下降，准确性提升

• 发布后24小时事件数下降

• 平均定位时间缩短

这些指标一旦下降，SRE就真正从救火队变成工程队，组织也会更愿意给SRE前置介入的授权。

2026年1月29日，PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区大使，我将会继续推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。

我是AI+ITL教练长河，欢迎交流。关注我，即可第一时间获得ITIL第5版最新动态及落地应用方法的深度解析，全网同名。