WHY SRE != OP？

任何一个服务只有符合SRE的标准才会由SRE接手，由SRE承担oncall以及其它的运维相关工作。研发只需要关注业务的需求。

一个服务若要符合SRE的标准，需要改造的点可能有上百个，如果真的能按标准改造后，就是一个非常稳定、成熟的服务，交给SRE后，SRE几乎没有运维成本。

对比google的SRE招聘标准（SRE前提是一个资深的研发工程师），国内的运维都是校招菜鸟，只能称作operations boy，没有能力和经验制定运维准入标准，现有的运维准入标准都是一群无资深研发经验的"传统"运维工程师制定。按照这样的标准，接手服务后，简直是噩梦，运维的服务经常出故障，运维工程师焦头烂额。稳定性工作由几个运维工程师去push研发改进，但是研发会认为稳定性的工作是运维的KPI，他只关注业务升级。维稳无法做大手术，运维只能依靠自己可怜的一点点业务理解，去改进业务。但治标不治本，陷入恶性循环。

更何况新人遵守准入标准都无法保证就接手了。呵呵呵。