DevOps可以是革命性的 但它也可以带来自己的挑战

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

与此同时，DevOps不是一个可以用几个词轻松解释的东西，比如线性总线或星形网络。这是一种模糊，多变，有点抽象的东西。企业可以通过按下按钮来实现一个通用的DevOps方案 - 这是假设创建DevOps思维模式很容易实现的问题的一部分。在向DevOps模型“迁移”过程中可能会发生很多事情。

DevOps可以适应CI / CD和其他业务目标的各种简洁改进，但什么时候出错呢?我们向专家询问了在追求DevOps理念时需要注意的事项。这是他们所说的一些内容。

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

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

更新流程，设置和维护用于支持文化和流程的工具需要实时，并且投资的回报不会立即实现。创造投资的时间需要组织支持。“

工具≠技能

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

“我们在尝试实施DevOps的组织中一次又一次地看到的是一种优先考虑工具而不是技能的方法。问题在于你是否依赖于一种工具来为你的团队提供一种能力，当你应该努力构建它时这样说吧：如果你想成为一名出色的厨师，你会出去购买最好的刀具并开始砍刀吗?不，你上课，练习，你会尝试新朋友的菜肴。然后一旦你找到了基础知识，就去买那些花哨的刀。“

允许灵活性

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

“我从同行和其他球队看到的一个陷阱是对'敏捷'方法的超级严格。如果情况需要，你必须愿意不时违反自己的规则......只是不要做这是一种习惯。在当今竞争激烈的世界中，优先考虑的是加快产品上市速度。

“在提供解决方案时，不要挂断所有的制衡措施，确保每个利益相关方都有'i'点缀并且不会交叉。它仍然需要成为您的路线图和交付承诺的一部分。

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