实录问答 | SRE 是如何炼成的

2017 年 2 月 7 日晚上 8 点 30 分，数人云CTO 肖德时为你们带来了主题为“运维达尔文： SRE 的自动化演进”的交流。

本文转自 GitChat 的交流实录，由主持人 Jacty 整理。

SRE 方法论

问： SRE 和 DevOps 有什么区别？

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

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

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

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

没有自动化。
外部维护的系统特定的自动化。
外部维护的通用的自动化。
内部维护的系统特定的自动化。
不须要任何自动化(自主化)。
讲起来就是 SRE 讨厌手动操做，然而有时手动操做不可避免的。自动化的演进是一套方法论。

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

操做人员触发手工操做(无自动化)，采用 shell 脚本经过 ssh 来应对繁琐的包分发和服务初始化问题。咱们本身也存在这个案例，不是说懂就所有上 SRE ，实施起来，水平仍在第一阶段。

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

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

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

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

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

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

答： SRE 要解决的是实际业务多方面的问题，在设计、开发阶段并无实际的投入。而是在投产前交给 SRE ， SRE 就彻底接管了业务。且对于开发来讲，须要的 SLO ，都会给予明确的评估和监控。

对工具或者服务，是有投入的。原来是一波人开发，一波人使用。可是 SRE 是本身开发本身使用，彻底解决本身的问题。这个能力有点理想化，可是从 SRE 的实践中，大量的例子告诉你们，这个是收益最大的，因此才有了运维自动化的 5 个阶段。

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

答： SRE 按照约定， 50%时间用于开发。因此这些开发经常使用的技能是须要的，可是这个是理想。国内阿里保障部，用一堆人来创建起 SRE 团队，也是很好的实践，整体上也保障了淘宝的业务发展。因此技能是一种诉求，不是彻底前提。从实际业务出发，能深刻研究问题，解决问题的方法和技巧就是 SRE 的产出。

SRE 中的开发与运维

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

答： 这个对两类人群都会有帮助，没有谁是最合适的。只是，这个岗位给年轻人新的机会，而且它是和业务相关的，老板最关心的就是业务，因此 SRE 的工做回报率很高。对我的的技术能力的培养和成长都有一个清晰的规划。当你热血沸腾的去国内招聘网站找 SRE 的职位的时候，是找不到的，这个是由于国内的云计算发展水平限制致使的，你们不用担忧。短时间内，当一个开发或者运维没有关系，可是你的思想高度若是提升到 SRE 的理论高度，必定会受到同事和领导的承认。机会永远是留给有准备的员工。

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

答： 自动化运维是一个理想，应该没有最好，只有更好。运用 SRE 的理论，应该脚踏实地的专一在业务层面，定义 SLO 。而后在此基础上，再作容量规划，这个容量规划是对现有资源的规划，和水平扩展时指标的实时监控。这个是很难作到的任务，必定会花费你不少精力。而后在切入实际的问题点，总结经验，一次性的解决问题。

这些事情在 SRE 的想法里，它是有固定的场景和解决方案的，这就是 SRE 十年磨练出来的体系化的内容。自动化运维应该是工具集的一种理论发展，可是和 SRE 对比起来， SRE 十多年的发展已经很是成熟，应该更有价值。工具的自动化是没有尽头的，但针对业务保障的 SRE 仍是一个不错的方向。我推荐你们关注和积累这方面的知识和方法论，在自动化运维将来发展过程当中也会有一个主心骨来引导。

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

答：如今就是在互相抢饭碗。单纯的开发和运维都是比较枯燥的职业，并非全部的开发能有机会能开发本身喜欢的工具或者产品。因此运维要提高本身，就会去走业务保障的路数，开发要提高本身，也会有大量的人员会走这条路，这个在国内是必经之路。

从担忧本身的饭碗，到强调运维的重要性，须要一个高度。不是简简单单的说运维会开发了，就牛了，开发会运维了，就革掉运维的命了。这个我不太认同，而是应从业务出发，真正的去思考业务问题，把本身的工做自动化思想高度提升，你们看的境界就不同了。一切以业务出发，深度的去解决问题的能力，是须要磨练和时间的沉淀的，毫不是今天咱们你们讲讲 SRE 就能升级。

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

答： SRE 最重要的是 Engineering ，用软件工程的方法论来解决业务问题，保障业务的持续发展。因此不管是开发，仍是运维，若是想我的发展， SRE 是一个不错的方法。有了思想的武装，在具体的事情上，你会考虑更全面，不用担忧淘汰的事情。全部事情不是有了思想就比别人先进了。掌握了 SRE 的思想，其 10 年的实践足以支撑你的发展方向没错。

SRE 与企业实践

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

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

首先说人，对于 SRE 人员的技能要求是比较高的，他既要具备必定的开发能力又须要对系统管理知识有所掌握，不管是从外部招聘仍是从本身的传统运维团队中培养都须要必定的人才储备和资金支持。通常而言 IT 规模比较大的企业总体规模也比较大，这种大企业相比小企业而言对于采用先进的运维理念会有更多的支持。可是这并非说 SRE 只适合 IT 规模比较大的企业。总体而言 SRE 对提升企业 IT 系统的效率都是有所助益的，不管企业规模或者说 IT 规模的大小。

第二个方面就是钱的方面，想省钱，可是业务一多，就须要招人。如何解决这个瓶颈。就是须要走 SRE 的操做路线。

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

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

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

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

问：如今国外都有哪些公司有 SRE 岗位？

答： Google 是最早设置 SRE 岗位的，其实也能够说是国外 SRE 的黄埔军校，不少国外公司的 SRE 其实都是从 Google 里面出来的。如今据咱们所知的还有 LinkedIn ， Twitter ， Facebook 、 Pivotal 、 Bloomberg 。

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

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

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

答： SRE 应该贯穿业务运行的全部阶段，否则没法有效的保障业务的平稳发展。能够按照不一样的阶段划分 SRE 团队，可是就咱们国内的现状，能把现有的人利用起来就已经很好了。

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

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

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

答：小公司，通常就 1 个，要么开发要么运维。强推 SRE ，是霸王硬上弓。从合理的角度是，是把如今的问题列出来，从 SRE 的方法论，指定本身的发展路线，天然就对人员配比和推广 SRE 有了一个现实的能够作的事情。 SRE 是务实的，就是为了要解决业务问题，而且一次性把问题想的很深，经过实践不断提出更深的解决办法。

特别注意的是， SRE 不是一个简单的岗位，而是给出了一个建议。从咱们实际的实践中，运维在推行 SRE 的时候想不通，为何要这么干。可是当你们一块儿讨论的时候，就会发现这里的难度，我的的水平达不到，正好激励人员提高。人很重要，可是方法论就是一盏明灯，给咱们走下去指明方向。而且， SRE 是解决具体问题，不是搞一些心得来分享。那个没有意义，你们要解决的是业务的真正可持续的发展。因此 SRE 的理论和实践方法是须要小公司的人员重视起来，把实际的事情作好，而不是看重谷歌的名头，那就废了。