1.1 为什么会引入SRE

计算机技术诞生之后，系统管理员这个职业也随之诞生。随着互联网的兴起、企业线上业务的不断分化和软件复杂度的提升，运维领域慢慢地引入了系统管理员（SA）、数据库管理员（DBA）和应用运维工程师（PE）等角色。这些角色的分工在互联网行业还是非常普遍的，也满足了很长一段时间内的业务运维需求，但是角色的精细化分工肯定还会带来新的问题。抛开外部技术演化，我们能看到以下问题。

（1）人员成本。

每个产品线都要配置系统管理员、数据库管理员、应用运维工程师等众多运维角色，而互联网业务的产品线随着业务的发展有时候是爆炸性的，这种情况导致了每开一条产品线都要配置一定的运维团队。在某种程度上这样的配置要求，会迫使业务团队优化自己的代码架构，减少对运维团队的依赖。

（2）运维任务细分。

我们常常可以看到这样一个场景，有一个需求要求运维，开发团队找系统管理员做事情，系统管理员一看是数据库管理员的需求，直接“踢球”给数据库管理员，数据库管理员跟进后发现这是一个需要系统管理员协助处理的需求，然后会再次找系统管理员。这个时候业务团队肯定会不满。另外就是因为角色分工很细，很多的需求处理过程都变成来回“踢皮球”的过程。这个过程不能说谁对谁错，但可以肯定的是这种情况是运维工作领域划分过细导致的。

（3）线上问题的跟进。

当前的业务模式已经不是以前的单个程序就能运作的模式了，当前的业务模式更注重的是业务体系化的系统运作，整个系统是复杂的，是远非一个人就能完全运维的。一般情况下，线上一旦出现问题后，需要投入整个运维团队。但是在投入整个运维团队的时候，因为角色细分，经常会出现各自处理各自的事情，最后汇总到运维领导层的问题。这种模式在当前分布式系统或云计算等场景下是非常低效和缺乏管理的。

SRE这个角色整合了运维的所有属性，因为SRE都是“多面手”，引入SRE有助于降低人员成本，同时简化业务和运维的交互过程，另外对线上问题的跟进也会因为SRE本身的属性变得更加及时和有效。总体来看，SRE的引入为运维领域带来的变化不只是称谓的变化，更多的是理念和纲领的变化。首先是运维团队的职业名称方面的理念变化，从职业名称上弱化了之前运维按照工作领域的细分，同时强化了运维这个职业的目标属性。

从软件领域的技术演化看，SRE的引入在某种意义上是必然的。

（1）云计算浪潮。

云计算带来了基础设施即服务（IaaS）和平台架构即服务（PaaS）的概念。云计算的应用对运维产生了巨大的冲击。首先是技能层面，很多原来需要专业运维团队才可以做的事情都被平台处理掉了，很多的运维技能，如使用Keepalived软件做HA和部署数据库主从等，因为云计算对相应功能的封装，已经不再需要运维团队操作。其次是需求层面，因为云计算简化了部署的复杂度，不需要运维团队考虑底层机架、服务器等硬件，所以对传统运维团队的需求大大降低。在一些场景下，更多的是开发团队自己执行一些运维需求。传统运维被开始逼着往结合业务的方向走。

（2）分布式/微服务/函数计算等新的软件架构。

微服务等概念从软件架构设计初始就考虑了运维的需求，很多以前应用运维和配置管理的运维需求也随之被软件本身集成。相比早期一个服务出现问题需要多个运维团队干预的情况，现在更多的服务都已经用分布式架构实现，具备容错、自愈等特性。如果是很久以前，线上业务出现问题，运维团队可能需要马上干预，这就变成了实际的运维人力需求，而现在这样的问题可能只要每周在特定的窗口统一处理一下就可以。从全局发展来看，传统运维团队卖体力的时代基本已经过去。

（3）服务器数量暴涨。

过去衡量一个运维团队的管理能力有一个很直接的指标，即单位人能维护多少台服务器。按照正常发展情况，单位人维护服务器的数量可能会随着技术增长而慢慢提升，但是互联网业务的快速增长直接导致了全球范围内的服务器数量不断增长。从内部感受来看，如果公司层面出现业务扩张，单个季度的服务器扩张量很可能是翻倍的，而运维团队的扩张不可能这么方便或没有上限。这个时候就会面临这样的一种情况：上个季度的团队人员是10个人管理1万台服务器，下个季度的团队人员还是10个人，但是需要管理的服务器会变成2万台。这种爆炸性的服务器扩张，要求传统运维团队不得不想办法将很多的运维操作沉淀成自动化的工具和脚本，来提升运维能力和效率，以满足业务扩张的需要。

（4）线上业务规模。

因为国内庞大的互联网用户基数，线上业务如果找对模式，就会快速膨胀。当一个业务规模复杂到一定程度的时候，会面临这样一种情况：单个开发团队本身只能聚焦部分业务功能的开发，对其他业务模块一无所知。从业务整体层面看，这意味着已经没有人能搞清楚所有的业务模块，对于业务调用体系只能越来越多地依赖Trace（链路调用）系统对业务架构做“画像”。因为每个开发团队只负责部分业务模块，在业务层面如果没有一个团队角色对业务系统做全局跟进，就会遇到大量稳定性相关的问题。

最终这4个方面的联合作用，让运维团队感受到了各个方面的压力，开始主动求新求变。新的技术让运维团队本身的很多技能慢慢地沉淀到了平台，运维团队已经不再需要机械的、低级的运维操作技能，业务团队也更多地要求运维团队去关注业务的稳定性或平台更底层的技术细节。