DevOps——这是一个创新的想法和有趣的命题。公司可以通过变得更加敏捷来改进软件生产和其他操作，并通过消除信息孤岛和让人们一起交谈来打破开发和操作之间的障碍。

同时，DevOps也不是简单用几句话就能解释的东西，比如线性总线或者星型网络。这是一个模糊的、多变的、有些抽象的东西。企业只需按下一个按钮，就可以实现一个通用的DevOps解决方案——，这是很容易创建DevOps思维模式的部分问题。在“迁移”到DevOps模型的过程中，可能会发生很多事情。

DevOps可以适应CI/CD等业务目标的各种简洁的改进，但是什么时候会出错呢？我们询问专家在追求DevOps的概念时应该注意什么。这是他们说的。

没有简单的“DevOps解决方案”

DevOps不是可以简单地实现然后期望成功的东西。——DevOps团队需要适当的工具和组织的支持。没有这些，即使是最好的DevOps专业人员也不可避免地会遇到障碍。

更新流程、建立和维护支持文化和流程的工具需要实时性，投资回报不会立即实现。创造投资时间需要组织支持。'

工具和技能

太多的组织试图通过购买他们能找到的最令人印象深刻的工具来实现DevOps，但是如果没有能正确使用它们的人，世界上最好的工具是不会有帮助的。DevOps团队需要合适的技能和知识来开始提供价值。

“我们在试图实施DevOps的组织中反复看到的是一种将工具优先于技能的方式。问题是你是否依赖一个工具来为你的团队提供能力。当你应该努力工作的时候，这样说：如果你想成为一名优秀的厨师，你会出去买最好的刀，开始弯刀吗？不，你有课和练习。你会尝试新朋友的菜。然后一旦你找到了基础知识，就去买那些花里胡哨的刀。

允许的灵活性

规则的存在是有原因的，但是过于严格的遵守规则会阻碍进步。记住你的优先顺序，但是记住在某些情况下，速度超过了准确性。

“我从同行和其他团队那里看到的一个陷阱是，‘敏捷’方法超级严格。如果有必要，你必须愿意不时打破自己的规则。别这么做。这是一种习惯。在当今竞争激烈的世界，加快产品的推出势在必行。

“在提供解决方案时，不要挂上所有的制衡，确保每个利益相关者都点缀着‘我’，不要交叉。它仍然需要成为您的路线图和交付承诺的一部分。

“无论成功还是失败，都需要快速完成。确保您的环境的“基本”方面是您的团队的优先事项(CI/CD、配置自动化、日志记录和监控框架等)。).)并把它作为一种服务在山顶上传播这种狗屎。确保构建产品的软件工程团队能够利用您的服务，而不是仅仅因为他们不知道产品的存在就重新发明轮子，从经验中学习并在此基础上进行构建。”