三种方式：支持DevOps的原则

2012年8月22日作者Gene Kim 45条评论

这篇文章是杨波老师分享的一篇文章：这几年对他架构影响最深的一篇文章。主要描述是关于DevOps的，但对系统架构同样适用：http://itrevolution.com/the-three-ways-principles-underpinning-devops/

在这篇博客文章中，我讨论了“三种方式”，这是所有DevOps模式都可以衍生的原理，我们在《 DevOps手册》和《 The Phoenix Project：A Novel About》中都使用了这些原理。   IT，DevOps，并帮助您赢得业务。”我们认为，“三种方式”描述了构成DevOps的流程，过程，实践以及说明性步骤的价值和理念。

与他的合著者Mike Orzen一起工作特别有趣，他是最近获得Shingo奖的得主，因为他的著作《精益IT》对卓越运营做出了贡献。

三种方式如下。在以后的博客文章中，我将描述可以从每个派生的DevOps模式。

第一种方式强调整个系统的性能，而不是特定的工作或部门筒仓的性能-这可以是一个大部门（例如，开发或IT运营），也可以是单个贡献者（例如，最小） ，开发人员，系统管理员）。

重点关注由IT启用的所有业务价值流。换句话说，它始于确定需求（例如，通过业务或IT），在开发中构建需求，然后过渡到IT运营，然后将价值作为服务形式交付给客户。

将“第一方法”付诸实践的结果包括：永远不会将已知的缺陷传递给下游工作中心；永远不会允许局部优化造成整体性能下降；总是试图增加流程；总是试图获得对系统的深刻理解（根据Deming） 。

第二种方法是创建从右到左的反馈回路。几乎所有过程改进措施的目标都是缩短和放大反馈回路，以便可以不断进行必要的纠正。

第二种方式的结果包括了解和响应所有内部和外部客户，缩短和扩大所有反馈回路，以及将知识嵌入到我们需要的地方。

第三种方式是创建一种文化，该文化可以促进两件事：不断的实验，冒险和从失败中学习；并理解重复和练习是精通的前提。

我们同样需要这两个。实验和冒险是确保我们不断推动改进的动力，即使这意味着要比以往任何时候都更深入危险区域。我们需要掌握一些技巧，这些技巧可以帮助我们在走得太远时退出危险区域。

第三种方式的结果包括分配时间来改善日常工作，创建仪式以奖励团队承担风险，将错误引入系统以提高弹性。

提起下：DevOps的社区 标记：DEVOPS，瘦肉，原则，threeways

评论

    1. DM科尔本

      2014年11月30日晚上8:14

      我赞扬吉恩·金（Gene Kim）为DevOps转型所做的贡献。这3条原则为发展文化变革要求提供了宝贵的关注点，而文化变革要求是嵌入DevOps价值体系的核心挑战。我的讨论建议确实可以提高这三个原则的价值。

      如果大家都同意，DevOps面临的最大挑战是改变当前的文化，价值观和奖励思维，那么关注“系统思维”就成为一个问题。对开发和管理“系统”的关注是否支持内部以IT为中心的观点？专注于Dev和Ops共同设计“服务”是否可以更好地支持以业务为中心的IT价值观？我认为，将DevOps的核心价值整合到IT服务生命周期中，最重要的是，通过针对3个原则的“服务”侧重来更好地服务。

      为了使内部IT部门保持相关性，企业必须改变其对IT的重视程度。IT必须从“成本中心”或“仅支出”部门发展到“服务提供商”或“贡献”部门。为了获得成功，IT必须能够以相同的方式展示价值，并且业务部门使用相同的评估点来展示其价值（即优化业务流程）。

      业务部门负责人天生就对“服务”进行量化（评估）并具有丰富的经验。另一方面，“系统”
      通常被认为是IT部门或与制造相关的部门的职责范围。但是，与制造相关的部门已经发展出更加成熟的功能，可以量化其价值以支持核心业务流程。IT部门正在努力发展同样的功能。

      DevOps是IT部门以业务部门领导者理解的方式发展评估其服务价值的能力所必需的关键范式转变。将可维护性，可用性，可靠性和服务级别可量化性构建到业务流程自动化服务中，IT设计，过渡，运营和不断改进，需要将开发和运营集成为在服务生命周期的所有阶段均发挥作用的单一学科。

      因此，我想知道是否将“ DevOps共同开发服务”的概念作为核心主体支持更多的“ IT转型”，从而避免了将上述“第一种方式”中的“系统”观点永久化的可能性。 DevOps的内部IT重点，而不是以业务为中心的“服务”角度。

      我的目的是促进有关这一点的讨论，以增强而不是批评吉恩为这些原则提供的价值。

      • 安德鲁

        2014年12月1日晚上11:07

        DM，您好，您当然比我更好。尽管我不想“批评”，但我认为，如果我们提出这样一种观点，即该讨论虽然承认“三种方式”的“潜力”，但将重点更多地放在我们的身上，那么该讨论可能会最有用。正在尝试“转型”，为什么将其视为“破产”，以及首先导致其“破产”并需要“转型”的“真正”文化和财务原因是什么？

        DevOps通过“持续集成”（通过代码）构建开发人员和客户之间的渠道，从而简化了流程。“监视触发器和事件”与组织的“票务”系统之间的连接；以及高级配置管理和/或可部署环境的完整“容器化”，以及其他作业描述符。运营只需要加入和/或避开。

        我对DevOps非常了解，因为这就是我和我的公司为许多大型和小型组织所做的事情。并且，我们的努力得到了丰厚的回报。而且，我不想咬住我的手。但是，我做的很多事情如此成功和/或如此“必要”，部分原因是政治失败和/或组织缺少或不存在程序：不一定是由于“三种方式”的“实力”或任何其他哲学性的声音。

        在某种程度上，可以将“ DevOps”视为“使操作更像开发”，然后我们理解为什么“服务台”的性质已被自动化和/或“自助服务”模型所取代。开发人员依靠用户/客户的反馈以及对崩溃的轻松“ PUT”，并将堆栈跟踪输出输出到“持续改进系统”中，从而可以在记录的时间内检测出缺陷，大概纠正并释放给客户。

        如果仅通过纯粹的数字，并在讨论中给予同等的重视，初创企业和规模较小，产品较少的公司，采用“敏捷”方法的“任务关键型客户服务”，流程和员工就很少（如果有的话）。指出快速的发展和很少的“灾难性”失败可以证明其端到端的“三种方式”，持续的反馈，承担风险和奖励产生收益的文化是坚定的成功。

        大型组织的产品和员工数量众多，并且只有一些绝对的“关键任务”服务才需要“吸收”这种精益的DevOps心态，并且其IT将得到充分的“转换”。

        在“第一种方式”中，我坚信IT专业人员需要从端到端理解其“系统”或生态系统。但是，随着生态系统数量的增加以及每个生态系统的复杂性的增加，充其量，任何一个人或一个群体的优势和/或可持续性“充分理解”每个处于充分“熟练”水平的生态系统就变得十分艰巨。因此，大型组织开始降低对“了解什么”的期望，因此确定其他人的生态系统中的“缺陷”或“退化”的能力充其量只是充其量。

        在“第二种方式”中，人员配备齐全且功能齐全的服务台可以充当来自系统，开发人员，测试人员，操作员和最终用户的反馈的信息交换所。但是，在政治上和经济上实施这样一个服务台的困难仍然是阻碍为规模较大的组织提供及时准确的反馈的主要障碍。

        主要来自文化和政治领域：当精品店开发商及其产品经理与他们的产品不直接相关时，“就不会为投诉和系统故障所困扰”。而且，并不总是能够“证明”这种关系：这要求开发人员和管理人员同意以诚实和开放的方式进行调查，并在发现错误时承认错误。

        因此，服务台对关键问题的解读和升级通常留给那些没有适当技能，对许多系统有知识或没有执行任务的政治权力的人，使他们的“缺乏效率”成为一种自我实现的预言。再次，这为自动和“自助”模型是唯一可靠且具有成本效益的反馈模型的观念提供了不公平的信任。

        在“第三种方式”中，我什至不会在这里讨论有效的“变更管理”系统是否不仅可以减轻风险，而且可以完全消除“冒险”的需要。我将探讨是否应将您的电子支票存款视为与墨西哥晚餐的“ Facebook赞”或“成功的Uber预订汽车服务”的服务责任“权重”相同。

        显然，要及时发现和克服“未知”需要承担一些风险。但是，错过某些“ Facebook喜欢”的风险与未进行某些“银行存款”的风险完全不同。

        我还没有完全按照风险的含义进行说明，但我也要坦率地说，只有“开发者”才能从冒险中获益。而且，这是在“未转型”和“完全转型”的IT商店中都发现的一种文化现象。更准确地说，风险/报酬系统仅旨在奖励开发人员。行动所能承受的唯一“风险”不会事与愿违，就是说“否”，因此她可能活着看到另一天。

        当开发人员承担失败的风险时，似乎只是无法解决先前已损坏的问题；或新的“功能”尚不可用。开发人员将再遇到一个或两个裂缝，或者根据需要进行多次裂缝，直到“杂物”起作用为止。但是，运营部门必须处理与维护故障产品相关的更多不便和风险。当开发人员最终“做到正确”时，他们获得了所有赞誉。所有运营部门在维护产品以及财务和层次结构利益方面，都可以减少一些头痛和风险，同样可以流向开发团队，而很少流向运营部门。

        当运营部门承担失败的风险时，客户将对产品失去信心，组织将失去业务，人员将失去工作。当运营部门承担成功的风险时，赞誉流向开发人员以“提出解决方案”，财务和分层收益也流向开发团队，而很少流向运营部门。

        因此，DevOps成功的“真正”原因（至少部分是）是因为我们现在看到“开发人员”担任运营角色。而且，现在，工程和产品经理对他们的“开发人员操作员”怀有一定的既得利益，这是他们在“系统管理员操作员”中从未有过的。我要说，唯一持久的差距仍然是对风险承担者的奖励（补偿）：DevOps工程师的表现仅比其Administrator Operator的前任略好。

        总而言之，我全力支持“敏捷”和“三种方式”。它们是处理IT和服务交付的令人兴奋且充满希望的方式。但是，运营商和服务台人员像开发人员一样获得报酬；服务台配备了真正的开发人员和一流的“ DevOps”工程师的那一天：那一天，“三种方式”可以是一个古怪的概念，适合那些产品很少，没有关键任务服务的初创公司。

      • 埃里克·哈格斯特罗姆

        2016年9月22日下午6:37

        您似乎将“系统思考”与IT构建，维护和运营的“系统”混为一谈。实际上，“系统思考”是一门与IT完全不同的学科，而我们认为的系统本质上通常是人类。Wikipedia可以让您很好地理解“系统思考”的含义，尽管沃特世基金会更简洁地做到了：http : //watersfoundation.org/systems-thinking/what/。

    2. 托比·韦斯

      2015年1月24日下午6:26

      我注意到“工具”不是其中一种方法。有人评论吗？我还将寻找有关工具与流程/文化主题的其他文章。

      • 史蒂夫·斯派克（Steve Speicher）

        2015年8月26日下午2:16

        工具只能帮助（或伤害）这三个原则。例如，如果您考虑第三原则，那么许多客户会寻找工具/产品/解决方案来帮助进行这种试验和重复性测试。我想到的最简单的方法是利用简单快速的方式来招募开发人员，例如OpenShift之类的平台即服务（PaaS）。另外，它允许本地连续集成和部署（重复）。这些可以通过许多第三部分系统来增强，例如Jenkins，Shippable，ContinuousCI等。

    3. 尤尼塔斯菲哈尼

      2015年9月22日，下午1:31

      最终crystal x di jakarta和obat gatal gatal di selangkangan引用了有关DevOps的内容

      • Imno Haree

        2017年10月10日上午9:15

        这些参考仅用于高级。它们具有高度的秘密性，您必须提供DevOps机密和宇宙其他机密的信用卡详细信息，以便在其所有荣耀中向您公开。在解码这些链接中包含的黑色艺术之前，请先阅读Phoenix项目以获取业余标准DevOps。

    4. 普拉米塔萨德维

      2015年10月10日，上午9:07

      jual crystal x di depok很高兴找到有关此DevOps的文章

      • 杰森·麦克斯帕辛（Jason McSpacin）

        2017年10月10日上午9:12

        具有讽刺意味的是，我们根本不感谢jual crystal x di depok。实际上，我将其比作SpamOps，这是一种非常好的实践工具，可污染互联网并试图向我们出售垃圾，而这些垃圾将永远无法真正交付。

    5. dianfebri

      2015年10月12日，上午8:18

      本文提供了更多有关围绕DevOps支撑原理的Jual Crystal x di depok的知识

    6. 叶夫根尼（Evgeny Zislis）

      2016年9月21日，下午3:29

      我现在正在阅读“ The DevOps Toolkit”的第一章。吉恩（Gene）真正喜欢“三种方式”的这个词无处不在。首先，它与此处描述的不同–因为如果我正确理解，那么Flow会改变系统思维。

      文本中到处都是“ First Way”，“ Second Way”，“ Third Way”，bla bla…我只是认为引用这样的命名原则是非常非常糟糕的选择。我不记得第一/第二/第三是什么意思，这很让人分心。在我实际上从中学到的大多数其他书籍中，有不同的原则名称-这些名称的使用和重复使用时都不会给它们加上数字或字母或其他任何东西，除非其首字母缩写很适合首字母缩写。

      您是否同意Gene需要在每个Way Number后面加上其名称，还是我不合理？

      • 埃里克·哈格斯特罗姆

        2016年9月22日下午6:58

        我同意“ First Way”等并不是一个非常有用的命名约定。这就像为变量A1，A2等命名一样。（打扰一下，我在必须使用BASIC生成工作代码的记忆中发抖。）
        至于第一种方式，您提到的两种表达方式是等效的。系统思考就是关于优化系统，简化系统，使其更可靠等方面的信息。当您对管理从业务需求到提供业务价值的服务“工作流”的系统进行这些操作时，会发生什么？您最终将优化流程，简化流程，使其更可靠等，然后对其进行改进。系统思考是您如何处理系统，更好的流程是改进它的结果。

      • 大卫·卡伦

        2016年11月7日下午3:18

        我同意。实际上，我已经开始将脑海中的“三种方式”翻译成他为它们使用的以下三个词：流程，反馈，实验。但是我可以根据@erick_hagstrom：disqus的出色评论来修改它。也许我会说系统思考，反馈，实验。任何事情都比学习新的三位一体更好。感觉就像参加邪教。而且我不喜欢邪教。我不想让我的团队喝苦力。我希望他们思考和学习。但我确实喜欢作者及其想法。所以我不会把婴儿和洗澡水一起扔出去。我只是轻描淡写“三种方式”。感谢您强调这一点。这也困扰着我，但是直到您回答我才对它进行检查。

      • 贝内特·埃尔德（Bennett Elder）

        十月11，2018在2:20上午

        科学家毫不费力地直接用数字指代牛顿的三个运动定律。当然，记住端口号和命令行语法以及首字母缩写词的我们商业和技术人员可以记住实现目标的三种方法。

        我花了一些时间来学习它们。菲尼克斯计划的书《伊莉亚胡·M·戈尔德拉特的目标》大有帮助。有时有点老套……但这是巩固这三种方法的概念的好方法。

    7. 多兰姆

      十二月14，2016在1:47上午

      “凤凰计划”似乎意味着“安全”不过是一个障碍。这本书可能是几年前写的，然后世界才意识到安全是事后才想出来的……是否有任何想法可言？

      • 鹰

        2017年3月30日，下午2:35

        我对这本书的印象是，安全性致力于解决法规遵从性问题，而这并不需要解决。另一方面，DevOPS鼓励每个人都关心安全性。我的印象

      • 乌齐尔

        2017年6月12日，下午6:32

        菲尼克斯项目将安全性定义为不是需要遵循的一组法规，而是一种需要交付的价值。安全测试和合规性并不是要检查的列表，而是遵循整本书中实践的相同思想和流程。当然，从法律的角度来看，仍然需要选中这些框。但是从行业角度来看，安全性需要像普通代码一样进行处理和测试，并且与UI一样具有价值。

    8. 彼得·罗

      2017年9月14日上午7:35

      没有人提到的最大挑战，至少就我在评论中所读的而言，是您的客户。能够快速迭代非常好，但是根据我的经验，客户永远都不想花那么多力气。他们只是在做自己有偿的工作，而这恰好是使用您编写和提供的软件。我们会在稳定的预定8周周期内发布新的测试版本，并让客户3周进行测试和反馈，然后再进行渗透测试的新版本，然后再进行RTM构建生产一周。我可以告诉您，我们非常幸运能够获得超过1个客户，他们将在分配的3周期间内积极反馈意见，尽管该年度内所有版本的日期都是预先已知的。

      • 布莱恩·沃克（Brian Wawok）

        十月8，2017在12:37下午

        这就是SaaS的奇迹。您每天都在升级。用户别无选择-台式机软件的8周周期太慢了。

        • 弗雷德里克

          2017年10月8日，下午4:15

          …或您自动升级桌面软件，例如Google Chrome或Spotify。

          • 彼得·罗

            十月11，2017在8:43下午

            这不是企业运作的方式。消费者软件肯定会像chrome这样，但是您必须在升级该软件之前先升级数据库，而客户在他们的测试系统上对其进行尝试之前就不会在生产中接受它，这完全是另外一回事。我想说的是，Rough只能拥有最新的，我们将发布一个新版本来解决任何问题，这根本不是企业可以接受的。

            • 特德·赫斯特德

              十月16，2017在1:18下午

              如今，许多购买SAAS模型的企业都接受它。

              以Salesforce.com为例。每年一次进行三次重大升级。补丁升级至少每周部署一次。据我所知，没有办法退出。

              当已经存在低信任度时，将现有产品迁移到SAAS模型肯定是一个问题，但是，如果正确呈现，那么许多企业将并且确实会接受该模型。

              就像原始海报所说的那样，客户永远都不想付出那么多的努力-但是信任是必不可少的。

            • 彼得·罗

              2017年10月18日下午6:14

              我猜这些人在那之前从未在当地政府工作过。

            • 拉朱

              十二月25，2017在11:33上午

              我同意彼得。除了Salesforce，Chrome等核心IT业务外，每周或每月的升级都会给客户带来很大的阻力。理想情况下，流程是可行的，但实际上政府面临的挑战众多

            • 亚伦·苏蒂

              三月29，2018，4:08下午

              我完全同意。我希望有一本ISV编写用于内部使用的企业软件的手册。

        • 彼得·罗

          十月11，2017在8:41下午

          它是网络软件，而不是台式机。对于桌面软件，这将是非常快的。您正在考虑使用浏览器之类的东西，但是业务客户和业务软件无法快速发展。

          • er

            十一月27，2017在4:11上午

            作为SaaS提供商，电信公司也存在直接接受实时软件更改的问题。尤其是因为在同一e2e环境中没有进行SaaS测试，并且客户是最终用户对服务水平的最终责任。最终发生的是连续测试，这会产生大量额外费用。

      • 布莱恩·特恩瓦尔德

        2018年5月15日，晚上9:07

        我找到了获得反馈的最佳方法，可以亲自或在电话上主动提出要求。当我通过电子邮件或“在那儿”放一些东西并要求他们进行测试时，它永远都做不到。客户喜欢提供反馈，但不要让他们为此而努力。轻松点！

    9. Vaes Theo

      一月18，2018在11:07上午

      感谢您分享此模型。我将其用于我们的社会创新项目，以持久地学习解决世代贫困。Armentekort.be

    10. 加里·威廉姆斯

      2018年4月10日下午6:27

      这篇文章使我很烦。为什么？因为这是100％正确的，但如今的开发人员仍与自动化，云和“开发人员工程师”相关联。他们中没有一个人了解这三种方式。