SRE 团队转型与业务接手实践指南

本文整理自书籍《SRE 原理与实践》"可靠性管理能力"，聚焦团队转型、新人培养、以及以 SRE 方式接手业务三大核心主题，帮助你理解如何从传统运维团队走向工程化的可靠性团队。

主要是和大家分享一下如何培养新人和新人如何学习的一些方法吧！

一、为什么要强调团队转型

专业的 SRE 团队职责及工作方法与传统运维团队有较大不同。SRE 的使命是提升产品在线持续运行的可靠性/稳定性，很多以传统运维为主的团队都在寻求转型为 SRE 团队的方法。

团队转型包括几种类型：

• 培养原先做技术运维的成员转型为 SRE；
• 招聘新人从零开始培养为 SRE；
• 把运维团队整体转型为 SRE 团队，优化团队能力结构，培养和引入可靠性工作所需要的多个方向的工程师。

运维工程师与 SRE 的核心区别

传统运维工程师偏重运维操作，以满足业务需求为主；而 SRE 以保持和提升系统可靠性为主要职责。两者的岗位职责和工作目标大为不同：

SRE 会使用运维技术，但使用目的是加强可靠性，使用方法是用编程的方式，运维操作只是 SRE 日常工作的一部分。

从运维工程师转型为 SRE，既是互联网平台提升可靠性稳定性的要求，也是运维工程师职业发展的需要。平台、团队与个人都面临转型问题，而且必须是体系化的转型——运维工作会逐渐实现自动化，部分工作由产品研发工程师通过系统执行，部分工作交给可靠性工程师来执行，SRE 工程师应进行更多可靠性工程工作。

二、运维工程师如何转型为 SRE

1. 通过学习提升能力，找到发展方向

一个优秀的 SRE 需要具备多方面的能力，以及专业的系统运维技能。如果 SRE 同时具备软件开发能力、产品架构设计能力（初级阶段可以是理解架构的能力）、沟通协调能力、项目管理能力等，将非常有优势。

SRE 的能力模型应该是"一专多能"：

• 有自己的专业方向（如软件开发、基础设施、系统架构等）；
• 技术广度同样重要，只有这样才能熟练应用可靠性技术、专业能力和综合能力完成可靠性工作；
• 在专业方向深入耕耘的同时，在其他技术面也要达到一定广度和深度。

2. 从度量所负责业务的可靠性开始

SRE 和业务方（包括产品、业务负责人、SRE 团队负责人）一起找到业务核心技术指标并进行度量，形成可靠性 SLO。通过 SLO 这个抓手：

1. 了解现状、分析风险、暴露问题；
2. 驱动产品研发、基础团队、SRE 团队一起改进；
3. 开展可靠性工程领域内的各项工程活动（提升感知能力、保障能力、快恢能力等）；
4. 把改进后的能力持续反馈出来，分析项目效果；
5. 持续分析新的业务现状和风险，逐步建立自己在业务质量和可靠性方面的权威性。

3. 对故障生命周期负责

SRE 要在故障的整个生命周期内积极主动推动各项可靠性工作，而不仅是参与处理故障。在过程中不断提升对故障发生、发现、定位、处理、总结、改进等环节的理解力和掌控力。

三、如何将新人培养为 SRE

成为 SRE 需要掌握系统性、累积型的学习方式，也需要有一套成长手册，而非向运维操作方向成长。

1. 团队与导师

SRE 团队的新人要在各业务运维组中轮训，在小组内安排一位导师负责试用期间的指导工作（一个新人配一位导师）。

2. 熟悉业务，学习知识和技术

新人进来首先要熟悉业务，了解业务使用的技术，与其他资深 SRE/产品研发工程师沟通，学习业务：

• 熟悉 CMDB、架构文档，了解用户请求是如何进入系统的；
• 从前端、中间、后端到数据库、存储，对整个架构进行反向工程；
• 自己整理文档——每个新人要为团队撰写新文档以及完善现有文档，不仅有利于传承知识，而且有利于激发新人的探索精神；
• 深入研究一个具体的问题，对架构、感知、脆弱性、快恢、保障能力中的某一方面研究透彻；
• 通过统计学、比较思维学会数据运营，学习监控技术，熟悉监控系统。

3. 系统性的培训

如果没有系统性的培训，新人会在混乱、庞大的信息量和无边的未知信息中惶恐工作，随时提心吊胆、不敢工作、工作效率低，经常找导师咨询问题，不仅成长速度慢，还会影响导师的工作。系统性培训包括以下几个方向：

(1) 学习监控

认识常见的监控指标，包括 SLI 监控、基础监控（系统、网络）、业务层监控（APM 上报、服务调用、服务日志）、DB/缓存监控。可安排日常基础监控的处理任务帮助新人加深理解。

学习常用的监控上报流程：监控程序 → 上报服务 → 存储 → 告警规则 → 展示 → 收取告警。目的是熟悉整体流程及每个组件的监控感知能力，了解如何发现异常。可安排任务：为系统增加一个指标监控、编写监控程序、取出数据告警判断、配置告警、发送并收取告警、在监控系统配置指标视图等。

(2) 了解发布变更

• 了解发布平台、变更系统的使用及发布流程，学习执行发布工作、检测发布结果；
• 学习服务的上下线流程（应用构建 → 流量摘除 → 发布 → 流量接入），学习弹性扩容组代码，熟悉弹性过程；
• 新人可在熟悉配置的基础上尝试做些变更（增加监控、增加运维系统新功能、增加小的自动化功能），待掌握后逐步扩展到独立完成升级、扩容等变更动作。

(3) 学习产研技术框架及基础设施与平台

• 学习框架的架构原理及日常的问题处理：了解生产的技术架构、高可用设计情况，以及出现问题时框架的处理方式。学习产研开发框架文档、处理框架常见问题、基于框架的故障定位和常规运维操作。
• 熟悉基础设施、基础软件：学习基础设施架构、机房 IDC 信息，熟悉公有云/私有云等云产品和云平台，熟悉运维资源管理、交付流程，学习常用中间件（负载均衡、缓存、队列等）。

(4) 学习稳定性保障体系

• 熟悉业务生产技术架构、部署架构、技术流程——清晰每个业务流程的流量路径（接入、流量路由、服务上下游转发等），熟悉每个服务当前的监控项与黄金指标的关系。
• 参与故障处理：阅读故障报告并做简单复盘，学习常规问题排查流程。分为 4 个阶段：导师讲解处理案例新人听 → 导师处理问题新人看 → 新人独立参与简单问题处理 → 高阶过程（故障处理分角色模拟演练、参与真实故障复盘、单独完成故障报告）。

4. 个人学习

工程师通过学习故障报告可以学习到如何理解系统、如何处理故障的知识。通过学习文档、熟悉集群部署、熟悉架构设计思路可以更好地理解系统如何工作，但这些都只是纸上谈兵；从实际故障中去调查分析系统为什么不能正常工作，是更有效的理解系统的方式。特别是对于新人来说，学习故障报告无疑是快速理解系统的途径，也能让新人快速进入业务稳定性保障角色和状态。

四、运维团队转型为 SRE 团队

可靠性工程工作表面看是保证业务可靠性、稳定性，一种更好的理解方式是集合各种技术能力，形成一种工程化的方式来保证业务持续稳定运行。目前很多公司的 SRE 团队还是以运维为主，包括业务运维/SRE、基础运维、数据库运维、监控团队等。

1. 团队结构

SRE 团队需要具备多方面的能力，一个人很难短期内拥有全部技能。SRE 团队要依靠团队的力量：

• 团队内要拥有掌握各种技能的工程师；
• 单个人搞不定的事情，发挥团队其他成员的力量；
• 单个团队搞不定的事情，跨团队协调资源搞定。

团队中应该有各方面的专家：管理人员、运维工程师、架构师、SRE 研发工程师、基础组件研发工程师、项目经理、AIOps、数据分析师等角色，并能在特定项目中吸收专业人士参与。

2. 在团队内部培养软件工程风气

大多传统运维团队习惯于手工解决一个个具体的运维问题——通过登录服务器执行运维操作来分析、排查、解决异常和故障问题。这种工作方式依赖于工程师个人技术经验，效率不高。

要培养软件工程风气：

• 鼓励可靠性工程师也具备软件设计开发的能力，把自己同时定位为软件工程师，通过软件工程化的方式解决运维问题；
• 鼓励把实践经验和操作方法通过软件编程形成工具或系统，做成通用型解决方案，解决可靠性相关的架构设计、感知观测、诊断定位、容量、快恢能力问题等；
• 团队要给 SRE/运维工程师留出时间来学习和参与工程开发工作，并提供指导；
• 《SRE：Google 运维解密》中讲到运维工作只能占 SRE 工作时间的50%，另外 50% 要用来开发工具、解决问题；
• 要求 SRE 必须参与工具开发，运维工具开发人员必须参与日常运维工作。

3. 建立应急协作的机制

要建立机制而不是靠运维工程师的个人经验和能力：

• 充分利用数据、度量和分配可靠性指标对稳定性进行度量，实时感知；
• 确定稳定性目标，主动感知发现和应对，而不是在收到用户投诉或告警时才被动处理；
• 机制应该明确各个岗位要求、能力要求，建立起流程体系。

4. 与研发深度协作、参与到系统架构设计中

• 强调稳定性是运维工程师与业务研发工程师的共同责任；
• 可靠性是设计出来的，很多问题属于架构设计问题，不应该由运维工程师靠人力来负责；
• 系统是共同建设的——业务研发团队负责上层系统，运维团队负责基础设施硬件、软件基础设施、基础服务、云服务等；
• SRE 应该和产品研发人员建立良好互动关系，如参与生产会议、共同承担可靠性工作目标、明确职责分工并共建可靠的系统。

5. 团队管理人员为团队找到可靠性的改进方向

SRE 有很多方向可以做，团队负责人要为团队指明方向：

• 确定可靠性的改进项目，取得成果并获得 SRE 团队各成员和业务产品研发人员的认可；
• 改进项目是提升系统可靠性的关键工程活动，也是 SRE 的主要工作；
• 可靠性工作方向是阶段性、经常变化的，每个季度每个业务的目标可能都在变化，所以需要团队管理人员有较强的判断能力和把控能力。

五、以 SRE 方式接手现有业务

接手一个现有业务的可靠性工作是经常出现的场景，如公司内部业务调整、SRE 工程师职责调整、入职新公司接触到的业务等。以下是用 SRE 方式接手业务的过程。

第 1 步：了解业务产品、人、背景信息

了解业务：以用户视角去了解业务，以开发者视角去了解网站/App 结构、系统结构，初步了解技术原理和流程。了解业务和服务的作用、解决了什么问题，了解业务在公司的重要程度以及目前的可用性。

了解人：跟研发负责人沟通，了解与业务相关的人（现有的 SRE/运维工程师、对应的研发团队、研发负责人、测试负责人、产品负责人、运营负责人等），建立沟通渠道，了解可靠性现状。

了解背景信息：业务在公司的商业价值、重要程度、老板重视程度。

分析可靠性目标：近期是否已经达标，或者有需要提升的目标。了解可靠性现状和业务期望，与产品研发负责人甚至业务负责人沟通，了解核心问题和对稳定性的期望。

第 2 步：熟悉业务架构

通过阅读文档、业务串讲等方式熟悉业务架构、技术架构：

• 获取架构设计文档、运维文档，初步了解服务应用架构、基础软件等；
• 请研发负责人概要介绍产品、业务架构和逻辑、部署方式、技术栈等；
• 根据架构文档和产研负责人的介绍，进行服务梳理，再回过头理解并消化业务架构、技术架构；
• 验证服务是否符合公司目前的标准部署和运维方式。

第 3 步：进一步熟悉部署架构，掌握运维资源

• 通过 CMDB、监控系统、管理后台等梳理现有的软硬件资源（主机、域名、数据库、缓存、云服务等）及其在运维管理系统中的情况；
• 对于运维系统化建设比较薄弱的公司，需要把所有主机、DB、应用等弄清楚，加好权限，自己整理一份列表或核对文档是否正确；
• 如果接维时已有 SRE/运维工程师，可请他们介绍目前的运维工作，了解生产服务现状、主要工作、压力来源，找到可能的导火索、风险点；
• 了解目前的紧急事件排序、紧急事件处理流程，甚至更细节的进程启动方式、监控方法、进程连接关系、部署架构等。

第 4 步：熟悉稳定性保障体系，尤其是现有监控

• 查看最近的故障报告、Bug 邮件、工单列表、事后总结等了解最近的故障及产生原因；
• 分析业务稳定性的现状（从故障次数、故障时长、严重程度、各方关注程度等方面），了解大家改进的动力和瓶颈所在；
• 查看与感知能力相关的监控告警的覆盖情况，以及过往故障处理过程中的监控表现情况。

第 5 步：处理当前问题

梳理业务当前问题，找出影响稳定性的主要问题。根据业务当前阶段（初创、发展、成熟、衰退等），制定不同的可靠性目标和工作策略。

第 6 步：推进改进

梳理改进事项，列出改进清单，排优先级，选取高价值、低成本的改进项优先落地，逐步推进。

六、以 SRE 方式接手新业务

对一个新业务来说，SRE 在早期介入会省事很多。如果有机会介入业务早期，SRE 可以从以下工作入手：

1. 参与组件选型

早期介入有利于推广统一的组件。SRE 对公司的基础设施、基础软件应该是非常清楚的，而很多产品研发人员关注面没有那么广。在使用组件时，建议优先使用公司内部统一的组件，或其他团队使用的较为成熟的组件，而非引入多个不同的组件。

2. 参与资源准备与部署架构的设计

• 在早期帮助业务准备基础资源，SRE 可以在项目早期完全熟悉基础资源，也可以在资源准备、采购、交付、部署等流程中进行把关，在早期预防一些可靠性风险；
• SRE 参与早期的部署架构设计，有利于尽早实现基础设施层的高可用和标准化；
• 在架构评审过程中，如果 SRE 具备架构能力，就能够参与、了解甚至评估业务架构中不合理的地方，在高可用、可靠性、安全性方面提出可靠性的要求，在早期规避风险。

七、本章小结

SRE 的使命是以工程化的方式保证和提升业务的可靠性。通过结合 SRE 的工作方法和工程能力，可以更高效地建设可靠性。

团队转型是基础——从运维操作驱动转向工程化驱动，从个人经验依赖转向机制体系保障；新人培养是传承——通过系统性的培训路径让新人快速进入角色；业务接手是实践——无论是现有业务还是新业务，SRE 都应该以度量驱动、工程化推进的方式开展工作。

核心一句话：可靠性是设计出来的，也是工程化建设出来的，不是靠人力堆出来的。