每个人都喜欢谈论 DevOps，但是当涉及到现实生活中的企业实施时，事情开始变得有些不稳定。在经历了数百个组织的过程后，xebialabs 销售工程团队向我传达了他们在企业首次实施 devops 时看到的 6 个最常见的错误。改变从来都不是一件容易的事，但如果你能避免这 6 大错误，你向 DevOps 的过渡就会相对轻松。
在实施早期没有得到认可
去找在生产（又名“ops”）方面“拥有盒子”的人。谈谈您的倡议，并帮助他/她了解这将如何使运营团队受益。 （目标：产品中的一键式部署）愿意与此人密切合作，为运营团队提供更新（演示、培训）。
没有过渡计划
一旦您以这种新的“devops”方式自动化了一些发布，运营就被迫有两种不同的部署过程：新的现代“自动化”方式和 17 页的部署电子表格。当您开始在生产中取得成功时，重要的是讨论和计划如何连接您的开发团队交付模型。
将 2-3 个应用程序从开发自动化到生产
这将帮助您发现应用程序交付过程中的所有……“细微差别”。涉及哪些人，你有什么要求等等。你可能已经知道这一点，但自动化迫使公司思考这些事情将如何变得更好。
只在较低的环境中自动化
大多数开发组织可以在其开发和集成环境中实现自动化。但是要进入质量保证、阶段、预生产和生产等环境，需要更多地考虑自动化的影响。如果 devops 团队无权在整个交付路径上进行更改，那么您会发现您的 devops 计划在这种“半自动”模式下失败了。
在现有的运营和开发团队之外创建一个开发团队
人们掉入的一个陷阱是引入另一个筒仓。意图是好的，某些项目的“无痛”迁移，但在实践中，绕过这个团队变得太容易了，或者更糟的是使用一些通过这个团队的快速路线来避免其他团队中存在的良好实践。我已经看到团队通过将“ops”嵌入到开发 scrum 中来避免这个陷阱。这通常会遭到抵制（“忙于砍树而无暇磨斧头”），但那些管理它的人学到了很多东西，并开始看到一个工作的 devops 组织的进展。
专注于错误的事情
正确进行 devops 与其他方式的主要区别在于人们如何相互交流。共享知识、共同目标、对成功的渴望都是希望正确行事的组织的特征。涉及的人员和业务结构越多，这就越难，大型组织中必须改变很多事情才能使这项工作发挥作用，其中一些变化会扰乱业务的其他领域，甚至可能变得更糟！
