消除了围绕DevOps的一些困惑。很多人在第一次学习DevOps的时候，看到它的一个结果，就会问它是怎么来的。事实上，了解Devops这部分是如何实现的并不重要。重要的是理解（使用）DevOps策略的原因。这就是行业领导者或追随者之间的区别。你可能听说过Devops的一些不可思议的结果，比如生产环境非常有弹性，即使有“疯猴ChaosMonkey”跳来跳去不知道拔掉哪个插头，它仍然可以处理数千个这是令人印象深刻，但它本身是一个记录不足的DevOps案例，它本质上被一个反例所困扰：DevOps环境具有弹性，因为尚未观察到关键故障关于DevOps存在很多混淆，许多人仍在试图弄清楚这是什么意思。这是我LinkedIn提要中某人的案例：我最近参加了一些#DevOps聚会，那里的一些演讲者似乎在提倡#AgileDevelopment是DevOps的一个子集。出于某种原因，我的理解恰恰相反。你能听听你的想法吗？你认为敏捷开发和DevOps之间的关系是什么？DevOps是敏捷开发的一个子集AgileDevelopmentIsasubsetofDevOpsDevOpsisanextensionofAgiledevelopDevOps是敏捷开发的新版本技术行业人士在LinkedIn帖子上表达了各种答案，你会如何回应？以及丰田生产系统对福特车型的（历史）改进。研究得很好。JamesP.Womack和DanielT.Jones将精益思想提炼为五个原则：指定客户想要的价值确定交付该价值的每个产品的价值流剩下的增值步骤。在所有可以连续流动的步骤之间完善拉式管理，使步骤的数量和时间以及服务客户所需的信息量不断下降。精益就是不断消除浪费并增加对客户的价值流。识别和理解精益的核心原则很容易，玩一些小游戏就可以看出为什么一次移动一个比一批移动要快得多。其中两个游戏是硬币游戏和飞机游戏。在硬币游戏中，如果一批20个硬币需要2分钟才能到达客户手中，客户可以在等待2分钟后获得整批。如果一次只移动一枚硬币，客户会在5秒内获得一枚硬币，并不断获得硬币，直到大约25秒后第20枚硬币到达。（LCTT译注：有相关视频）这是一个巨大的不同，但生活中并不是所有的事情都像投币游戏那样简单和可预测。这就是敏捷发挥作用的地方。我们当然在高性能敏捷团队中看到了精益原则，但这些团队需要的不仅仅是精益来完成他们所做的事情。为了能够应对典型软件开发任务的不可预测性和变化，敏捷开发的方法论将关注意识、深思熟虑、决策和行动，以便在不断变化的现实中进行调整。例如，srcum等敏捷框架通过日常站立和冲刺审查会议等仪式来提高意识。如果Scrum团队意识到新的事实，该框架允许并鼓励他们在必要时调整路线。对于做出此类决策的团队，他们需要能够在高度信任的环境中进行自组织。以这种方式工作的高绩效敏捷团队在不断调整的同时实现了价值的快速流动，消除了错误方向的浪费。批量大小了解DevOps在软件开发中的力量有助于我们了解批量大小的经济性。考虑以下来自DonaldReinertsen的产品开发过程原则的U曲线优化示例：最佳批量大小的U曲线优化图示这可以用杂货店购物的类比来解释。假设您需要买一些鸡蛋，而您住的地方离商店30分钟路程。买一个鸡蛋（图中最左边）意味着每次30分钟的路程，这是你的交易成本。携带成本可能是鸡蛋变质以及它们在冰箱中占用的固定空间。总成本是交易成本加上您的持有成本。这条U形曲线解释了为什么对于大多数人来说，一次购买一打鸡蛋是他们的批量。如果你住在商店旁边，步行到那里不会花你任何时间，而且你可能一次只买一小盒鸡蛋，以节省冰箱空间并享用新鲜鸡蛋。这条U形优化曲线可以解释为什么在成功的敏捷转型中生产力会显着提高。考虑敏捷转型对组织决策的影响。在传统的等级制组织中，决策权是集中的。这导致更少的人做出更大的决定。敏捷方法通过将决策分散到知识和信息最广为人知的地方：跨高度信任、自组织的敏捷团队，有效地降低了组织决策中的交易成本。下面的动画演示了在降低交易成本后批量大小如何向左移动。在做出更频繁、更快速的决策方面，您不能低估组织的价值。U曲线优化图示DevOps适用的地方自动化是DevOps最广为人知的事情之一。前面的插图非常详细地展示了自动化的价值。通过自动化，我们将交易成本降低到接近于零，从根本上免费进行测试和部署。这使我们能够利用越来越小的工作批次。较小批量的工作更容易理解、提交、测试、审查并知道何时完成。这些较小的批量大小还包含较少的差异和风险，使它们更容易部署、故障排除和在出现问题时从中恢复。通过将自动化与可靠的敏捷实践相结合，我们可以使我们的功能开发非常接近单件流程，从而快速、持续地为客户提供价值。更传统地说，DevOps被理解为一种打破开发和运营团队之间混乱局面的方法。在这种模式下，开发团队开发新功能，而运维团队则保持系统稳定和顺畅运行。摩擦的发生是因为开发过程中的新功能将更改引入系统，增加了停机的风险，运营团队对此不负责任，但无论如何都必须处理。DevOps不仅仅是试图让人们一起工作，更重要的是试图在复杂的环境中安全地进行更频繁的更改。我们可以看看RonWestrum关于在复杂组织中实施安全性的研究。在研究为什么有些组织比其他组织更安全时，他发现组织的文化可以预测其安全性。他确定了三种文化：病态的、官僚的和生产性的。他发现病态的文化预计会更不安全，而生产性的文化预计会更安全（例如，在他的主要研究领域，飞机失事或意外住院死亡人数要少得多）。RonWestrum确定的三种文化有效的DevOps团队通过精益和敏捷实践实现生成文化，表明速度和安全性是相辅相成的，或者说是同一枚硬币的两个方面。通过将决策和功能的批量大小减少到非常小，DevOps可以实现更快的信息流和价值，同时消除浪费并降低风险。与Westrum的研究一致，在提高安全性和可靠性的同时，很容易发生变化。当敏捷的DevOps团队被信任做出自己的决策时，我们将获得DevOps当今最著名的工具和技术：自动化和持续交付。通过这种自动化，交易成本比以往任何时候都进一步降低，并且实现了近乎单一的精益流程，创造了每天数千个决策和发布的潜力，正如我们在高绩效DevOps组织中看到的那样Flow,Feedback,LearningDevOps不止于此。我们主要讨论了DevOps实现革命性流程，但精益和敏捷实践可以通过类似的努力进一步扩大，从而实现更快的反馈循环和更快的学习。在TheDevOpsHandbook中，作者详细解释了DevOps如何在整个价值流中实施遥测，此外还解释了快速过程，以获得快速和持续的反馈。此外，利用精益突破和scrum回顾，有效的DevOps团队将不断推动学习和持续改进深入到他们组织的基础，从而在软件产品开发行业实现精益制造革命。从DevOps评估开始利用DevOps需要通过广泛的研究或在DevOps顾问和教练的帮助下评估高绩效DevOps团队中始终存在的一系列维度。评估应确定需要改进的薄弱或不存在的团队规范。对评估结果进行评估，以找到成功机会高的快速见效的重点领域，从而实现高影响力的改进。快速获胜对于为团队提供应对更具挑战性领域所需的动力非常重要。团队应该产生可以快速尝试的想法，并开始专注于DevOps转型。随着时间的推移，团队应该重新评估相同的维度以衡量改进并建立新的高影响重点领域，并再次吸收团队的新想法。一位优秀的教练会根据需要进行咨询、培训、指导和支持，直到团队拥有自己的持续改进计划，该计划通过不断的重新评估、实验和学习在所有方面几乎保持一致。
