计算机科学中的任何问题都能够经过发明一个概念来处理。如果一个不可，那就两个！

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]【注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）。此刻即使研制能够经过灵敏高效起来，但糟糕的交给进程依然会将事务交给全体拉回到低效的瀑布办法[2]（图6），乃至构成事务失利，而这正是促进咨询师Patrick Debois提出DevOps的要害地点。【注8】


图5. 原生DevOps定位


图6. 紊乱之墙


图7. 糟糕的交给让灵敏回到瀑布

此刻，让我们站在图1时刻轴的2009年处，回看过去并瞭望未来！向后看，灵敏现已有近10年的开展，环绕继续集成的实践现已比较老练，但传统运维侧的布置和运维范畴里的东西都尚待昌盛，而整个社区内只需为数不多的经历能够用来辅导DevOps实践，如Flickr的《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》[3]。而向前看，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[4]：
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运维的传奇故事》[5]，这本书是灵敏和精益思维辅导DevOps作业的里程碑式的作品。下面让我们简略回忆一下这本书。

《凤凰项目》
这本书经过小说的办法，叙述了无极限公司运维部的比尔在大神埃瑞克的协助下，逐步将精益和TOC的许多办法引进运维办理的进程。这本书读之亲热的原因在于书中呈现的正是运维团队的日常：许多的改动作业，紊乱的流程，人员瓶颈，忙于紧迫作业，以及研制与运维团队糟糕的协同等等。作者经过一个个详细场景，为读者演示了：
经过看板可视化改动作业（精益）

经过发现捆绑点找出流程中待改进部分（TOC）

经过缩小批量和发布距离前进体系流动性（精益）

经过集合事务方针打破部分优化（TOC）

经过削减在制品消除糟蹋（精益）

经过前期重视质量及防止缺陷传递来前进质量、消除糟蹋（精益）

经过剖析问题本源来防止问题再次发作（精益）

经过规范化流程和作业来前进功率

经过区别作业性质来做合理的取舍

经过自动化下降人为过错的概率

……

更为重要的是，作者运用自创的三步作业法将这些套路安排在一个能够参看的结构内，并由此树立起一个从处理问题到树立反应再到构成文明的全体流程。毫无疑问，《凤凰项目》经过设想的场景将精益思维可能带给运维作业的改动描写得浅显易懂，并且还给出了从详细作业到文明创立的主张途径，仅凭这几点，其启示含义和辅导性就使本书很值得一读。当然，从重视事务连续性和精益思维的普适的视点看，将其归于DevOps亦无不可，并且其办法彻底能够作为进程改进型DevOps的典型代表。可是，因为书中评论的场景只是局限于运维安排内部并且通篇并无太多翰墨谈及研制部分的运作办法以及研制和运维的协同、交流办法，因而显得美中不足【注10】。

之后，“凤凰项目”还被规划成一款沙盘游戏，以期让参加者能够在协作中切实地感知和体会书本中的办法在整个故事场景中所带来的效果。尽管以游戏化的办法树立初始认知是不错的办法，但这样的体会对实践的操作有多大的辅导效果则是见仁见智的作业了。

《凤凰项目》能够说是精益（灵敏）思维向运维侧扩展的代表。除此之外，研制和运维运维侧的前进也演化出了不同的DevOps形状。接下来让我们一同看看DevOps开展到今日构成了哪些不同的形状。

当时DevOps的几种形状
如图11，不管狭义DevOps仍是广义DevOps，要前进全体流动性——不管部分的代码提交到上线作业仍是大局的事务，我们需求处理两种功率：
部分内部的功率

部分之间的功率


图11. 软件生命周期中的部分墙

我们应该先优化哪一种功率呢？从《方针》[6]和《凤凰项目》的经历，我们应该首要找出制约点，也就是瓶颈，然后在瓶颈处进行优化。不然，部分优化有可能无法到达大局优化的意图。举个比方，如果研制团队现已能够高质量快速地出产，那么我们依然一味地在研制部分投注资源去前进出产才能的话，只能构成更多的作业堆积到运维处（更多的在制品），大局功率并不能得到前进。

但是，实践的状况是，许多被DevOps奇特成效所招引的安排其自身研制还没有整理明晰，因而，这自但是然地就要将灵敏归入到DevOps的范畴之内。也就是说，在研制自身仍是问题的状况下，首要要处理研制内部的功率的问题，当研制功率前进后，瓶颈转移至研制与运维的结合处，此刻再次运用灵敏来进行和谐，这就是DevOps的榜首种形状：由灵敏落地，然后从研制向运维侧扩展，如图12。


图12. 灵敏由研制向运维扩展

这种形状下，依据操作的办法的不同又可分红几种办法：

榜首种，最为原生的办法，专心在流程方面。


图12. 灵敏导入前软件生命周期各阶段的问题

这种办法一般会选用一些老练的灵敏（或精益）实践，关于研制和运维的之间的部分墙，则以前进交流和协作为方针，主张测验《凤凰项目》中的一些办法。这种DevOps办法其本质就是灵敏，其适用于开端时研制侧依然问题重重的状况，或许是运维被乱七八糟的作业捆绑而使运维作业低效时。这种办法的长处在于易操作、见效快，但缺陷在于流程改进办法的天花板很快就会触达，此刻，天然就需求凭借第二种形状。

第二种，依据继续集成构建继续交给。


图13. 灵敏导入后，问题可能在于测验和运维部分低效

安排开端测验这种办法时已在内部选用了灵敏开发实践，此刻可能的问题常常在于测验团队低效，如测验团队依然依靠许多人工进行回归测验，以及运维上线的低效。这种办法的首要辅导思维是继续交给[7]。依据安排详细所在阶段，其对继续交给完结的程度可能不尽相同，如图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》中详细介绍了运用依据容器的微效劳来构筑继续布置流水线。[8]【注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的一些观点：

榜首，软件开发交给的应该是作业的体系，因为作业的体系承载着作业的事务，因而，从这个视点，研制团队将对自身作业的定位有更为明晰的知道，环绕研制的作业更简单一致方针。