SRE 与传统运维的本质区别
概述 很多团队把 SRE 理解为"运维换个名字"——招几个会写脚本的人，改个 Title，就算转型了。这种认知忽略了一个根本事实：SRE 是一种工程方法论，不是一套工具链。Google 在 2003 年创建 SRE 职能时，核心理念就是"用软件工程方法解决运维问题"，这从根本上改变了运维的定位、工作方式和文化。 从组织定位、文化差异、工程化实践和度量体系四个维度，系统性地剖析 SRE 与传统运维的本质区别，并给出团队转型路径建议。 一、组织定位：工程师 vs 支撑角色 传统运维的定位困境 传统运维团队通常被定位为"支撑角色"——开发负责写代码，运维负责让代码跑起来。这种分工看似清晰，实则制造了一个致命的对立面： 开发追求"快"：快速上线、快速迭代，功能越多越好 运维追求"稳"：变更越少越好，最好什么都别动 这种目标冲突导致的结果是：开发把运维当作发布的障碍，运维把开发当作故障的根源。最终演变为一个"拉锯战"——开发提需求，运维挡需求，谁的话语权大谁说了算。 SRE 的定位：工程师 SRE 的根本定位是软件工程师，只是专注于"可靠性"这个领域。Google SRE Book 第一章就明确指出： “SRE is what happens when you ask a software engineer to design an operations team.” 来源：Google SRE Book - Introduction 这意味着 SRE 的工作方式是工程化的： 遇到重复劳动 → 写工具自动化 遇到故障 → 做根因分析并修复系统性问题 遇到容量问题 → 建模型、做预测 遇到流程瓶颈 → 优化流程，而非增加人力 具体对比 维度 传统运维 SRE 定位 支撑角色，被动响应 工程师，主动设计 工作内容 工单处理、手动变更、故障排查 系统设计、自动化、可靠性工程 成功标准 系统没出事 系统在 SLO 范围内，错误预算可控 与开发关系 对立面（快 vs 稳） 协作伙伴（共同对 SLO 负责） 二、文化差异：工程文化 vs 经验文化 错误预算 vs 人工兜底 传统运维文化中，“可用性"是一个模糊的概念——领导说"要 4 个 9”，运维就拼命堆冗余、加监控、人工值守。一旦出了事故，就增加人手和流程来"防止再犯"。...