|
Gartner 2016 年应用开发成熟度曲线上，DevOps 已入顶峰。毫无疑问，DevOps 自 2009 年诞生以来，一路高歌猛进，目前已然成为软件行业的标准配置（最佳实践）。 甚至近两年的IT招聘中，DevOps 工程师已成为最火的岗位之一，而熟悉 DevOps 也成为研发人员或运维人员的技能要求。相应的，作为新兴技术概念繁荣的另一面，当我们谈论 DevOps 时，对其认识也呈现出多种多样的理解，并会按照自己的需要进行阐述：有的强调研发和运维流程改进，有的谈论自动化运维，有的试图建立起软件开发全生命周期管理；还有些甚至在 DevOps 的基础上进行更为超前的扩展，比如，就某些具体的领域探讨 NoOps 或者是围绕人工智能建立 AIOps，等等，真是乱花渐欲迷人眼。 今天，无论是作为互联网行业的参与者，还是传统IT企业的从业者，在这场 DevOps 运动浪潮中，我们要如何拨开重重迷雾来理解 DevOps，了解各种不同 DevOps 主张间的异同，从中选择适合自己的方式落地，并最终建立起高效的研发运维体系？ 另一方面，我们如何从 DevOps 的发展中理出隐藏在背后的动机和目标，从而在实践过程中能够超脱具体器用的限制，在面对未知问题时可以灵活的处理，甚而发展出自己的流程、系统和生态？…… 对这些问题的探讨正是本文目的之所在！但在开始我们的旅程前，我们需要先回答一个基本问题：DevOps 到底是什么? DevOps是什么？ DevOps (a clipped compound of “development” and “operations”) is a software engineering practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives. 如上是 wikipedia 上关于 DevOps 的最新描述【注1】，聊聊数语，似乎并不能让我们建立对 DevOps 的清晰认知，而且也不能一窥DevOps已发展出的庞大体系。 为了要理解现今的 DevOps，我们最好顺着历史长河逆流而上，不过有别于关注那些发生在2009年左右的故事【注2】，这次让我们先走的更远些，看看那敏捷诞生时的事情。 2000年左右，软件行业的主要工作是交付客户定制的软件应用，而软件研发团队被推荐使用像 CMM/CMMI、RUP 这样的大型方法论来组织生产 【注3】。 从事过大型交付项目的人应该对些方法论不陌生，抛开可能的操作差异——比如是瀑布还是迭代，它们有着一些共同的特征： 通过详细的流程规范软件开发的各个方面 大量细节工作前置以预防后期变更 将文档作为软件的产物和流程验证工具
这些大型方法论效果并不理想，一方面甲乙双方在需求变更上的扯皮不是影响交付日期就是交付后的产品不能真正解决客户的问题，另一方面研发团队又需要花费大量精力在准备流程需要的文档上面【注4】。 正因此，当时一些正在积极尝试不同方法的软件开发人员才会济济一堂，提出著名的《敏捷宣言》，如图1。 图1. 敏捷宣言 虽然敏捷宣言的提出者们委婉地肯定了一下右侧各项的价值，但我们依然能够从这些文字中体会出他们对大型方法论的不满——右侧各项都是与大型方法论紧密联系的实践。 可以这样说，敏捷方法的出现正是对大型方法论的反思和反抗。由于敏捷源自实践，在这个概念刚刚提出时，其对应的理论体系尚不完备，人们对其认知也并不统一，所以开始时，敏捷涵盖了与敏捷宣言相联系的多种方法论 【注5】。 这里，我们提及敏捷的原因在于几点： 第一，作为 DevOps 的提出者，敏捷的视角和方法直接影响了早期 DevOps，我们需要理清这样的影响在何处。 第二，DevOps 和敏捷，以及更早些的精益生产，都是先实践，再形成理论，最后又以理论指导实践。因此，了解了敏捷的诞生和发展过程，我们再看人们对 DevOps 概念认知的发展就不会感到困惑。 最后，DevOps 的产生和整个大环境的变化有着直接的关系，从敏捷到DevOps，我们通过梳理历史发展的脉络来从侧面了解催生 DevOps 背后的原因。 图2. 敏捷与DevOps时间线 如图2，敏捷提出后其关注过程和质量，而其要解决的问题则是如何快速交付客户需要的软件，或者我们更高大上地说，如何快速地交付价值！ 一开始，这里的交付有着相对狭窄的意义，也就是，它实际上指的是软件外包公司和软件需求方（甲方）之间的软件研发和制品交付工作。而后，随着敏捷在一般企业内部推广，其开始涵盖软件开发团队和业务团队之间的需求实现和软件交付关系。此时，整个软件的生命周期如图3，交付是开发的终点（或者在任何迭代中作为阶段性终点）。 由于此时多数是企业级应用开发，业务的稳定性和需求的演进速度尚不是问题，加之开发和运维在物理上的分离（通常分属于不同的公司），因此，研发和运维之间的矛盾并未凸显，需求频繁变更、研发效率低下才是甲乙双方头痛的问题。 图3. 传统软件生命周期 之后，如图4，在互联网高速发展的过程中，软件开发成为企业业务整体运营中的一环，开发团队阶段性交付软件后，并不能从总体上为业务立即带来任何价值，软件必须经过后续阶段，直到被部署到生产环境并真正带动业务运转起来后，整个软件研发工作才算交付了价值。 图4. 面向运营的软件生命周期 因此，在 DevOps 提出前，IT 行业中的主要问题不再仅仅是需求研发的问题，而且还有软件变更高质量、快速上线的问题。要让业务快速产生价值，降低从需求到软件上线的整体时间才是关键，如图5，加之互联网业务高速运转的要求，这个效率对企业生存是至关重要的。 但是，由于传统研发和运维定位的问题，即便在同一个企业中，由于工作性质和考核的方式的不同，研发和运维之间的部门墙对效率的提高有着很大阻碍（图6）。 此时即便研发可以通过敏捷高效起来，但糟糕的交付过程依然会将业务交付整体拉回到低效的瀑布方式（图6），甚至造成业务失败，而这正是促使咨询师 Patrick Debois 提出 DevOps 的关键所在。【注8】
图5. 原生 DevOps 定位 图6. 混乱之墙
图7. 糟糕的交付让敏捷回到瀑布 此时，让我们站在图1时间轴的2009年处，回看过去并眺望未来！向后看，敏捷已经有近10年的发展，围绕持续集成的实践已经比较成熟。但传统运维侧的部署和运维领域里的工具都尚待繁荣，而整个社区内只有为数不多的经验可以用来指导 DevOps 实践。如 Flickr 的《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》。 而向前看，2年后的2011年，《持续交付》这部重要的著作才会上市，业界和社区此时对持续交付尚缺统一的指导思想。4年后，探讨精益思想应用于开发运维工作中《凤凰项目》才出版。在这种情况下，作为擅长流程改进的敏捷方法论祭出沟通和协作的大旗就顺理成章了，而这也就反映在 DevOps 最初的图中，如图8。 另一方面，对文化的强调也得自于敏捷推广过程中的经验，自然地，这一部分也延续到了 DevOps上。可以这么说，早期 DevOps 就是敏捷通过开发向运维侧延伸，它直接继承了来自敏捷的诸多理念和实践，尤其是许多年来精益思想在软件行业的实践，这一次在拉通整个价值流的过程中得到了更大的应用舞台，如图9。
图8. 面向沟通与协作的DevOps
图9. 来自IBM的DevOps 总结一下，在 DevOps 提出时，面对的问题从定制软件的交付变成支撑业务的自研软件的部署和运营，敏捷轻车熟路地将利益相关各方拉到一起，希望在统一业务目标的前提下，通过沟通和协作来消除部门间的隔阂，提高整个流程的效率。 有别于敏捷方法在处理软件研发时所面对的情况，应用部署和运维是一个硬技术领域，其非常依赖工具和自动化，尤其是对于规模稍大的公司而言，源自持续集成的有关技术完全无法达到大规模 DevOps 预期的目标。 因此，沟通和协作带来的效率提升在运维相关的工作上很快会达到天花板，接下来，一系列自动化工具的繁荣将会推动 DevOps 走到新的高度，同时，这也让自动化运维成为 DevOps 的一种形态。 行文至此，让我们再次回到最开始的问题，“DevOps是什么？”。 与敏捷类似，DevOps 也没有标准定义，我们只能对 DevOps 进行描述，这种描述或者如我们之前所做，陈述其发生发展的过程——从这一点上看，DevOps 就是一个运动；或者是表述其预期的目标和作用的范围，如开始处引用的 wikipedia 的描述。 在诸多类似的描述中，来自《DevOps: A Software Architect’s Perspective》的描述更为简单直接——只要能够在保证质量的前提下缩短代码提交到上线时间的实践都是 DevOps：DevOps is s set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality. 当从目标和范围着手界定 DevOps 时，就会有所谓狭义 DevOps 和广义 DevOps 的区分。狭义 DevOps，如图5所示，就是原生 DevOps，它只关心从代码变更提交到变更部署到生产系统并运行起来，其目标在于缩短这个周期时间；而广义的 DevOps，如图10所示，它将整个软件生命周期纳入自己的范畴（即所谓的全生命周期管理），其目标在于提高整个业务的连续性。 此时，（广义）DevOps 与敏捷的关系就变得微妙，这成为常常讨论的主题，两者的范围似乎都可以包含对方。其实，（广义）DevOps 在具体工作层面上涵盖了敏捷管理和研发方法，但在整个理论基础上，敏捷思想（或精益）可以作为（广义）DevOps 的理论基础，用来指导整个软件研发的全生命周期中的活动。
图10. 广义DevOps和全生命周期管理 2013年，Gene Kim、Kevin Behr和George Spafford 出版了《凤凰项目 : 一个IT运维的传奇故事》，这本书是敏捷和精益思想指导 DevOps 工作的里程碑式的著作。下面让我们简单回顾一下这本书。《凤凰项目》这本书通过小说的形式，讲述了无极限公司运维部的比尔在大神埃瑞克的帮助下，逐步将精益和 TOC 的诸多方法引入运维管理的过程。 这本书读之亲切的原因在于书中呈现的正是运维团队的日常：大量的变更工作，混乱的流程，人员瓶颈，忙于紧急工作，以及研发与运维团队糟糕的协同等等。作者通过一个个具体场景，为读者演示了： 更为重要的是，作者使用自创的三步工作法将这些套路组织在一个可以参考的框架内，并由此建立起一个从解决问题到建立反馈再到形成文化的整体流程。毫无疑问，《凤凰项目》通过假想的场景将精益思想可能带给运维工作的变化描写得深入浅出，而且还给出了从具体工作到文化创建的建议途径，仅凭这几点，其启发意义和指导性就使本书很值得一读。 当然，从关注业务连续性和精益思想的普适的角度看，将其归于 DevOps 亦无不可，而且其方法完全可以作为过程改进型 DevOps 的典型代表。 但是，由于书中探讨的场景仅仅局限于运维组织内部而且通篇并无太多笔墨谈及研发部分的运作方式以及研发和运维的协同、沟通方法，因此显得美中不足【注10】。 之后，“凤凰项目”还被设计成一款沙盘游戏，以期让参与者能够在协作中切实地感知和体验书本中的方法在整个故事场景中所带来的作用。 虽然以游戏化的方式建立初始认知是不错的方法，但这样的体验对实际的操作有多大的指导作用则是见仁见智的事情了。 《凤凰项目》可以说是精益（敏捷）思想向运维侧扩展的代表。除此之外，研发和运维运维侧的进步也演化出了不同的 DevOps 形态。接下来让我们一起看看 DevOps 发展到今天形成了哪些不同的形态。当前 DevOps 的几种形态如图11，无论狭义 DevOps 还是广义 DevOps，要提高整体流动性——无论局部的代码提交到上线运行还是全局的业务，我们需要处理两种效率： 图11. 软件生命周期中的部门墙 我们应该先优化哪一种效率呢？从《目标》和《凤凰项目》的经验，我们应该首先找出制约点，也就是瓶颈，然后在瓶颈处进行优化。否则，局部优化有可能无法达到全局优化的目的。举个例子，如果研发团队已经可以高质量快速地生产，那么我们仍然一味地在研发部分投注资源去提高生产能力的话，只能造成更多的工作堆积到运维处（更多的在制品），全局效率并不能得到提升。 然而，现实的情况是，很多被 DevOps 神奇功效所吸引的组织其自身研发还没有梳理清晰，因此，这自然而然地就要将敏捷纳入到 DevOps 的范畴之内。也就是说，在研发自身还是问题的情况下，首先要处理研发内部的效率的问题，当研发效率提升后，瓶颈转移至研发与运维的结合处，此时再次运用敏捷来进行协调，这就是 DevOps 的第一种形态：由敏捷落地，而后从研发向运维侧扩展，如图12。 图12. 敏捷由研发向运维扩展 这种形态下，根据操作的方式的不同又可分成几种形式： 第一种，最为原生的形式，专注在流程方面。 图12. 敏捷导入前软件生命周期各阶段的问题 这种方式通常会采用一些成熟的敏捷（或精益）实践，对于研发和运维的之间的部门墙，则以提高沟通和协作为目标，建议尝试《凤凰项目》中的一些方法。 这种 DevOps 方式其本质就是敏捷，其适用于开始时研发侧依然问题重重的情况，或者是运维被杂乱无章的工作束缚而使运维工作低效时。 这种方式的优点在于易操作、见效快，但缺点在于流程改进措施的天花板很快就会触达，此时，自然就需要借助第二种形态。 第二种，基于持续集成构建持续交付。 图13. 敏捷导入后，问题可能在于测试和运维部分低效 组织开始尝试这种方式时已在内部采用了敏捷开发实践，此时可能的问题常常在于测试团队低效，如测试团队仍然依赖大量人工进行回归测试，以及运维上线的低效。这种形式的主要指导思想是持续交付。 基于组织具体所处阶段，其对持续交付实现的程度可能不尽相同，如图14，对于小型互联网公司，基于 Jenkins 的 pipeline 就可以快速搭建起可用的简单持续交付环境。 图14. 基于 Jenkins 的 pipeline 的极简持续交付 但对于规模稍大、业务更为复杂的公司，可能就需要引入更多的开源工具，基于持续交付的理念来搭建整个持续交付工具链，如图15。 近两年环境和部署类工具的繁荣，使基于开源工具链的搭建越来越简单，而 Jenkins 和 Docker 是其中最重要的两个工具，目前，这是多数公司关注的阶段。 对于规模更大的公司或者一些有着不同理念的企业，可能会有自研工具链生态的诉求，这个我们之后讨论。在此种形式下，有一点需要注意，即研发和运维团队在生产上线过程中的职责划分。 通常，出于安全和稳妥的考虑，会继续将生产上线的职责放在运维团队，并建立流程进行管控。我们更建议尽量将整个应用运维的工作完全交给研发负责，包括生产环境的维护和上线，只要保证无关人员不直接登陆生产环境，以及保证数据安全性即可。 图15. 基于Jenkins、Docker等开源工具的交付工具链 第三种，DevOps 认证 图16. 证书的价值应该在于其能代表解决问题的能力 这是近两年兴起的事物，敏捷社区和大会上有关认证的讨论至今尚无定论，而 DevOps 的认证加入则让情况变得更为混乱，当然，这也从侧面反映出 DevOps 的火热程度【注11】。 不过，DevOps认证课程中源自《凤凰项目》的沙盘推演确实可以像敏捷工作坊中的游戏，帮助参与者了解套路后的理念、产生共鸣，但对于一个重技术的领域，这样快餐式的布道对实际工作的启发和指导究竟能有多大作用，确实有待考证。 因此，DevOps认证需要更多来自一线的真实实践数据的支撑，否则其不过是某种形式的安慰剂。而且据目前的了解，参与DevOps的认证者多数是运维人员。 但就个人的看法而言，为了达到软件全生命周期的最高效的运转，DevOps的出发点和落脚点最后都应该在于研发本身，运维应该成为幕后英雄。 今天，秉持类似理念的公司早已将研发团队打造成多能团队，做到近万系统的高效研发和运营，如果我们还在满足于玩这种家家酒，那可以认为是一种懒惰了…… 除了敏捷从研发侧向运维侧的扩展，另一个的改进来自于运维侧的发展，如图17，这种情况常见于规模较大的互联网公司中，如腾讯的织云系统和阿里的运维平台，Google 的 Borg 系统及相配套的 SRE 制度多少也可以划归到这一类中。 通常，此类平台需要多年积累和打磨，其成本惊人。但近几年由于像 Puppet、Ansible 和 SaltStack 这类的配置管理工具及 Docker 和 K8s 这类环境管理和资源调度工具的成熟，普通公司也可以快速建立起一套可行的自动化运维平台。 此类平台通常要么是基于传统 CMDB 或 ITOM，将应用组成和环境信息的元数据管理起来，并根据这些元数据指导新的应用和环境的部署（有人将其称为CMDB中心化），要么是直接解决部署和资源调度自动化的问题。 这样的平台一旦成功，相应的流程和实现标准就都会围绕其设立。这种聚集作用会将研发侧的工作吸引到平台上，或者围绕平台构筑更为强大的工具生态。 图17. 运维侧的平台搭建可以将研发侧拉入 在这样的平台上，应用运维工作对于研发人员而言可以成为一种自助服务，运维人员就可以从此类事务性工作中脱身出来并将精力投注到更有挑战性的工作上。 如果运维团队还提供了监控平台，甚至是测试平台，可想而知，研发人员独自运营系统将并非难事，研发和运维在应用运营上将无需沟通和协调，正是所谓的，最高效的协作是无（需）协作，最好的沟通是不（用）沟通。 虽然开源软件的出现降低的平台关键技术的难度，但此类平台成功的最大挑战却往往不在于此。一方面，如何能够抽象出一套简单的体系，使不同业务都可以涵盖其中，当新业务出现时平台无需或只要做很小的改变；另一方面，平台的扩展性如何，是否可以很好地与软件生命周期中的其它工具很好地协作？最后一点，对于操作人员而言，平台功能是否足够简单易用。至此，我们已经看到研发侧向运维侧的敏捷扩张，也简单审视了运维侧自动化运维平台对研发侧的拉动。现在，让我们看看与DevOps相关的其它尝试。 首先，我们来了解一下自研系统的必要性。 如图18，DevOps 涉及的工作极为庞杂，开发到运营的每一项工作，本身就具有单独成为系统的可能。当业务本身相对简单时，如前所述，我们可以围绕 Jenkins 构建整个 DevOps 交付工具链，但随着规模的扩大，Jenkins 本身的弊端就会显现。 如图19，Jenkins 承担了从CI到部署的诸多工作。虽然Jenkins本身是平台，具体的工作交给了插件完成，但插件的逻辑往往通过 Jenkins 内的配置或脚本实现。 这一方面不利于大规模情况下的复用，而且在一些需要更为复杂操作的情况则需要大量工作，甚至无能为力。比如，以构建为例，除了打包和部署前测试工作，我们很可能希望基于包的依赖关系进行兼容性检查，并按配置的版本规则将所有使用者的构建触发起来进行验证，在执行的过程中更新元数据以便后期系统组装时可以参阅等等，这样的工作交给一个构建系统则更为方便。 而且独立的系统更容易抽象出 DSL，从而将编程性的工作变成声明性（配置）的工作，极大地提高工具的易用性。此外，独立系统也能够考虑更为细节的工作，并快速演化。 图18. DevOps 相关工作 图19. 承担太多职责的Jenkins 另一个促使我们希望自研系统的原因可能是量化数据的获取和建立软件全生命周期的管理。今天，在运维侧，与系统相关的数据获取早已不是难题，通过 zabix，pinpiont，zipkin，ELK 等等工具，我们即可搭建起从资源到应用服务的全链路监控（虽然需要一些定制开发工作，而且性能可能也无法支撑大规模应用，但标准化的商用软件非常成熟）。 而 DevOps 的工具链搭建似乎让我们看到收集研发和部署数据，并将其与系统运行等数据拉通的可能性。这个想法无比诱人，尤其是考虑到在这些数据上构建起的大数据应用，使我们有机会更深、更广地了解研发和运维，从而真正对软件全生命周期进行管理。 之前，基于开源工具搭建起的交付工具链可能并未考虑数据收集工作，而且其与软件生命周期其它阶段工具的配合也有问题。此时，我们要么需要对这些开源软件进行定制化开发，要么从头开发我们自己的工具。虽然处看起来，基于开源软件的二次开发似乎更为经济，但实际上，对大型企业而言，从头开发往往才是捷径。 其次，对于 DevOps 平台我们该如何选择？ 如同我们之前讨论，此类 DevOps 平台也可分为研发侧平台和运维侧平台，研发侧平台通常集成了项目管理、持续集成、测试和发布等功能，除了项目管理外，其它功能就是对 Jenkins 相关（插件）功能的二次封装； 而运维侧平台多数是在早期的 CMDB 基础上，配备了元数据、测试和部署等功能，其实背后的引擎往往也是 Jenkins。使用大一统的工具平台可以帮助我们省去自己搭建和维护的成本，在好的情况下，还可以将最佳实践通过工具固化下来，这对运维侧的平台尤其适合。 但对于研发侧的平台而言，我们就不得不考虑公司和团队的现状，因为需要遵循平台给出的流程和使用方式，有时即便知道平台给出的是最佳方案，但改变过于急进，失败的风险很大。研发人员是如此天生骄傲的人群，如果平台不是公司为研发人员量身定制的，我们最好把搭建平台的工作交给研发自己吧。 微服务与 DevOps2.0 DevOps 并不依赖微服务！ 这本来是两个在各自世界里独立发展的概念。微服务自诞生时起就被其所要求的独立部署困扰，加之业务往往会拆分出大量微服务，这些服务的编排和治理也是难题。 这种状况一直持续到基于 Docker 的不可变部署流水线出现后才得以改善，而这项技术是伴随着 DevOps 运动发展起来的。因此，相对确切的表述是，微服务需要 DevOps 的相关技术来实现其部署和治理。Viktor Farcic 在《The DevOps 2.0 Toolkit》中详细介绍了使用基于容器的微服务来构筑持续部署流水线。【注12】 DevOps下的团队与角色 在敏捷的方法论中，我们以打造自治的全功能团队为目标。在这样的团队中，我们通常会在团队中配备尽可能全面的人员角色。比如业务、产品、项目管理、开发、测试等等，由于部署和研发在组织上的分离以及我们对运维工作的传统认识，运维人员通常不包含在这个团队以软件生产为目标的团队中。 现实中，尤其在一些互联网业务的公司内，功能上线的时间是在开发时就被强制确定下来的，这种情况下，为了保证之后研发与运维工作交接的顺畅，以及让运维人员及早做相应工作安排，在项目启动时也会把运维人员拉人到启动会议（或计划会议）中。 图20. 一种常见的全功能团队组建方式 但在 DevOps 的情况中，系统的运维（运营）需求成为重要的需求，一个不易运维的系统最终将拖慢业务的连续性，因此运维人员的早期介入成为必然。随着整个工具链逐步成熟，这样的全功能团队中，最先受到冲击的就是测试人员。在部署流水线中，大量的测试将依赖自动化的技术完成，因此，对于通过人力密集型的方式进行测试的组织，精简团队势在必然。甚至在某些技术产品中，测试团队可以完全被取消，如图21。 在我们企业的实际例子中，近百人的研发团队中没有设置任何测试岗位，测试工作要么交由研发自身负责，要么依赖自动化的分层测试解决。在更为一般的情况下，研发团队应该担负起产品（或系统）的全部技术性测试工作，而精简的测试团队则应更专注于无法自动化的测试部分，如用户体验测试、可用性测试或者探索性测试等等。 图21. DevOps 下的测试人员 其次，如我们之前探讨，运维人员应该将应用运维的工作交由研发人员负责，这样整个系统的研发和运营可以由最熟悉它们的人来全权负责——还是我们之前所说，最高效的协作是无协作。 如图22，在这种组织结构方式下，我们对研发团队的要求是尽力多能，当然这样安排的前提在大型企业中，需要对应工作可以由自服务的工具很容易完成【注13】。 图22. 研发多能下的组织结构 最后，让我们再次强调，DevOps 应该起于研发，终于研发！ 亚马逊的启示 组织的竞争优势并不在于精益技术、盈利产品等解决方案本身，而是取决于组织根据现有条件制定恰当解决方案的能力。 ——《丰田套路》通常，我们认为 Google 的 SRE 是 DevOps，但当阅读《SRE:Google运维解密》时，SRE 的负责人却言之凿凿的说 SRE 是谷歌应对自己业务特点而创造出来的，虽然其形式在某些方面与 DevOps 暗合，但 SRE 本身不是 DevOps。类似的情况也发生在亚马逊身上，早在2005年亚马逊已完成整个工具链和研发的全生命周期管理，当然，之后这个工具链的组成部分还是在不断的演化。在2012年左右，内部构建系统基本每分钟发起一次构建。 在2014年左右，亚马逊内部的包（包括第三方依赖包）已超过12000个，假使50%是第三方包和陈旧的包，其它6000左右的项目包每两个包组成一个独立系统（一个应用包+一个配置包），整个亚马逊保守估计有超过3000个生产系统在运行中，这些系统一般对应还有开发、测试等环境，也就是说有上万的环境在运转。 亚马逊在没有 DevOps 的指导下如何成功，以及伴随这个问题的另一个有趣的问题——也可能是这篇文章中最为重要的问题就被提出来：在DevOps背后，最为重要的东西是什么？ 正如《丰田套路》中所说，隐藏在精益具体套路背后的分析和解决问题的思考方式和方法才是最重要的，因为，它可以帮助我们找出和建立起新的方法。因此，不要过于迷信 DevOps，看到自己的问题，义无反顾的思考并解决，共勉！ DevOps 再认识 最后，让我们谈谈对 DevOps 的一些看法： 第一，软件开发交付的应该是运行的系统。 由于运行的系统承载着运转的业务，因此，从这个角度，研发团队将对自身工作的定位有更为清晰的认识，围绕研发的工作更容易统一目标。 图23. 研发交付运行的系统 第二，谁构建，谁运营。 在这个理念下，建立多能的研发团队，让支持团队从协作中逐步释放职责。 当我们让研发人员承担起应用运维的工作时，就需要思考如何平衡研发和运维工作。Google 采用的是故障预算的方式，亚马逊则由研发经理直接控制并使用卓越运营的方式进行调节。 图24. 谁构建谁运维 第三，构建起两个（反馈）闭环： 图24. 业务与研发闭环 图25. 研发与运维闭环 第四，围绕 DevOps 的文化、流程和系统要相互支撑，也就是说，在实施的过程中，要从业务出发，考虑组织和人员当前的情况，采用对应方式方法，不要急于求成。 当企业在初创阶段，通过敏捷调理流程，基于CI构筑CD可能就够了；当业务上了台阶，需要更多的人员和支持系统时，可以基于开源软件搭建工具生态，必要时构建自己和核心平台（构建系统和部署系统等）；当企业规模更大时，自研完整的工具生态就非常必要了。 最后，优秀的 DevOps 工具链应该做到： 可配置、可重建、可追溯 自动化、可视化、服务化 自服务 易用 数据驱动 自我演化
未来 随着DevOps的成熟，下一阶段的创新点在研发运维的数据运用，不难想象，一个全线拉通的体系不但能让我们对业务和系统有更细粒度的洞察——建立全链路监控，甚至是全生命周期监控，而且人工智能的引入还能让我们构建出新的能力，如异常点检测、根因分析等等，这就是智能化运维（AIOps）。毋庸多言，现代IT企业的发展走到了一个加速分化的阶段。将优秀产品推向用户的成本和速度将成为决定企业生存与否的关键因素之一。优秀的互联网企业已装备精良并持续优化，新兴企业是否还要日以继夜的赶工，亦或趁此机会构建出自己的能力壁垒？ 理论和工具已在手中，时不我待，行动起来…… 原创：运维派
| 
转播
分享
淘帖
()