为何DevOps是如今最重要的技术策略
副标题[/!--empirenews.page--]
很多人初学 DevOps 时，看到它其中一个结果就问这个是如何得来的。其实理解这部分 Devops 的怎样实现并不重要，重要的是——理解（使用） DevOps 策略的原因——这是做一个行业的领导者还是追随者的差别。 你可能会听过些 Devops 的难以置信的成果，例如生产环境非常有弹性，就算是有个“癫狂的猴子）跳来跳去将不知道哪个插头随便拔下，每天仍可以处理数千个发布。这是令人印象深刻的，但就其本身而言，这是一个 DevOps 的证据不足的案例，其本质上会被一个反例困扰：DevOps 环境有弹性是因为严重的故障还没有被观测到。 有很多关于 DevOps 的疑惑，并且许多人还在尝试弄清楚它的意义。下面是来自我 LinkedIn Feed 中的某个人的一个案例：
科技行业的专业人士在那篇 LinkedIn 的帖子上表达了各种各样的答案，你会怎样回复呢？ DevOps 源于精益和敏捷如果我们从亨利福特的战略和丰田生产系统对福特车型的改进（的历史）开始， DevOps 就更有意义了。精益制造就诞生在那段历史中，人们对精益制作进行了良好的研究。James P. Womack 和 Daniel T. Jones 将精益思维（Lean Thinking）提炼为五个原则：
精益致力于持续消除浪费并增加客户的价值流动。这很容易识别并明白精益的核心原则：单一流。我们可以做一些游戏去了解为何同一时间移动单个比批量移动要快得多。其中的两个游戏是硬币游戏和飞机游戏。在硬币游戏中，如果一批 20 个硬币到顾客手中要用 2 分钟，顾客等 2 分钟后能拿到整批硬币。如果一次只移动一个硬币，顾客会在 5 秒内得到第一枚硬币，并会持续获得硬币，直到在大约 25 秒后第 20 个硬币到达。（LCTT 译注：有相关的视频的） 这是巨大的不同，但是不是生活中的所有事都像硬币游戏那样简单并可预测的。这就是敏捷的出现的原因。我们当然看到了高效绩敏捷团队的精益原则，但这些团队需要的不仅仅是精益去做他们要做的事。 为了能够处理典型的软件开发任务的不可预见性和变化，敏捷开发的方法论会将重点放在意识、审议、决策和行动上，以便在不断变化的现实中调整。例如，敏捷框架（如 srcum）通过每日站立会议和冲刺评审会议等仪式提高意识。如果 scrum 团队意识到新的事实，框架允许并鼓励他们在必要时及时调整路线。 要使团队做出这些类型的决策，他们需要高度信任的环境中的自我组织能力。以这种方式工作的高效绩敏捷团队在不断调整的同时实现快速的价值流，消除错误方向上的浪费。 最佳批量大小要了解 DevOps 在软件开发中的强大功能，这会帮助我们理解批处理大小的经济学。请考虑以下来自Donald Reinertsen 的产品开发流程原则的U曲线优化示例： U-curve optimization illustration of optimal batch size 这可以类比杂货店购物来解释。假设你需要买一些鸡蛋，而你住的地方离商店只有 30 分钟的路程。买一个鸡蛋（图中最左边）意味着每次要花 30 分钟的路程，这就是你的交易成本。持有成本可能是鸡蛋变质和在你的冰箱中持续地占用空间。总成本是交易成本加上你的持有成本。这个 U 型曲线解释了为什么对大部分人来说，一次买一打鸡蛋是他们的最佳批量大小。如果你就住在商店的旁边，步行到那里不会花费你任何的时候，你可能每次只会买一小盒鸡蛋，以此来节省冰箱的空间并享受新鲜的鸡蛋。 这 U 型优化曲线可以说明为什么在成功的敏捷转换中生产力会显著提高。考虑敏捷转换对组织决策的影响。在传统的分级组织中，决策权是集中的。这会导致较少的人做更大的决策。敏捷方法论会有效地降低组织决策中的交易成本，方法是将决策分散到最被人熟知的认识和信息的位置：跨越高度信任，自组织的敏捷团队。 下面的动画演示了降低事务成本后，最佳批量大小是如何向左移动。在更频繁地做出更快的决策方面，你不能低估组织的价值。 U-curve optimization illustration DevOps 适合哪些地方（编辑：常州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
