肖德时：SRE是怎样炼成的

2017年2月7日，春节假日后的首个周三晚上8点30分，数人云的肖德时老师为大家带来了主题为“运维达尔文：SRE的自动化演进”的交流。肖德时老师，曾任Redhat Engineering Service部门内部工具组Leader，是国内第一代Docker代码贡献者，现负责数人云产品研发及架构设计工作。以下是主持人Jacty整理的交流实录，记录了肖老师与读者智慧沟通的精粹。

问：SRE是否只适合有大规模IT系统的企业？

答： 从本质上来说SRE主要关注提升IT的效率，而不关注IT规模。但是从国内外的实际情况来看，确实是IT规模比较大的企业才会考虑设置SRE岗位。这主要的原因在于SRE理念的实施有两个很现实的问题一个是人，一个是钱。

首先说人，前面我们已经提到对于SRE人员的技能要求是比较高的，他既要具有一定的开发能力又需要对系统管理知识有所掌握，不管是从外部招聘还是从自己的传统运维团队中培养都需要一定的人才储备和资金支持。一般而言IT规模比较大的企业整体规模也比较大，这种大企业相比小企业而言对于采用先进的运维理念会有更多的支持。但是这并不是说SRE只适合IT规模比较大的企业。整体而言SRE对提高企业IT系统的效率都是有所助益的，无论企业规模或者说IT规模的大小。

第二个方面就是钱的方面，想省钱，但是业务一多，就需要招人。怎么能解决这个瓶颈。就是需要走SRE的操作路线。

所以，SRE是通用型的理论思想，推荐任何需要服务支持的企业应用起来这种思想。

问：SRE和DevOps有什么区别？

答： 这个问题其实出现过很多次了，之所有此一问，必然是两者之间有很多共同点。确实，DevOps 和 SRE 都重视自动化，拒绝手工劳动，利用软件工程手段执行运维任务等等。我们可以认为DevOps是SRE核心理念的普适版，可以用于更广范围内的组织结构、管理结构和人员安排。SRE可以看做是DevOps模型在某种组织结构中的具体实践。DevOps 一般多指一个工作方式或者流程，DevOps 的定义中就包括 Dev 和 Ops 互相协作，识别并规避风险，总体来说还是比较抽象。虽然SRE也是一种方法一种体系，但是SRE有许多更具体的操作实践。比如在《SRE-Google运维解密》这本书中详细得介绍了监控报警、应急事件处理、变更管理、需求预测和容量规划以及资源部署等具体化方法和工具。

问：在企业内部践行SRE体系，除了启用自助化和自动化工具，是否意味着要增加SRE岗位？

答： 回答这个问题的时候我要先放一张图。

从这张图上可以看出SRE成功的标志是业务快速增长，但运维事务并不随着业务增长的速度而增长。所以我们引入SRE理念，不是要增加运维团队的规模，反而是要提高运维的效率，保持运维团队规模不随业务规模的增长而同比增长。所以如果仅仅是在原有运维团队的基础上增设SRE岗反而扩大了运维团队的规模，这与SRE的初衷是不一致的。所以比较合理的做法是在启用自动化工具的同时，把部分的传统运维工程师升级为SRE工程师，这些工程师需要具备一定研发能力和具体的系统知识。

问：如果从技术上转型，是否程序员比纯运维更容易适合SRE工作？

答： 这个对两块人群都会有帮助。没有谁是最合适的。只是，这个岗位给年轻人新的机会。并且，他是和业务相关的，老板最关心的就是业务。所以SRE的工作回报率很高。对个人的技术能力的培养和成长都有一个清晰的规划。当你热血沸腾的去国内招聘网站找SRE的职位的时候，是找不到了。这个是因为国内的云计算发展水平限制导致的，大家不用担心。短期内，当一个开发或者运维没有关系，但是你的思想高度如果提高到SRE的理论高度，一定会受到同事和领导的认可。机会永远是留给有准备的员工。

问：自动化运维如何逐步开展起来？都有哪些事情要做？这些事情之间的依赖关系如何？自动化运维未来的方向在哪里？

答： 自动化运维是一个理想。应该没有最好，只有更好。运用SRE的理论，应该脚踏实地的专注在业务层面，定义SLO。然后在此基础上，再做容量规划，这个容量规划是对现有资源的规划，和水平扩展时指标的实时监控。这个是很难做到的任务。一定会花费你很多精力。然后在切入实际的问题点，总结经验，一次性的解决问题。这些事情在SRE的想法里，它是有固定的场景和解决方案的，这就是SRE十年磨练出来的体系化的内容。自动化运维应该是工具集的一种理论发展，但是和SRE对比起来，SRE十多年的发展已经非常成熟，应该更有价值。工具的自动化是没有尽头的，但针对业务保障的SRE还是一个不错的方向。我推荐大家关注和积累这方面的知识和方法论，在自动化运维未来发展过程中也会有一个主心骨来引导。

问：现在国外都有哪些公司有SRE岗位？

答： Google是最先设置SRE岗位的，其实也可以说是国外SRE的黄埔军校，很多国外公司的SRE其实都是从Google里面出来的。现在据我们所知的还有LindedIn， Twitter， Facebook、Pivotal、Bloomberg。

问：肖总提到用共享经济来在国内推广SRE，能否结合实际案例介绍下如何在中小企业中实施，对于企业的IT基础平台的业务系统是否有一些要求？

答： 举个实际例子：我们在卖的是一套数人云PaaS平台，同行也在卖一套PaaS，除了功能上的对比，实际上从一开始和客户接触，就会形成一个壁垒。客户的痛点解决不了，产品卖出去也非常累。所以，现在业界有一个B4B的模式，就是让客户和产品公司能坐在一起共同讨论客户自己的问题。说起来很容易，但是实际操作起来，我们确实面临过问题。在一家金融机构里面，最后还是对方在给我们疏导痛点。因为，传统企业的运维规章制度很严格，从SRE的角度来落地，对方不一定认可，因为规模小，用人就能顶住。最多是看到自动化的需求，买一个工具来自动化一下。但是从我们这些要坚持SRE理念的公司，也适度的和客户深入交流，帮助客户把具体的痛点问题梳理成有体系的模块。这样对客户来说，他们都是反馈很好。并且允许我们工具的不完善。按照之前闭门造车制作的产品，到客户那里就是定制。并且因为产品已经有一个方圆，你很难就场景下把工具做的更通用。所以，怎么能贴近客户，才能有机会就痛点问题找到工具的实现范围。

问：关于自动化演进的5个阶段，能结合实例做一些更详细的介绍么？

答： SRE思想上倾向于尽可能使用机器管理机器，但是实际情况需要一定的变通。将每个系统的每个组件都自动化是不合适的，同时不是所有人都有能力或者倾向于在一个特定的时间开发自动化系统。

自动化的演进遵循如下路径:

1. 没有自动化。

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

3. 外部维护的通用的自动化。

4. 内部维护的系统特定的自动化。

5. 不需要任何自动化(自主化)。

讲起来就是SRE讨厌手动操作，然而有时手动操作不可避免的。自动化的演进是一套方法论。

举个具体的例子，集群上线自动化进化遵循这样一个路径:

1. 操作人员触发手工操作(无自动化)。采用shell脚本通过ssh来应对繁琐的包分发和服务初始化问题。就是我们自己也存在这个案例。不是说懂的就全部上SRE了。实施起来，水平还在第一阶段。

2. 操作人员编写，系统特定的自动化。能够使用生产用测试脚本Prodtest检测不一致情况。这个的难度会高一点，基本开始往SRE的方向在跑了

3. 外部维护的通用自动化。幂等地解决不一致情况，增加自动修复程序。能实现这一步，基本达到国内顶级运维水平了。

4. 内部维护，系统特定的自动化。通过消除运维相关服务的团队维护和运行自动化代码的责任，创造新的组织激励机制，让最好用的工具由那些每天使用它们的人来写。改职责，上SRE的激励机制。让用的人来写运维工具。这个难度不在人，是文化和职责的再次明确。对个人还是公司都是一次成长。

5. 不需要人为干预的自治系统。由服务团队维护上线流程，每个团队按照合同(API)提供自动上线所需的自动化，不限制底层的实现细节。

基本第五层就是平台分层的运维方式了。SRE的角度也深入到最内核集群的调度。国内有过这样的场景，阿里，滴滴都有，但是也在发展中，大家还在一个积累阶段。

问：看评论有人提到，开发应该比运维更适合SRE岗位，和我想的，SRE的新人是往开发方向发展还是运维方向发展？若是开发方向那为何不直接先去开发岗位，然后再转为SRE？若是运维方向，那么从此开发能力就会很低了，早晚都得被SRE岗位淘汰？对此，肖老师怎么看？

答：首先SRE，最重要的是Engineering。用软件工程的方法论来解决业务问题。保障业务的持续发展。所以，不管是开发，还是运维，如果想个人发展，SRE是一个不错的方法。有了思想的武装，在具体的事情上，你会考虑更全面。不用担心淘汰的事情。所有事情不是有了思想就比别人先进了。而是掌握了SRE的思想，之后能实践起来。SRE10年的实践足以支撑你的发展方向没错。

问：SRE是否定位为系统运行阶段？还是产品的全生命周期？之前了解到谷歌的数据中心运维人员极少，是否和践行SRE有关？在国内的大环境下，一个中等规模的IT公司若要践行SRE，组织结构应当做何调整，绩效方面当如何评估？

答： SRE应该贯穿业务运行的所有阶段。不然没法有效的保障业务的平稳发展。可以按照不同的阶段划分SRE团队，但是就我们国内的现状，能把现有的人利用起来就已经很好了。

谷歌的数据中心SRE很少，是谷歌躺出来的科学的方法论。国外大量的公司不可能复制谷歌，但是在此方法论下实践已经得到很高的收益。不要把目光放在谷歌之上，因为谷歌的工具自动化程度已经非常高，这个阶段的SRE问题我们没法复制。在国内大环境下，从最实际的角度，是走DevOps路线。这个上到老板，下到基层，大家都知道。组织结构可以先从运维开始。但是解决问题的方式要有变化。从应用的全生命周期来全局考虑运维自动化。并且自动化的5个发展阶段也很好的解读了一个实际问题。大大小小的问题，必须深究下去，保证到最后能一次性解决。

我们一般的运维都是解决完问题，就完事了。不会深究。从软件工程角度，我们把具体问题写成报告，不断演练，自动化的幂等实现。如果没有一套合适的理论，我们是没法坚持下去做研发的。

问：初创或小型公司能否推行SRE，人员配比是否有要求？如果推行，是否有特别注意的地方？

答：小公司，一般就1个，要么开发要么运维。强推SRE，是霸王硬上弓。从合理的角度是，是把现在的问题列出来，从SRE的方法论，指定自己的发展路线。自然就对人员配比和推广SRE有了一个现实的可以做的事情。SRE是务实的，就是为了要解决业务问题。并且一次性把问题想的很深。通过实践不断提出更深的解决办法。特别注意的是，SRE不是一个简单的岗位，而是给出了一个建议。从我们实际的实践中，运维在推行SRE的时候想不通，为什么要这么干。但是当大家一起讨论的时候，就会发现这里的难度。个人的水平达不到。正好激励人员提升。人很重要，但是方法论就是一盏明灯，给我们走下去指明方向。并且，SRE是解决具体问题，不是搞一些心得来分享。那个没有意义。大家要解决的是业务的真正可持续的发展。所以SRE的理论和实践方法是需要小公司的人员重视起来，把实际的事情做好。而不是看重谷歌的名头，那就费了。

问：SRE在设计、开发阶段有投入么？投入的内容是什么？对系统的第三方开发者或者自己的开发团队提供服务或者工具么？

答： SRE要解决的是实际业务问题。要解决的是多方面的问题。在设计、开发阶段并没有实际的投入。而是在投产前交给SRE，SRE就完全接管了业务。真正的接管。并且对于开发这来说，需要的SLO，都会给明确的评估和监控。

对工具或者服务，是有的。原来是一波人开发，一波人使用。但是SRE是自己开发自己使用。完全是解决自己的问题。这个能力有点理想化。但是从SRE的实践中，大量的例子告诉大家，这个是收益最大的。所以才有了运维自动化的5个阶段。要慢慢来。

问：不太理解为什么SRE需要掌握 “算法，数据结构，编程能力...”这类技能。

答： SRE按照约定，50%时间用于开发。所以这些开发常用的技能是需要的。但是这个是理想。国内阿里保障部，用一堆人来建立起SRE团队，也是很好的实践。总体上也保障了淘宝的业务发展对不对。所以技能是一种诉求，不是完全前提。从实际业务出发，能深入研究问题，解决问题的方法和技巧就是SRE的产出。

问：感觉自动化运维会不会与开发形成竞争 这个职业到一定热度后，开发会进入这个行业抢饭碗。

答：现在就是在互相抢饭碗。单纯的开发和运维都是比较枯燥的职业。并不是所有的开发能有机会能开发自己喜欢的工具或者产品。所以运维要提升自己，就会去走业务保障的路数。开发要提升自己，也会有大量的人员会走这条路。这个在国内是必经之路。

所以，从担心自己的饭碗，到强调运维的重要性，怎么体现出来。需要一个高度。不是简简单单的说运维会开发了，就牛了。开发会运维了，就革掉运维的命了。这个我不太认同。而是从业务出发，真正的去思考业务问题，把自己的工作自动化思想高度提高，大家看的境界就不一样了。一切以业务出发，深度的去解决问题的能力，是需要磨练和时间的沉淀的。绝不是今天我们大家讲讲SRE就能升级。

（以上内容转自GitChat，版权归GitChat所有，转载请联系GitChat，微信号：GitChat，原文：《肖德时：SRE是怎样炼成的》）