2017 年 2 月 7 日晚上 8 点 30 分，数人云CTO 肖德时为大家带来了主题为“运维达尔文： SRE 的自动化演进”的交流。
本文转自 GitChat 的交流实录，由主持人 Jacty 整理。
答： 这个问题其实出现过很多次，之所有此一问，必然是两者之间有很多共同点。确实， DevOps 和 SRE 都重视自动化，拒绝手工劳动，利用软件工程手段执行运维任务等等。我们可以认为 DevOps 是 SRE 核心理念的普适版，可以用于更广范围内的组织结构、管理结构和人员安排， SRE 可以看做是 DevOps 模型在某种组织结构中的具体实践。 DevOps 一般多指一个工作方式或者流程， DevOps 的定义中就包括 Dev 和 Ops 互相协作，识别并规避风险，总体来说还是比较抽象。虽然 SRE 也是一种方法一种体系，但是 SRE 有许多更具体的操作实践。比如在《 SRE-Google 运维解密》这本书中详细地介绍了监控报警、应急事件处理、变更管理、需求预测和容量规划以及资源部署等具体化方法和工具。
答： SRE 思想上倾向于尽可能使用机器管理机器，但是实际情况需要一定的变通。将每个系统的每个组件都自动化是不合适的，同时不是所有人都有能力或者倾向于在一个特定的时间开发自动化系统。
自动化的演进遵循如下路径:
没有自动化。 外部维护的系统特定的自动化。 外部维护的通用的自动化。 内部维护的系统特定的自动化。 不需要任何自动化(自主化)。 讲起来就是 SRE 讨厌手动操作，然而有时手动操作不可避免的。自动化的演进是一套方法论。
举个具体的例子，集群上线自动化进化遵循这样一个路径:
操作人员触发手工操作(无自动化)，采用 shell 脚本通过 ssh 来应对繁琐的包分发和服务初始化问题。我们自己也存在这个案例，不是说懂就全部上 SRE ，实施起来，水平仍在第一阶段。
操作人员编写，系统特定的自动化，能够使用生产用测试脚本 Prodtest 检测不一致情况。这个的难度会高一点，基本开始往 SRE 的方向在跑了
外部维护的通用自动化，幂等地解决不一致情况，增加自动修复程序。能实现这一步，基本达到国内顶级运维水平了。
内部维护，系统特定的自动化。通过消除运维相关服务的团队维护和运行自动化代码的责任，创造新的组织激励机制，让最好用的工具由那些每天使用它们的人来写。改职责，上 SRE 的激励机制，让用的人来写运维工具。这个难度不在人，是文化和职责的再次明确，对个人还是公司都是一次成长。
不需要人为干预的自治系统。由服务团队维护上线流程，每个团队按照合同(API)提供自动上线所需的自动化，不限制底层的实现细节。
基本第五层就是平台分层的运维方式了， SRE 的角度也深入到最内核集群的调度。国内有过这样的场景，阿里，滴滴都有，但是也在发展中，大家还在一个积累阶段。
答： SRE 要解决的是实际业务多方面的问题，在设计、开发阶段并没有实际的投入。而是在投产前交给 SRE ， SRE 就完全接管了业务。且对于开发来说，需要的 SLO ，都会给予明确的评估和监控。
对工具或者服务，是有投入的。原来是一波人开发，一波人使用。但是 SRE 是自己开发自己使用，完全解决自己的问题。这个能力有点理想化，但是从 SRE 的实践中，大量的例子告诉大家，这个是收益最大的，所以才有了运维自动化的 5 个阶段。
答： SRE 按照约定， 50%时间用于开发。所以这些开发常用的技能是需要的，但是这个是理想。国内阿里保障部，用一堆人来建立起 SRE 团队，也是很好的实践，总体上也保障了淘宝的业务发展。所以技能是一种诉求，不是完全前提。从实际业务出发，能深入研究问题，解决问题的方法和技巧就是 SRE 的产出。
答： 这个对两类人群都会有帮助，没有谁是最合适的。只是，这个岗位给年轻人新的机会，并且它是和业务相关的，老板最关心的就是业务，所以 SRE 的工作回报率很高。对个人的技术能力的培养和成长都有一个清晰的规划。当你热血沸腾的去国内招聘网站找 SRE 的职位的时候，是找不到的，这个是因为国内的云计算发展水平限制导致的，大家不用担心。短期内，当一个开发或者运维没有关系，但是你的思想高度如果提高到 SRE 的理论高度，一定会受到同事和领导的认可。机会永远是留给有准备的员工。
答： 自动化运维是一个理想，应该没有最好，只有更好。运用 SRE 的理论，应该脚踏实地的专注在业务层面，定义 SLO 。然后在此基础上，再做容量规划，这个容量规划是对现有资源的规划，和水平扩展时指标的实时监控。这个是很难做到的任务，一定会花费你很多精力。然后在切入实际的问题点，总结经验，一次性的解决问题。
这些事情在 SRE 的想法里，它是有固定的场景和解决方案的，这就是 SRE 十年磨练出来的体系化的内容。自动化运维应该是工具集的一种理论发展，但是和 SRE 对比起来， SRE 十多年的发展已经非常成熟，应该更有价值。工具的自动化是没有尽头的，但针对业务保障的 SRE 还是一个不错的方向。我推荐大家关注和积累这方面的知识和方法论，在自动化运维未来发展过程中也会有一个主心骨来引导。
答：现在就是在互相抢饭碗。单纯的开发和运维都是比较枯燥的职业，并不是所有的开发能有机会能开发自己喜欢的工具或者产品。所以运维要提升自己，就会去走业务保障的路数，开发要提升自己，也会有大量的人员会走这条路，这个在国内是必经之路。
从担心自己的饭碗，到强调运维的重要性，需要一个高度。不是简简单单的说运维会开发了，就牛了，开发会运维了，就革掉运维的命了。这个我不太认同，而是应从业务出发，真正的去思考业务问题，把自己的工作自动化思想高度提高，大家看的境界就不一样了。一切以业务出发，深度的去解决问题的能力，是需要磨练和时间的沉淀的，绝不是今天我们大家讲讲 SRE 就能升级。
答： SRE 最重要的是 Engineering ，用软件工程的方法论来解决业务问题，保障业务的持续发展。所以无论是开发，还是运维，如果想个人发展， SRE 是一个不错的方法。有了思想的武装，在具体的事情上，你会考虑更全面，不用担心淘汰的事情。所有事情不是有了思想就比别人先进了。掌握了 SRE 的思想，其 10 年的实践足以支撑你的发展方向没错。
答： 从本质上来说 SRE 主要关注提升 IT 的效率，而不关注 IT 规模。但是从国内外的实际情况来看，确实是 IT 规模比较大的企业才会考虑设置 SRE 岗位。这主要的原因在于 SRE 理念的实施有两个很现实的问题，人与钱。
首先说人，对于 SRE 人员的技能要求是比较高的，他既要具有一定的开发能力又需要对系统管理知识有所掌握，无论是从外部招聘还是从自己的传统运维团队中培养都需要一定的人才储备和资金支持。一般而言 IT 规模比较大的企业整体规模也比较大，这种大企业相比小企业而言对于采用先进的运维理念会有更多的支持。但是这并不是说 SRE 只适合 IT 规模比较大的企业。整体而言 SRE 对提高企业 IT 系统的效率都是有所助益的，无论企业规模或者说 IT 规模的大小。
第二个方面就是钱的方面，想省钱，但是业务一多，就需要招人。如何解决这个瓶颈。就是需要走 SRE 的操作路线。
所以， SRE 是通用型的理论思想，推荐任何需要服务支持的企业应用起来这种思想。
答： 回答这个问题的时候我要先放一张图。
从这张图上可以看出 SRE 成功的标志是业务快速增长，但运维事务并不随着业务增长的速度而增长。引入 SRE 理念，不是要增加运维团队的规模，而是要提高运维的效率，保持运维团队规模不随业务规模的增长而同比增长。如果仅仅是在原有运维团队的基础上增设 SRE 岗反而扩大了运维团队的规模，这与 SRE 的初衷是不一致的。比较合理的做法是在启用自动化工具的同时，把部分的传统运维工程师升级为 SRE 工程师，这些工程师需要具备一定研发能力和具体的系统知识。
答： Google 是最先设置 SRE 岗位的，其实也可以说是国外 SRE 的黄埔军校，很多国外公司的 SRE 其实都是从 Google 里面出来的。现在据我们所知的还有 LinkedIn ， Twitter ， Facebook 、 Pivotal 、 Bloomberg 。
答： 举个实际例子：我们在卖的是一套数人云 PaaS 平台，同行也在卖一套 PaaS ，除了功能上的对比，实际上从一开始和客户接触，就会形成一个壁垒。客户的痛点解决不了，产品卖出去也非常累。所以，现在业界有一个 B4B 的模式，就是让客户和产品公司能坐在一起共同讨论客户自己的问题。说起来很容易，但是实际操作起来，我们确实面临过问题。在一家金融机构里面，最后还是对方在给我们疏导痛点。因为传统企业的运维规章制度很严格，从 SRE 的角度来落地，对方不一定认可，因为规模小，用人就能顶住。最多是看到自动化的需求，买一个工具来自动化一下。但是从我们这些要坚持 SRE 理念的公司，也适度的和客户深入交流，帮助客户把具体的痛点问题梳理成有体系的模块。这样对客户来说，他们都是反馈很好，并且允许我们工具的不完善。按照之前闭门造车制作的产品，到客户那里就是定制。并且因为产品已经有一个方圆，你很难就场景下把工具做的更通用。所以贴近客户，才能有机会就痛点问题找到工具的实现范围。
答： SRE 应该贯穿业务运行的所有阶段，不然无法有效的保障业务的平稳发展。可以按照不同的阶段划分 SRE 团队，但是就我们国内的现状，能把现有的人利用起来就已经很好了。
谷歌的数据中心 SRE 很少，是谷歌实践出来的科学的方法论。国外大量的公司不可能复制谷歌，但是在此方法论下实践已经得到很高的收益。不要把目光放在谷歌之上，因为谷歌的工具自动化程度已经非常高，这个阶段的 SRE 问题我们没法复制。在国内大环境下，从最实际的角度，是走 DevOps 路线。这个上到老板，下到基层，大家都知道。组织结构可以先从运维开始，但是解决问题的方式要有变化，从应用的全生命周期来全局考虑运维自动化。并且自动化的 5 个发展阶段也很好的解读了一个实际问题，大大小小的问题，必须深究下去，保证到最后能一次性解决。
我们一般的运维都是解决完问题，就完事了，不会深究。从软件工程角度，我们把具体问题写成报告，不断演练，自动化的幂等实现。如果没有一套合适的理论，我们是没法坚持下去做研发的。
答：小公司，一般就 1 个，要么开发要么运维。强推 SRE ，是霸王硬上弓。从合理的角度是，是把现在的问题列出来，从 SRE 的方法论，指定自己的发展路线，自然就对人员配比和推广 SRE 有了一个现实的可以做的事情。 SRE 是务实的，就是为了要解决业务问题，并且一次性把问题想的很深，通过实践不断提出更深的解决办法。
特别注意的是， SRE 不是一个简单的岗位，而是给出了一个建议。从我们实际的实践中，运维在推行 SRE 的时候想不通，为什么要这么干。但是当大家一起讨论的时候，就会发现这里的难度，个人的水平达不到，正好激励人员提升。人很重要，但是方法论就是一盏明灯，给我们走下去指明方向。并且， SRE 是解决具体问题，不是搞一些心得来分享。那个没有意义，大家要解决的是业务的真正可持续的发展。所以 SRE 的理论和实践方法是需要小公司的人员重视起来，把实际的事情做好，而不是看重谷歌的名头，那就废了。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.