许多人第一次了解 DevOps 是在看到它的成果之一并询问它是如何实现的。 没有必要理解为什么某些东西是 DevOps 的一部分才能实施它，但了解这一点——以及为什么 DevOps 战略很重要——可能意味着在行业中成为领导者还是追随者之间的区别。
也许您听说过一些归因于 DevOps 的令人难以置信的结果，例如生产环境非常具有弹性，它们可以处理每天数千次的发布，同时 "Chaos Monkey" 在周围随机拔掉插头。 这令人印象深刻，但就其本身而言，这是一个薄弱的商业案例，本质上承担着 证明否定 的负担：DevOps 环境具有弹性，因为尚未观察到严重的故障…… 尚未。
关于 DevOps 存在很多困惑，许多人仍在试图理解它。 这是来自我在 LinkedIn 动态中的某人的一个例子
最近参加了一些 #DevOps 会议，其中一些演讲者似乎暗示 #Agile 是 DevOps 的一个子集。 不知何故，我的理解恰恰相反。
想听听您的想法。 您认为敏捷和 DevOps 之间的关系是什么？
- DevOps 是敏捷的子集
- 敏捷是 DevOps 的子集
- DevOps 是敏捷的扩展，从敏捷结束的地方开始
- DevOps 是敏捷的新版本
科技行业的专业人士一直在 LinkedIn 帖子上发表意见，答案五花八门。 您会如何回应？
DevOps 在精益和敏捷中的根基
如果我们从亨利·福特的战略以及丰田生产系统对福特模型的改进开始，DevOps 会更有意义。 在这段历史中，精益生产的诞生地已被充分研究。 在 精益思考 中，詹姆斯·P·沃马克和丹尼尔·T·琼斯将其提炼为五个原则
- 明确客户期望的价值
- 识别每个提供该价值的产品的价值流，并挑战当前提供该价值所需的所有浪费步骤
- 使产品持续流经剩余的增值步骤
- 在所有可能实现持续流动的步骤之间引入拉动
- 朝着完美管理，以便服务客户所需的步骤数量以及时间和信息不断减少
精益旨在不断消除浪费并增加流向客户的价值。 这很容易识别和理解，通过精益的核心原则：单件流。 我们可以进行许多活动来了解为什么一次移动单件比批量移动多件要快得多； 硬币游戏 和 纸飞机游戏 就是其中两个。 在硬币游戏中，如果一批 20 枚硬币需要两分钟才能到达客户手中，那么他们在等待两分钟后会收到整批硬币。 如果您一次移动一枚硬币，客户大约在五秒钟内收到第一枚硬币，并继续收到硬币，直到大约 25 秒后收到第 20 枚硬币。
这是一个巨大的差异，但生活中的一切都不像硬币游戏中的硬币那样简单和可预测。 这就是敏捷的用武之地。 我们当然在高性能敏捷团队中看到了精益原则，但这些团队需要的不仅仅是精益才能完成他们所做的事情。
为了能够处理典型软件开发任务的不可预测性和差异性，敏捷方法论侧重于意识、审议、决策和行动，以便在不断变化的现实面前调整方向。 例如，敏捷框架（如 Scrum）通过每日站立会议和冲刺回顾等仪式来提高意识。 如果 Scrum 团队意识到新的现实，框架允许并鼓励他们在必要时调整方向。
为了让团队做出这些类型的决策，他们需要在高信任的环境中进行自组织。 以这种方式工作的高性能敏捷团队实现了快速的价值流，同时不断调整方向，消除了走错方向的浪费。
最佳批量大小
要理解 DevOps 在软件开发中的力量，了解批量大小的经济学是有帮助的。 考虑一下唐纳德·莱纳森在 产品开发流程原则: 中提出的以下 U 形曲线优化图示
这可以用关于杂货店购物的类比来解释。 假设您需要购买一些鸡蛋，并且您住在离商店 30 分钟路程的地方。 一次购买一个鸡蛋（插图中最左边）意味着每次 30 分钟的行程。 这是您的交易成本。 持有成本 可能代表鸡蛋变质并在一段时间内占用您冰箱中的空间。 总成本 是交易成本 加上您的持有成本。 这个 U 形曲线解释了为什么对于大多数人来说，一次购买一打鸡蛋是他们的最佳批量大小。 如果您住在商店隔壁，走到那里几乎不需要花费任何费用，您可能会每次购买较小的纸箱，以节省冰箱空间并享用更新鲜的鸡蛋。
这个 U 形曲线优化图示可以阐明为什么生产力在成功的敏捷转型中显着提高。 考虑敏捷转型对组织决策的影响。 在传统的层级组织中，决策权是集中的。 这导致由较少的人员更少地做出更大的决策。 敏捷方法将通过将决策分散到最了解意识和信息的地方来有效地降低组织做出决策的交易成本：跨高信任、自组织的敏捷团队。
以下动画展示了降低交易成本如何将最佳批量大小向左移动。 您不能低估更频繁地做出更快决策对组织的价值。
DevOps 在哪里发挥作用？
自动化是 DevOps 最为人所知的事情之一。 前面的图示非常详细地展示了自动化的价值。 通过自动化，我们将交易成本降低到几乎为零，基本上免费获得了我们的测试和部署。 这使我们可以利用越来越小的工作批量大小。 较小的工作批量大小更容易理解、提交、测试、审查，并知道它们何时完成。 这些较小的批量大小也包含较小的差异和风险，使其更易于部署，并且，如果出现问题，也更易于排除故障和恢复。 通过自动化与可靠的敏捷实践相结合，我们可以使我们的功能开发非常接近单件流，快速且持续地为客户提供价值。
更传统地，DevOps 被理解为一种消除开发团队和运维团队之间混乱墙壁的方法。 在此模型中，开发团队开发新功能，而运维团队保持系统稳定平稳运行。 摩擦的发生是因为来自开发的新功能将更改引入系统，增加了中断的风险，运维团队不觉得对此负责——但无论如何都必须处理。 DevOps 不仅仅是试图让人们一起工作，它更多的是试图在复杂环境中更频繁地安全地进行更改。
我们可以参考 Ron Westrum 关于在复杂组织中实现安全的研究。 在研究为什么有些组织比其他组织更安全时，他发现组织的文化可以预测其安全性。 他确定了三种文化类型：病态型、官僚型和生成型。 他发现病态型文化预示着安全性较低，而生成型文化预示着安全性较高（例如，在他的主要研究领域中，飞机坠毁或意外医院死亡的人数要少得多）。
有效的 DevOps 团队通过精益和敏捷实践实现了生成型文化，表明速度和安全性是互补的，或者说是同一枚硬币的两面。 通过将决策和功能的最佳批量大小减小到非常小，DevOps 实现了更快的信息和价值流，同时消除了浪费并降低了风险。
与 Westrum 的研究一致，变革可以轻松发生，同时安全性和可靠性得到提高。 当敏捷 DevOps 团队被信任可以自行做出决策时，我们获得了当今 DevOps 最为人所知的工具和技术：自动化和持续交付。 通过这种自动化，交易成本比以往任何时候都进一步降低，并且实现了接近单件精益流，从而有可能实现每天数千次的决策和发布，正如我们在高性能 DevOps 组织中看到的那样。
流动、反馈、学习
DevOps 并没有止步于此。 我们主要讨论的是 DevOps 实现革命性的流动，但精益和敏捷实践通过类似的努力得到进一步放大，这些努力实现了更快的反馈循环和更快的学习。 在 DevOps 手册 中，作者详细解释了，除了其快速流动之外，DevOps 如何在其整个价值流中实现遥测，以实现快速和持续的反馈。 此外，利用精益的 改善 爆发和 Scrum 的 回顾会议，高性能 DevOps 团队将不断推动学习和持续改进深入到其组织的基础中，从而在软件产品开发行业实现精益生产革命。
从 DevOps 评估开始
利用 DevOps 的第一步是，在经过大量研究之后，或者在 DevOps 顾问和教练的帮助下，对高性能 DevOps 团队中始终如一地发现的一系列维度进行评估。 该评估应识别需要改进的薄弱或不存在的团队规范。 评估评估结果，以找到快速获胜的机会——成功机会高且将产生高影响力改进的重点领域。 快速获胜对于获得应对更具挑战性领域所需的动力非常重要。 团队应产生可以快速尝试的想法，并开始推动 DevOps 转型。
一段时间后，团队应在相同的维度上重新评估以衡量改进，并确定新的高影响力重点领域，再次从团队获得新的想法。 一位优秀的教练将根据需要提供咨询、培训、指导和支持，直到团队拥有自己的持续改进，并通过不断重新评估、试验和学习，在所有维度上实现接近一致性。
在本文的 第二部分 中，我们将查看 Drupal 社区中 DevOps 调查的结果，并了解最有可能找到快速获胜机会的地方。
Rob Bayliss 和 Kelly Albrecht 将在 DevOps：为什么、如何以及是什么 上进行演讲，并主持后续的 Birds of a Feather 讨论 在 2019 年西雅图 DrupalCon 上，4 月 8-12 日。
评论已关闭。