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方面的任何看法，欢迎后台留言与咱们交流~~