DevOps成熟前的曲折之路

这些年来，我发现这样一种现象：每当团队发展到DevOps即将成熟时，就会有这样的趋势，且称之为成熟前的曲折之路吧。近来，我曾使用一个前一段时间设计的DevOps模型，试图对这个过程进行阐述，然后发现随着云基础DevOps的出现，这个模型必须得更新了。所以我觉得应该跟大家分享一下，也听听别人的想法。令人惊讶的是在许多不同的工作环境中，比如在部署自动化、测试自动化还有许多其他情况下，都会出现这样的模式。在本文中，我会仅仅用部署自动化方案作为例子，但是请相信：这种模式同样适用于其他的技术方面。

这是我目前的模型，也是很长一段时间我跟许多客户和同事分享过的一个模型：

第一阶段：“按部就班的完成一切”——每次都按照列表逐步完成。或部署、或测试、或其他随便什么，只要归属于日常工作，都按表单逐步完成。在这个层次中，性能并没有太大优化，一切任务都完成地非常机械。

第二阶段：“必要工作遵循手册”——经过一段时间以后，我们发现：如果在任务执行前先做一个快速的影响评估，并且按照评估结果只完成那些必需的步骤，那么有很多步骤就可以直接跳过了（像是：不重新部署未更改的组件，或者不测试那些未更改的功能）。然而我们身处的这个时代，经过评估的每个部署看起来都不一样——如果资源流动太快，或者人员频繁更替，总是使用缺乏完成可靠评估所需技能和知识的新手，那么在这一阶段中，实际执行起来也会相当困难。

第三阶段：“自动化”——接着我们发现了自动化。但是，评估影响的自动化比通用步骤的自动化要复杂得多，因此每次我们都需要返回最初，重新运行所有的步骤。这样做减少了部署的工作量，但有可能会影响实际运行的持续时间。

第四阶段：“性能优化”——一旦掌握了自动化，我们开始寻求相应的优化方案。我们发现了这样的策略：只确认每个活动所必需的步骤，建立并执行动态的自动化脚本。这样一来我们减少了工作量，同时也不断降低着总花费时间。在执行的自动化方法切实可靠的基础上，我们使得整体结构逐步优化。

到这里我的故事通常就结束了，而且我会告诉你这是一个优化的最终状态，不会真正地再误入歧途。不过我认为，基于云的DevOps会更进一步，这使得我必须更新模型来适应：

在这个新模型中，我们需要再次运行之前的所有步骤。让我来解释一下：在自动化部署的情况下，不仅需要将所需的增量变化添加到环境中，而且需要完全实例化环境（以代码作为基础架构）。在自动化测试的情况下，则需要创建多个并行环境，同时执行多个测试以节省时间，取代在评估影响的基础上建立多个测试子集的测试形式。我们现在可以负担起这样奢侈的运行方式，因为我们在模型中遇到了新的壁垒，我称之为云壁垒。

诚实点来讲，我早就该做这个更新了，这也显示了这样的道理：如果很长一段时间你都使用同一个模型工作的话，就无法在它过时的时候意识到这一点，而只会一直尝试让它符合现实情况。希望更新后的模型也能帮你明确你的企业规划。通往DevOps成熟的道路虽然曲折，却是有捷径可寻的，但就如攀登险峰时一般，捷径往往会更险峻，耗费更多的体力。期待在“峰顶”与你相见！

原文链接：The Winding Road to DevOps Maturity（译者/李贻丽 责编/钱曙光）

本文为ImapBox编译整理，未经允许不得转载，如需转载请联系market#csdn.net(#换成@)