前两天看了18年的DevOps现状报告，下面这张图给我的印象比较深，它展示了当前实施Devops的5种方式。其中SRE方式占比最少，但是组织希望实施SRE的意愿却最高，无论CXO层、管理层还是团队，都表现出了极高的兴趣。SRE究竟具有什么特质，让大家一边向往，一边又保持距离呢？

SRE，全称Site Reliability Engineering, 是google公司对运维工程师的称呼，也用来表示google的运维方法论。SRE的核心目标是稳定（Reliability）。一般意义上的运维，类似于系统管理，以人工操作（operation）为主，但google改变了这种理念，以软件工程（Engineering）的方法来做运维，通过创造系统来维护系统运行以替代传统的人工操作。

对于开头提出的问题，我觉得大概有3点因素： ####1. google效应 google自带明星光环，只要是google出品的，总会引起人们的效仿。另外，google分布全球的服务器集群，每天需要支撑几十亿的访问。负责维护这么庞大集群的SRE团队，是如何运作的，自然很受大家的关注。

####2. 理念 系统需要人工参与的地方越多，它的稳定性就越差。SRE就是要尽量消除人工操作，特别是经常发生的，重复性的操作。google把这些操作称为琐事。关于琐事的介绍，可以参考我之前写的文章《减少琐事》。

SRE通过设计、构建自动化工具取代人工操作。传统运维团队的大小基本与所服务的产品负载呈线性同步增长。如果一个产品越成功，用户流量越大，就需要越多的人来重复进行同样的事。而成功的SRE，运维工作量保持在一定范围内，却能支持持续增长的业务规模。它们的关系如下图所示：

SRE代表了管理大型复杂服务的最佳实践，由一个简单的想法“我是一名软件工程师，这是我如何来应付重复劳动的方法”而生。

####3. 现状约束 谷歌SRE团队里有两类工程师。50%-60%是标准的软件工程师，其他40-50%基本满足软件工程师标准（具备85-99%的技能），同时具有一定程度的其他技术能力，比如，Unix系统内部细节、1-3层网络知识等。可以看出来，SRE对人员的要求是很高的，传统的运维人员大都没有开发软件工程的能力，有些甚至连linux、数据库都不是很熟悉。运维一般需要跨团队协作，针对不同的问题，由专门的团队来解决，这也是大多数公司采用的做法。

一般公司的项目，并没有google这么大的集群规模，shell脚本+现成的监控工具就能满足运维的需要，采用SRE有点大材小用的感觉。

####结束语： SRE涉及的内容很多，有技术上的，也有管理上的。本文只是涉及了点皮毛。SRE很多具体的策略，如拥抱风险、监控预警、紧急处理、on-call等等，还没来得及深入学习。感兴趣的朋友可以看看《谷歌运维解密》这本书，有时间大家一起探讨。