技术译文 | DevOps“五宗罪”，这样向DevOps过渡注定会失败

云计算提供的速度响应、敏捷性和规模效应，契合了如今不断变化的数字商业环境。企业基于最新的IT技术，重构IT架构，加速产品创新和服务交付的速度，从而提高运营效率和市场占有。

不过，企业IT管理者在利用云计算进行数字化转型时，往往会面临两方面的挑战：一是技术，一是企业固有的流程、文化和组织架构。许多公司仍然运转于各个“信息孤岛”，陷入依赖“瀑布式”软件开发的泥潭中，这与技术本身提供的巨大灵活性背道而驰。

在数字化时代，速度和敏捷性是企业领跑和打造核心竞争力的关键。DevOps通过打破开发与运维之间的隔阂，大大缩短软件的开发周期，并快速部署到生产环境，对企业的数字化转型至关重要。

DevOps就像一座现代软件开发的圣杯。许多人都在积极寻找，有些人声称已经找到，而更多人还在寻找中。

由于每家公司都有其独特的运营方式，通往DevOps成功之路上，没有一步步的标准化指导。但是，可以肯定以下这5种方式是无法过渡到DevOps的，DevOps不应该做什么，希望本文能够给企业客户以启示。

不确定DevOps对企业的业务意味着什么

DevOps并没有严格的定义，它为什么会出现，采用DevOps可以解决什么问题，有多种解释。

从2010年起，DevOps运动的创始人之一斯蒂芬·尼尔森·史密斯（StephenNelson-Smith）就发布了一篇有关DevOps的很漂亮的帖子。清楚地说明了，开发、运维和QA团队的所有成员应该就DevOps对他们各自意味着什么达成共识。回答这些问题有助于：

团队如何定义DevOps流程？应该在任何流程变化发生之前达成共识，否则会出现不必要的紧张情绪。团队要做的是开展工作，而不是花时间确定什么必须做，什么不该做。

团队成员愿意失去哪些特权?他们愿意钻研哪些任务?如果开发人员不想参与测试和基础设施维护，Ops工程师不急于开始编写代码，QA团队更喜欢手工测试，而并非编写自动化单元测试代码——这样的人将无法在一个健康的、有竞争力的DevOps团队中脱颖而出。

新成立的DevOps和其他部门之间会有什么界限？向DevOps软件交付方式的转变不可能在一夜之间发生，这需要大量的时间和资源投入。在此期间，试点DevOps的团队应该在所谓“卓越中心”的主要业务工作流程之外独立开展工作。

没有遵守DevOps文化

DevOps方法论实际上只有大约25%的比例使用了DevOps工具，诸如Ansible，Kubernetes，Salt，Puppet或Terraform等。

75%的客户，他们的DevOps方法依赖于组织内部的文化变革，正如我们在另一篇文章中所描述的，“为什么说DevOps文化是人类的一大步？”。

DevOps的理念非常简单: 提供持续集成、持续交付和基础设施即代码。

这意味着DevOps工程师不仅要熟练使用多个DevOps工具进行代码开发、构建、测试和部署;

还应该为代码交付自动化测试，并维护生产基础设施，因此，任何有可能出现的问题，都可以由团队中的任何成员来解决掉。

成功采用DevOps范式的最后一点，是将基础设施作为代码构建，尽管是最后强调的一点，但这并不代表它不重要。

当企业基础设施迁移到私有云或混合云之后，将有可能实现。当所有基础设施参数可以由每位团队成员通过轻松访问和修改文件进行配置时，就不存在瓶颈和过度的运营成本。

这正好对应了“你构建，你运行”的范例，形成了DevOps方法论的核心。

从单一任务和责任到统一的团队，拥有通用的工具集和技能集，以及共同的思维方式，对于培养可行和持久的DevOps团队至关重要。最重要的一点，这不可能作为一项基层行动而发生，它必须得到企业里C-Suite和经理们的全力支持。然而，这点引起了企业内部对治理和安全的关注，应该加以解决。

无法重组组织结构和治理

向DevOps迁移的原因之一仍然是，在企业业务中，错误的成本太高。这意味着错误的决策可能会让经理们失去他们的位置，这也是为什么他们真正抵制变化的原因。

“如果它行得通的话，为什么要改变它呢?” 然而，在现代快节奏的世界里，遵循传统惯例并不是很有效，因为没有按时交付价值意味着没有交付价值。

因此，为了加速软件开发，尽可能多地从交付流水线中去除管理开销。但是，不需要多个审批并不意味着不需要遵守安全和合规性限制。这仅仅意味着DevOps应该对其行为的后果负责，并且如果失控，有能力纠正错误。

正确的做法是在，DevOps团队的软件交付流水线上复制审批功能，同时将最后的消息留给管理人员。

通过这种方式，管理人员可以让DevOps在软件部署和基础设施更新方面做出决策，同时根据需要，也可以取消它们。如果缺乏这种控制，整个企业的软件部署和基础架构的统一结构就可能会变成杂乱无章的混乱。

DevOps工程师只有开发出稳定的和能够检验错误的工作流程，使所有更新顺利进行，DevOps才可以自行开展工作。

任务和职责的这种渐进式过渡，应该发生在整个企业中。这有助于建立一支强大自信的团队，自主展开工作，同时遵守安全和治理法规。

无法评估风险

持续交付、自动化测试、持续集成，构建不可变基础设施即代码—DevOps这些诸多优势都将会大大缩短上市时间和反馈循环。

但是，如果出现差错，同样的行为会导致重大损失。因此，DevOps工程师应该接受培训，尽可能地移除错误产生的因素。

这通常意味着自动化测试过程，俗话说:“如果可以自动化，就必须自动化”。

软件交付最近的阶段如果出现错误，那么成本对业务来说是相当高的，这会给 QA 和 DevOps 团队带来消极影响和倦怠状态。

为了避免这种结果，最好在DevOps中投入大量的精力来编写自动化单元测试，并锻炼使用Ansible和Terraform等配置管理工具，掌握Docker技能，实现快速部署测试和环境搭建，发布滚动更新，并在需要时快速回滚到以前的版本。从而降低风险，并提供稳定、不间断的服务。

无法提供可测量的统计数据

任何企业的核心目标都是一样的：赚取利润。因此，对企业来说，每一个变化首先应该是可行的，并得到高管们的认可。

虽然 DevOps 有助于加快服务和软件交付流程，但它应该满足某些KPI，从而证明其实施的合理性。

这些 KPI 将根据行业、传统基础设施的状况以及其他因素有所不同，但有一点是一样的：DevOps的采用应该解决问题并证明切实的结果。

为了达到这些结果，管理层应审核整个企业使用的遗留基础设施，系统和流程的状态。

从而确定效率和性能的大致水平，例如，从新特性的发布到发布这项功能的天数等。

一旦确定了上面这些参数，衡量成功就变得相当简单了。不过，这不是一个月、两个月就能达成的任务，部署全面的DevOps模型需要一年之久，这取决于企业的规模和重组工作流所需的工作量。

密切关注DevOps团队的表现，并将其与常规团队进行比较，有助于评估向DevOps过渡的进展和效率。

结论：

向DevOps过渡绝不是一时之功就能实现。它需要打好基础，获得企业整个管理层的支持，投入大量的时间和资源。

这一转型的结果通常会给企业带来切实的好处，正如Puppet关于DevOps的报告所论述过的。

本文抛砖引玉，如果你有DevOps方面的任何见解，欢迎后台留言与我们交流~~

文章来源：

标题：Transition to DevOps: 5 sure ways to fail

链接：https://itsvit.com/blog/transition-devops-5-sure-ways-fail/

注：本文转自灵雀云