我做了十多年运维，接触过基础设施、云平台、自动化工具和生产故障。DevOps 和 SRE 这两个词经常出现在岗位介绍里，但要马上说清它们的区别，我仍然会犹豫。
它们的工作看起来太像了：写代码、搭建 Kubernetes、维护监控、处理告警，也都可能使用 Terraform、Ansible 和 CI/CD。
我更愿意从一项具体工作判断：团队希望解决什么问题？我负责什么结果？结果怎样验证？沿着这三个问题看，一次熟悉的服务发布，就能把两者的联系讲清楚。
先分清概念，再看职位名称
DevOps 是一组强调开发与运维协作、自动化和持续反馈的原则与实践。SRE，即站点可靠性工程，则用软件工程方法改善生产系统的可靠性，也对应一种工作角色。Google 将 SRE 描述为落实 DevOps 理念的一种方式。Google：How SRE Relates to DevOps
因此，我们比较的两者，本来就不完全处在同一个层面。到了招聘市场，它们又都变成职位名称，具体职责由公司安排。
小团队可能让一个人维护流水线、基础设施和线上服务。规模扩大后，平台团队提供部署能力，业务研发维护应用，SRE 参与可靠性治理。这样的分工只是可能的组织方式，没有一张通用的职位表能覆盖所有公司。
同一段工作经历，在不同公司可能得到不同名称。工具清单只能说明使用过什么，还需要追问：为什么使用，以及对什么结果负责。
从一次发布看 DevOps 的协作与反馈
下面用一个查询服务举例。场景用于解释概念，不代表我的项目实测。
开发完成代码，运维接到上线任务，却发现环境变量缺失。补完配置，又发现数据库变更没有安排。上线失败后，开发认为测试环境正常，运维认为交付包有问题。
问题出在多个交接点：配置没有完整记录，发布条件没有共同确认，生产反馈也没有进入开发流程。
改善这件事，可以把测试、镜像构建、配置管理和部署串起来。开发与运维共同维护发布条件，并提前准备回滚步骤。上线后的错误、延迟和用户反馈，再进入下一轮修改。
沿图中的蓝色主线向下看，代码变更经过验证后进入生产；左侧回路把生产问题送回开发阶段。这个回路很关键：部署完成以后，团队还需要根据实际运行情况改进软件。
流水线能减少手工步骤，但责任问题也需要解决。如果生产告警永远只发给运维，应用缺陷却无人安排修复，自动化程度再高，协作仍然会停在交接处。
SRE 继续追问：用户是否得到可用的服务
现在，流水线显示部署成功，Pod 也都处于运行状态。但用户查询仍然可能超时，或者收到错误结果。
这时就需要把关注点移到服务质量：什么算一次正常查询？怎样发现质量下降？哪项工程改进最值得优先做？SRE 强调用软件工程方法处理这些运行问题，并为长期改进保留时间。Google：Introduction
CPU、内存和连接数有助于定位原因，但不能单独说明用户体验。CPU 很低，查询也可能因为下游超时而失败；CPU 很高，服务也可能仍在正常处理请求。
为了让可靠性可以讨论，需要三个相互关联的概念。
SLI：测量什么
SLI（Service Level Indicator）是服务水平指标，用来观察服务质量。对于查询服务，可以测量符合统计口径的请求中，有多少成功返回。如果业务对等待时间敏感，还可以单独定义延迟指标。
这里的"成功"要说清楚。仅仅返回 HTTP 200，是否就代表业务正确？网关统计能否覆盖到用户实际遇到的问题？指标需要结合服务语义和采集位置定义。
SLO：目标是多少
SLO（Service Level Objective）是服务水平目标。例如：在一个 30 天统计窗口内，至少 99.9% 的有效查询成功返回。
这是教学示例。选择目标时，需要结合业务需求、系统能力和维护成本。定义里还要明确有效请求范围、成功条件、统计窗口和数据来源。
错误预算：允许多少未达标结果
对于上面的成功率目标，允许的失败比例是 0.1%。假设窗口内有 100 万次有效请求，错误预算就是 1,000 次失败请求。
图中橙色条只表示这 1,000 次失败请求的预算。假设此前尚未消耗预算，一次故障造成 400 次失败，就消耗了预算的 40%，剩下 600 次。图里的比例是算术演示，不是线上监控数据。
注意，这里按请求数计算，不能直接换算成停机多少分钟。故障发生在高峰还是低谷、影响全部还是部分请求，都会改变失败请求数量。
错误预算帮助团队讨论变更风险和工程优先级。预算不足时，哪些变更需要暂停、哪些修复仍可继续，以及谁负责判断，都需要提前约定。SLO 和预算政策要得到相关团队认可，才能用于决策。Google：Implementing SLOs
同一条发布流水线，可以同时服务两个目标
回到查询服务。我们建设自动发布流程时，可以从两个角度检查它。
从交付角度看：配置能否追踪？各环境是否一致？发布步骤是否可重复？失败后能否恢复到上一版本？
从可靠性角度看：新版本是否让用户请求失败？旧实例退出时能否处理完现有请求？分批上线期间容量是否充足？回滚后服务质量是否真的恢复？
这两组问题会落到同一项实现上。例如，分批发布既让变更过程更可控，也提供了观察新版本质量的机会。回滚既是交付流程的一部分，也需要验证是否恢复了服务。
实际工作中，不能简单划成"DevOps 管发布，SRE 管稳定"。DevOps 同样关注可靠运行，SRE 也会改进发布机制。两者的区别更适合用关注重点解释，而不能据此把任务分成互不相交的两堆。
Terraform 也是如此。配置进入版本管理，可以减少环境差异；同一份配置也可能用于重建资源。但资源重建完成以后，数据、依赖和业务是否恢复，还需要验证。写过 Terraform，说明一项技能；承担并验证恢复结果，才说明相应责任。
自动化之后，还要看问题是否反复出现
生产工作难免包含值班和紧急处置。值得警惕的是，同一类操作每天重复，业务越大，需要的人越多。
Google 用 toil 描述一类手工、重复、可自动化、缺少长期价值，且往往随服务规模增长的运维工作。并非所有辛苦的工作都属于 toil：一次能长期改善告警质量的整理，也可能有明确的工程价值。Google：Eliminating Toil
假设一个服务每天需要重启，才能缓解连接池耗尽。紧急重启可以先恢复业务，后续则要确认连接是否泄漏、超时是否合理、资源是否正常释放。
加一个定时重启脚本，能够减少手工操作，但问题可能仍然存在。如果缺少保护条件，自动化还可能让多个实例同时退出。
评估改进时，可以记录三件事：问题是否减少，恢复过程是否更可靠，人工介入是否降低。脚本数量很容易统计，长期效果却需要持续观察。
多年运维经验，怎样说明更准确
对我这样的从业者，这个问题最终会落到自己的经历上。
以前的岗位可能叫运维、运维开发或 DevOps，实际工作已经包含监控、故障定位、资源优化和工具开发。这些都是有价值的经验。整理经历时，我会选一项真正负责的服务，说明问题、措施、负责范围和验证方式。
例如，"负责监控和告警"还可以继续展开：观察哪些用户请求？怎样减少无效告警？告警能否指向可执行的处理步骤？修复后用什么数据确认恢复？
如果没有运行过正式的 SLO 和错误预算政策，就写清已有的可靠性相关实践，以及需要补齐的部分。把职责讲具体，比用一个更热门的职位名称概括全部年限更准确。
看新岗位时，也可以问四件事：
- 负责什么结果？ 环境交付、工具平台、日常支持，还是指定服务的可靠性？
- 怎样验证结果？ 有哪些用户侧指标、目标和改进记录？
- 怎样分配时间？ 值班之外，是否有时间开发工具、修复长期问题？
- 能够推动什么修改？ 能否和研发一起改应用、调整架构、讨论变更风险？
如果想把现有运维工作向可靠性工程推进，可以先选一个服务，定义一个与用户体验有关的指标，记录一类反复出现的问题，再完成一项可验证的工程改进。范围可以小，但责任、数据和结果要说得清楚。
参考资料
- Google，《The Site Reliability Workbook》：How SRE Relates to DevOps
- Google，《Site Reliability Engineering》：Introduction
- Google，《The Site Reliability Workbook》：Implementing SLOs
- Google，《Site Reliability Engineering》：Eliminating Toil