几十年来，公司内部的开发和运营团队都是孤立的。开发人员开发软件，运营部门测试和部署软件。但在 2009 年，IT 顾问 Patrick Debois 创造了“DevOps”一词，将开发和运营相结合，以改善沟通、建立最佳实践并为组织创建反馈循环，从而不断改进整体的流程。
DevOps 承诺将深度聚焦并重新激发软件团队的活力，恰好容器看起来像是一种重新包装现有资源的有趣新方式。然而，容器的采用正在加速，编排容器使用的技术Kubernetes 常常被描述为革命性的。那DevOps呢? 如今，多达四分之三的组织使用DevOps 蓝图。然而，在Garden 最近的一项调查中，只有 11% 的受访者认为他们的运营达到了应有的水平，并对他们的开发设置和工作流程感到完全满意。在DevOps Institute的一份报告中，超过50%的人将他们的 DevOps 转型之旅描述为“非常困难”。
是什么造成了这种幻灭感？DevOps只是纸上谈兵，但在实践中却没有效果？自动化任务的过程是否耗费了团队本可以用于创造性创新的时间？
DevOps发展的痛苦源于我们倾向于高估它的作用，当我们没有充分理解某个事物的意义和能力时，我们就会高估它。不过我们高估DevOps也在情理之中，因为它的定义很松散。有成千上万的组织在实施DevOps，但没有两个组织以完全相同的方式定义其角色。在写下DevOps之前，团队应该明确它对组织意味着什么，并重新设定组织的期望，制定一个现实的“游戏”计划。在你定义DevOps可以为你做什么的时候，有以下三个关键要点需要牢记。
持续的文化转变
人类对变化有一种天然的抵触。实施有效DevOps的最大障碍之一是文化转变，包括技能短缺和自动化程度有限。虽然领导者可能会在DevOps计划启动时表现出兴奋，但只有持续的参与才能推动该计划的长期有效性。在Puppet 2021年DevOps状态报告中，组织自主报告了他们在DevOps发展中所处的位置——从低阶或中期发展到高阶发展。报告称，“与文化相关的挑战在处于低阶发展阶段的组织中最为严重，而处于中期发展阶段的组织中存在着持续的文化障碍。只有18% 处于高阶发展阶段的受访者表示他们没有文化障碍。”
如果管理者不致力于DevOps计划，团队成员就会失去焦点，导致项目的整体效率下降。如果这不起作用，有时尝尝被竞争对手打败的滋味也是一种有效的方式——使我们意识到必须演变以保持竞争力。
持续的，而不是最终状态
各部门通常以其在年度目标方面的进展来衡量效能。对于一些部门来说，实施DevOps模式可能是其中的进度点之一。然而，DevOps不是一个最终状态，实施DevOps也不意味着100%采用集成和自动化策略。例如，您不会希望有人使用只经过了两周时间开发和测试的软件来进行心脏手术。有些项目更适合采用传统的模式。因此保持两种模式，即DevOps和传统开发，能使团队从两者中受益。
没有终点线。相反，DevOps只是我们工具箱中的另一个工具——就像敏捷、SecOps和持续交付一样。
创造而不是合规
根据Garden的研究，美国公司每年在许多开发人员认为令人沮丧的任务上花费约610亿美元，如等待管道运行，等待构建和测试，以及设置、维护和调试管道/自动化，而不是在创新领域。另一个常见的挫折是实现和维护详细的合规要求的任务。虽然DevOps团队（执行备份）和Platform Ops团队（负责进行备份）之间有共同的责任，但Platform Ops团队才是最终对合规性负责的人。是的，DevOps是这个过程的一部分，但其核心重点应该是创造，而不是合规。
人们认为“左移”实践意味着左边的人承担全部责任，但这与成功的DevOps相冲突。为了不负众望，DevOps必须优先考虑数字服务的实际创建。
组织可以通过明确定义现实可行的期望来达到DevOps所承诺的生产力。虽然这在远程工作环境中是个挑战，但我希望当我们以某种身份返回办公室时，会有更多的机会进行临时合作，这将促进无论是开发人员还是组织领导层对 DevOps 的热情。
本人作者：Veeam首席技术官及产品战略高级副总裁Danny Allan
