SRE的组织架构

第一代SRE是2016年以前Google内部的团队的，至于他们内部的组织架构是怎么样的，我们其实都不大清楚，Google也从来没有披露过，只是靠着《SRE》这本书推测是一个单独的团队。

第二代SRE就是很多大型互联网公司根据Google书中提示的，建立了一个独立的SRE团队，一般这个团队是归属于运维团队中的。

但是在实际的运行中，有一些问题是需要解决的。比如很重要的一点就是SRE需要去推一些稳定性的事情，需要跟产品和开发团队进行沟通，毕竟做了稳定性的事情后，那产品的功能迭代的事情就要减少。而且也未必很多开发团队愿意干这个事情。因为很多所谓稳定性的事情大部分都是重要但不紧急的。

这个时候需要SRE团队跟产品和开发团队进行沟通和排期。

这个时候如果公司内部各个团队沟通工作做的比较好的情况下，这些事情还是比较好推进的，比如我之前在X信的时候，因为从CTO到底层研发同学都非常关注可用性和成本，同时SRE和运维同学的水平又得到大家广泛认同，这个时候就是容易推进各项事宜的进展。这些可用性项目也是写入到CTO和各个研发负责人的OKR中的。

但是如果公司内部各个团队本来就是各自独立的，比如我在X右的时候，各个研发负责人各自维持一摊事情，就算是CEO来管也未必听。那你说这个事情应该怎么推进了。在强力推进了几个事情后，发现了这些问题，很多事情只能私下跟人好好聊聊，聊通了之后再名义上走一遍流程。但是后面发现在老板的OKR上也很少有这些事情。

因此第二代SRE的团队的适用性就要首先确认下现有的组织架构和氛围。

另外一个就是要跟组织的规模大小要相匹配，见过很多公司刚开始都是由研发兼任的，等实在撑不下去了再去招个SRE来解决，但是这个时候你地基都已经这样了，只能一点点改的。而且单个SRE很多时候还需要承担可用性布道师的职责。

最后就是第三代的SRE团队。    

这个组织结构的大题含义就是还是有一个完整的SRE团队，这个是负责公司级别的统一的，但是每个SRE会专注到单个或者多个产品线中，跟产品和研发团队的其他工程师打成一片，这个就需要SRE leader需要给这些这些SRE同事输出很好的方法论。这里不光需要技术能力，首先最重要的是跟开发团队建立信任关系，这样一个是可以传授SRE相关的知识给其他工程师，帮助他们发展运维思维。另外一个是当碰到SLA阻力的时候可以更平缓的解决。

这个就跟很多测试团队的架构也是这样的，平时都在产品线那边干活，也会虚线汇报给产品研发负责人。

不过这里我们还是要理清哪些东西是各个业务线特有的情况，哪些是整个公司都要统一执行的。

比如一些基础平台，例如监控平台，CI/CD平台，报警平台这些可以统一起来。但是每个产品里使用的开发语言，数据库这些完全可以根据实际的来进行。