运维界最远的距离，不是上线到宕机，而是我还在做系统管理员，你却到谷歌做了SRE。偷得半日闲，今天就作为一名资

深系统管理员老司机来谈谈为什么SRE那么风光，而我却如此苦逼。

一、企业变化，IT技术在传统业务中发挥影响力

对于传统企业中的IT运维来说，一个毋庸置疑的事实是他们作为成本中心的存在永远也说不清楚他们到底创造了多少价值，评估他们最有效的土办法就是建立SLA，服务级别协议。

SLA中最常用的指标是可用性，系统全年服务窗口内停机时间，在企业运维体系建立之初SLA确实发挥了很大的作用，其意在于保证业务系统稳定，而这些业务系统大多数服务于内部人员，更好的服务于内部人员，保证系统稳定性比什么都重要。

SLA的可用性要做到什么程度才是最好？99.9%，还是99.99%，抑或是99.999%？可以肯定的是在一个还比较原始的运维水平阶段，要计算好每一个系统的可用率也是件挺揪心的事（每个人心中都有一个哈姆雷特，在这里每一个团队都有自己的统计方法）。

当可用率达到一定程度后，其本身就没有太多意义了，比较重要的是业务实际影响，互联网看失败率，金融看损失金额，内部看是否影响了大boss。

很少有企业能够看到依据业务定SLA，而是继续逐年承诺更高的可用率，可悲的是可用率与其投入的成本并不是线性增长的，为了在小数点后多一个9，不得不下足功夫，投入巨额成本代价，同城多地多中心灾备，高度资源复合冗余，严格把控生产变更，在IT仍旧是成本中心的时期，这种SLA的紧箍咒下对企业产生的最大伤害莫过于成本过大。

对个人而言则是禁锢在严格的管控流程中，专业技能提升缓慢，如果企业比较壕，这也无所谓，而在人员方面，很大一部分企业逐渐转变为能力外包，坦白的说，在这种体系之下并不需要优秀的工程师，只需严密管控。一个企业运维外包人数与其运维技术专业水平成反比，请记住这句话。

随后互联网时代来临，科技公司逐渐抢占了各种C端，电商在细分领域抢占渠道，搜索把流量入口拦截，金融牌照放开随时可颠覆传统。有道是人有多大胆，地有多大产，运维领域此刻充斥着各种江湖术士，号称一个人管理一万台服务器的高人比比皆是，一时间多少传统企业傻白甜被忽悠也不在少数。

不管怎么样，这个时期的重点是传统企业开始重视IT，加大在IT建设上的投入，企业也逐渐通过互联网渠道直接面向C端，这个时期IT运维开始从原来的服务型角色，转变为：数据业务运营，关注用户体验，版本快速发布。

你会发现让书生气十足的IT人员用理工逻辑思维参与到业务数据运营中马上可以起到立竿见影的效果，而互联网终端的用户体验又直接关系着客户的转化率与留存，面对激烈的渠道竞争快速发版是王道。

系统管理员在周而复始的保证可用率，谷歌SRE则参与到了公司核心业务中，SLA依据业务分类定义，其提供平台来获取业务相关数据，提升用户体验。他们的差距在于一个是被动服务，一个是主动运营。

二、行业变化，云平台普及，去IOE呼声高涨

作为一名传统企业的运维老兵，不得不说对云平台IaaS的评价一开始并不高，回过头来看其实自己是犯了传统企业的老毛病，用可靠性这把尺子去衡量一个IaaS的具体实现，而没有高屋建瓴的看到云平台的运维行业发展趋势。

坦诚的说，现阶段的公有云较之一个优秀的企业运维团队而言，其稳定性确实要低些，但其行业发展趋势不在于那SLA的小数点后面的9，而在于对绝大多数小企业来说，他们可以立即获取到邮件、IM、ERP等SaaS服务，他们可以省去租用机柜、购买服务器、搭建操作系统的时间，直接使用IaaS服务，部署互联网应用。

是的，从这些中小企业的需求出发，你去用可靠性这把尺子衡量云平台就不那么合适了。很多运维同学问我云来了，我们会失业吗？我说，请记住，加菲猫说过：如果你打不败敌人，你就加入他。再具体一点说，对于企业内部的运维团队来说，你本身就是云。

中小企业的运维团队帮助企业入云，大企业的运维团队则要提供与云一样快速交付的服务，同时具备混合云的管理能力。系统管理员在手动的运维着一台台服务器，而聪明的SRE提供平台工具将选择权送回了用户手中。

全球运维界也看到了这个问题，于是产生了传统、互联网的双态运维模式，DevOps的敏捷运维方法等等，总之，评价当下运维团队优秀的标准在于，你能否比云平台更快速的提供服务，只要慢了，在互联网这一态而言，你就拖了后腿。

再回过头来谈去IOE，在国家安全等地缘政治话题背景下，去IOE在夹杂着民族主义的呼声中高涨，IOE可以去吗？当然可以了，关键是看你背负着多重的历史包袱，你拥有多少应用改造的资源，以及当下你真实的需求是什么。

系统管理员继续周而复始的划SAN，扫盘，挂Nas，而谷歌SRE倒逼应用软件改造，将存储放到了分布式x86上。如果我们无法像SRE一样驱动研发，至少我们可以将选择权交回到用户手上，软件定义存储还是有可能的，记住加菲猫那句话。

三、从系统管理员到谷歌SRE

好了，最后让我们回到谷歌SRE，我们如何走过那一段距离，对于小企业而言，很简单，帮助企业上云，记住重点：数据业务运营、关注用户体验、版本快速发布。对于大企业而言则有点尴尬，因为将传统企业的所有资源搬到云上成本不一定低，而数据安全以及稳定性需求在某些方面又无法满足。怎么办？

请在纸上画一个十字，从左到右是初级到高级，从下到上是技术、业务，然后将你日常工作内容填入到这四个区域，如果左边区域的工作占用了你绝大部分时间，很抱歉，你还在系统管理员中苦苦挣扎。典型的SRE活动分为：软件工程、系统工程、琐事、流程负担。

· 软件工程：编写代码、系统设计、文档工作，例如编写自动化脚本，创建工具框架、增加平台功能等，主要是运维开发方面工作。

· 系统工程：主要指运维相关的项目工作，平台级别的变更，专注在运维本身。例如设计负载均衡服务，并在项目里上线使用。

· 琐事：与运维服务相关的重复性、手工性劳动

· 流程负担：这是古今中外无差别的工作。

谷歌SRE用一种很委婉的方式提出了：拥抱风险，辨识风险容忍度，实际上就是帮助大家从SLA的怪圈走出来，再多的小数点后的9已经没有太大价值了，守住底线，腾出一只手，消除左边区域的初级琐事，重点投入到右边区域的事项中，成为业务推手、技术专家。

减少琐事，构建自动化是SRE开出的另一个妙方，首先来谈琐事，什么是琐事，但凡满足下列一个或多个属性的亦即琐事，手动性、重复性、可被自动化的为琐事，与服务器同步线性增长的事项也是琐事，这个标准非常得体，如果在工作中所涉及的任务与服务的大小、流量或者用户数量呈线性增长关系，那么这项任务可能属于琐事。

与SRE有所出入的是，我不认为performance测试属于琐事，做好性能测试，记录好各项指标，对以后的需求评估有很大帮助，另外troubleshooting事件处理如果在各种高尖深的平台技术支持下（如日志分析平台、逆向工程技术等）也是一件比较有意思的事情。按全年或者数个季度来说，SRE需要花费至少50%的时间在工程工作中，确保长期关注研发工作。这就是他们能够从琐事中脱身的法宝。

关于构建自动化平台，SRE给出了经验之谈，只有负责运维该组件的团队才是组件自动化的责任人，与组件的使用方没有关系，也不需要第三方来介入它的自动化，若非如此，没有谁会关注自动化的可用性，并且运维参数的变化，会让自动化久而久之失效。

这一点正是点睛一笔，多少自动化过程效果不佳的原因不过如此啊。简而言之，系统团队负责系统的自动化，网络团队负责网络的自动化，为了让这些自动化服务得到编排，他们对外发布服务接口，让其他团队调用。

再进一步说了下服务设计的原则，这些自动化服务是可重入的,同一个原子操作多次调用不会产生破坏，做到事前检查、事后验证，并且这些脚本都需要纳入到专门的版本控制器中。

除了自动化服务的重要原则，其概述了服务的演进过程：

1.没有自动化的手动操作

2.外部维护的特定系统的自动化脚本

3. 外部维护的通用的系统自动化脚本

4 内部运维的系统自动化脚本

5 纳入到平台，无需人工触发的系统

SRE通过自动化逐渐将琐事消除，之后将越来越多的时间投入到工程项目中，例如他们的Borg调度平台、borgmon监控平台等等，同时面对运维无法避免的On Call事项（突发事件、监控巡检），他们具备更好的工具支持，以及拥有更多的时间提升自己的专业技能。

最后一点，古往今来无差异的流程负担哪儿都有，他们也需要输出报告。好了，希望本文能够给运维圈内朋友一点启示，早日像萧帮主一样走在Google Charleston 大道上愉快的玩耍。

运维界最远的距离，不是上线到宕机，而是我还在做系统管理员，你却到谷歌做了SRE。偷得半日闲，今天就作为一名资

深系统管理员老司机来谈谈为什么SRE那么风光，而我却如此苦逼。

一、企业变化，IT技术在传统业务中发挥影响力

对于传统企业中的IT运维来说，一个毋庸置疑的事实是他们作为成本中心的存在永远也说不清楚他们到底创造了多少价值，评估他们最有效的土办法就是建立SLA，服务级别协议。

SLA中最常用的指标是可用性，系统全年服务窗口内停机时间，在企业运维体系建立之初SLA确实发挥了很大的作用，其意在于保证业务系统稳定，而这些业务系统大多数服务于内部人员，更好的服务于内部人员，保证系统稳定性比什么都重要。

SLA的可用性要做到什么程度才是最好？99.9%，还是99.99%，抑或是99.999%？可以肯定的是在一个还比较原始的运维水平阶段，要计算好每一个系统的可用率也是件挺揪心的事（每个人心中都有一个哈姆雷特，在这里每一个团队都有自己的统计方法）。

当可用率达到一定程度后，其本身就没有太多意义了，比较重要的是业务实际影响，互联网看失败率，金融看损失金额，内部看是否影响了大boss。

很少有企业能够看到依据业务定SLA，而是继续逐年承诺更高的可用率，可悲的是可用率与其投入的成本并不是线性增长的，为了在小数点后多一个9，不得不下足功夫，投入巨额成本代价，同城多地多中心灾备，高度资源复合冗余，严格把控生产变更，在IT仍旧是成本中心的时期，这种SLA的紧箍咒下对企业产生的最大伤害莫过于成本过大。

对个人而言则是禁锢在严格的管控流程中，专业技能提升缓慢，如果企业比较壕，这也无所谓，而在人员方面，很大一部分企业逐渐转变为能力外包，坦白的说，在这种体系之下并不需要优秀的工程师，只需严密管控。一个企业运维外包人数与其运维技术专业水平成反比，请记住这句话。

随后互联网时代来临，科技公司逐渐抢占了各种C端，电商在细分领域抢占渠道，搜索把流量入口拦截，金融牌照放开随时可颠覆传统。有道是人有多大胆，地有多大产，运维领域此刻充斥着各种江湖术士，号称一个人管理一万台服务器的高人比比皆是，一时间多少传统企业傻白甜被忽悠也不在少数。

不管怎么样，这个时期的重点是传统企业开始重视IT，加大在IT建设上的投入，企业也逐渐通过互联网渠道直接面向C端，这个时期IT运维开始从原来的服务型角色，转变为：数据业务运营，关注用户体验，版本快速发布。

你会发现让书生气十足的IT人员用理工逻辑思维参与到业务数据运营中马上可以起到立竿见影的效果，而互联网终端的用户体验又直接关系着客户的转化率与留存，面对激烈的渠道竞争快速发版是王道。

系统管理员在周而复始的保证可用率，谷歌SRE则参与到了公司核心业务中，SLA依据业务分类定义，其提供平台来获取业务相关数据，提升用户体验。他们的差距在于一个是被动服务，一个是主动运营。

二、行业变化，云平台普及，去IOE呼声高涨

作为一名传统企业的运维老兵，不得不说对云平台IaaS的评价一开始并不高，回过头来看其实自己是犯了传统企业的老毛病，用可靠性这把尺子去衡量一个IaaS的具体实现，而没有高屋建瓴的看到云平台的运维行业发展趋势。

坦诚的说，现阶段的公有云较之一个优秀的企业运维团队而言，其稳定性确实要低些，但其行业发展趋势不在于那SLA的小数点后面的9，而在于对绝大多数小企业来说，他们可以立即获取到邮件、IM、ERP等SaaS服务，他们可以省去租用机柜、购买服务器、搭建操作系统的时间，直接使用IaaS服务，部署互联网应用。

是的，从这些中小企业的需求出发，你去用可靠性这把尺子衡量云平台就不那么合适了。很多运维同学问我云来了，我们会失业吗？我说，请记住，加菲猫说过：如果你打不败敌人，你就加入他。再具体一点说，对于企业内部的运维团队来说，你本身就是云。

中小企业的运维团队帮助企业入云，大企业的运维团队则要提供与云一样快速交付的服务，同时具备混合云的管理能力。系统管理员在手动的运维着一台台服务器，而聪明的SRE提供平台工具将选择权送回了用户手中。

全球运维界也看到了这个问题，于是产生了传统、互联网的双态运维模式，DevOps的敏捷运维方法等等，总之，评价当下运维团队优秀的标准在于，你能否比云平台更快速的提供服务，只要慢了，在互联网这一态而言，你就拖了后腿。

再回过头来谈去IOE，在国家安全等地缘政治话题背景下，去IOE在夹杂着民族主义的呼声中高涨，IOE可以去吗？当然可以了，关键是看你背负着多重的历史包袱，你拥有多少应用改造的资源，以及当下你真实的需求是什么。

系统管理员继续周而复始的划SAN，扫盘，挂Nas，而谷歌SRE倒逼应用软件改造，将存储放到了分布式x86上。如果我们无法像SRE一样驱动研发，至少我们可以将选择权交回到用户手上，软件定义存储还是有可能的，记住加菲猫那句话。

三、从系统管理员到谷歌SRE

好了，最后让我们回到谷歌SRE，我们如何走过那一段距离，对于小企业而言，很简单，帮助企业上云，记住重点：数据业务运营、关注用户体验、版本快速发布。对于大企业而言则有点尴尬，因为将传统企业的所有资源搬到云上成本不一定低，而数据安全以及稳定性需求在某些方面又无法满足。怎么办？

请在纸上画一个十字，从左到右是初级到高级，从下到上是技术、业务，然后将你日常工作内容填入到这四个区域，如果左边区域的工作占用了你绝大部分时间，很抱歉，你还在系统管理员中苦苦挣扎。典型的SRE活动分为：软件工程、系统工程、琐事、流程负担。

· 软件工程：编写代码、系统设计、文档工作，例如编写自动化脚本，创建工具框架、增加平台功能等，主要是运维开发方面工作。

· 系统工程：主要指运维相关的项目工作，平台级别的变更，专注在运维本身。例如设计负载均衡服务，并在项目里上线使用。

· 琐事：与运维服务相关的重复性、手工性劳动

· 流程负担：这是古今中外无差别的工作。

谷歌SRE用一种很委婉的方式提出了：拥抱风险，辨识风险容忍度，实际上就是帮助大家从SLA的怪圈走出来，再多的小数点后的9已经没有太大价值了，守住底线，腾出一只手，消除左边区域的初级琐事，重点投入到右边区域的事项中，成为业务推手、技术专家。

减少琐事，构建自动化是SRE开出的另一个妙方，首先来谈琐事，什么是琐事，但凡满足下列一个或多个属性的亦即琐事，手动性、重复性、可被自动化的为琐事，与服务器同步线性增长的事项也是琐事，这个标准非常得体，如果在工作中所涉及的任务与服务的大小、流量或者用户数量呈线性增长关系，那么这项任务可能属于琐事。

与SRE有所出入的是，我不认为performance测试属于琐事，做好性能测试，记录好各项指标，对以后的需求评估有很大帮助，另外troubleshooting事件处理如果在各种高尖深的平台技术支持下（如日志分析平台、逆向工程技术等）也是一件比较有意思的事情。按全年或者数个季度来说，SRE需要花费至少50%的时间在工程工作中，确保长期关注研发工作。这就是他们能够从琐事中脱身的法宝。

关于构建自动化平台，SRE给出了经验之谈，只有负责运维该组件的团队才是组件自动化的责任人，与组件的使用方没有关系，也不需要第三方来介入它的自动化，若非如此，没有谁会关注自动化的可用性，并且运维参数的变化，会让自动化久而久之失效。

这一点正是点睛一笔，多少自动化过程效果不佳的原因不过如此啊。简而言之，系统团队负责系统的自动化，网络团队负责网络的自动化，为了让这些自动化服务得到编排，他们对外发布服务接口，让其他团队调用。

再进一步说了下服务设计的原则，这些自动化服务是可重入的,同一个原子操作多次调用不会产生破坏，做到事前检查、事后验证，并且这些脚本都需要纳入到专门的版本控制器中。

除了自动化服务的重要原则，其概述了服务的演进过程：

1.没有自动化的手动操作

2.外部维护的特定系统的自动化脚本

3. 外部维护的通用的系统自动化脚本

4 内部运维的系统自动化脚本

5 纳入到平台，无需人工触发的系统

SRE通过自动化逐渐将琐事消除，之后将越来越多的时间投入到工程项目中，例如他们的Borg调度平台、borgmon监控平台等等，同时面对运维无法避免的On Call事项（突发事件、监控巡检），他们具备更好的工具支持，以及拥有更多的时间提升自己的专业技能。

最后一点，古往今来无差异的流程负担哪儿都有，他们也需要输出报告。好了，希望本文能够给运维圈内朋友一点启示，早日像萧帮主一样走在Google Charleston 大道上愉快的玩耍。