第2章 SRE在组织内部的定位

在开始落地SRE之前，运维的工作模式一直是一个大型的垂直分化的团队模式。直白一点说，团队内部很多人不自觉地将自己看作一个工单的执行者，每天的工作就是执行各种业务的需求。日常工作中最常见的任务处理流程是这样的：A业务的开发工程师有一个需求，他可以直接通过IM联系到一个运维工程师，沟通完之后运维工程师就帮开发工程师处理这个需求。

因为很多开发工程师平时很少和运维工程师打交道，所以开发工程师逮到一个隶属运维团队的人就开始提需求。这会发生什么情况呢？如果开发工程师想调整一个系统参数，但他不知道找谁，那么他就可能直接找到了数据库管理员。数据库管理员可能会说这个部分不是他负责的，让开发工程师去找应用运维工程师。如果开发工程师找到应用运维师后能解决这个问题，那么算是幸运的，但更多的情况是应用运维工程师会和开发工程师说你需要开一个系统运维的工单。这种“踢皮球式”的流程对于开发工程师来说有时候简直就是灾难。

这种“踢皮球式”的流程很多时候会导致运维团队在整个组织内部不受开发工程师的欢迎，进而导致运维团队在内部推行一些运维规范的时候会遇到比较多的阻力。针对这种情况，整个运维团队开始转变思路。最直观的改变就是对原有系统运维工程师、数据库管理员、应用运维工程师的做事方式和工具进行调整，通过协调运维团队内部降低开发工程师找运维团队做事的难度。

举例来说，转变前业务工程师要申请一台服务器资源，通常会需要申请服务器、部署服务器、部署应用、发布上线等好几个步骤。每个步骤都有独立的工单流程，这些步骤分别对应系统运维、应用运维、数据库运维等工具。从团队的角度看，每个角色的工作方式都完成了自动化和流程化，但是从用户的角度看，为了上线一台服务器，还需要填写3～4个工单，真的太难了。于是我们思考将这些工具整合到一个任务工单里，简化用户的填写过程，改善整体的用户体验和任务执行效率。

有了一定的经验后，我们团队内部也开始尝试执行一些工作方式上的转变。例如，针对每个业务建立运维小组，将系统运维、应用运维、数据库运维的跟进人员组成独立的小组，小组内统一流程和意识，提升产品运维的效率。从某种意义上说，这样的转变初步有了SRE的形态。

成立面向业务的运维小组后，业务对系统运维、数据库运维、应用运维的需求会直接转接到各自业务的运维小组。运维小组成员在组织架构上虽然没有变化，但是承担的工作慢慢出现了细微的变化，工作范围不再以各自成员的原有角色进行区分，而是更讲究团队属性。这种细微的变化会很大程度体现在工作中，如团队成员中的系统运维工程师在接受一个数据库需求的时候，不会再将用户需求踢给数据库管理员，而是会以数据库运维工程师的角色直接和用户沟通，主动协调推动需求的解决落地。