在DevOps的开头，模型的缩写也相同：它打破了开发与操作和维护之间的隔离墙。团队之间的沟通更好，并且以共同的目标和重点运作。在极端情况下，不再是开发人员，操作和维护人员，而是DevOps技能集合，但是现在，DevOps的另一种观点是：它是为开发人员提供环境提供环境的环境，然后尽可能避免它。
[您如何在DevOps职位的申请人中脱颖而出？请参阅我们的文章DevOps工作：如何赢得角色。]
这种模型适合您的业务需求吗？您了解内部开发和操作团队使其运行的工作吗？让我们看看。
DevOps扩大了敏捷性原则，以涵盖整个应用程序生命周期，包括生产和运营。因此，需要将操作（和安全）技能添加到交叉努力团队中，包括设计师，测试人员和开发人员。
此DevOps View的重点是“两个Bisa蛋糕”交叉 - 划线团队 - 小组和多学科团队。从服务开始到整个生命周期，它都有服务。这部分是因为这些服务是自主的，具有边界环境，并且可以独立于其他服务和团体开发，只要他们遵循其API合同。还假设这些“人才”团队具有运营底层平台的必要技能。
但是，另一种观点认为，Tongcai DevOps团队可能不想从事运营基础设施和平台业务 - 也可能没有有效的技能。
这是Netflix的Qianyun和DevOps Master -Adrian Cockcroft-他现在在Amazon Network Services（AWS）中表达该术语 - “无操作”术语，他晋升了本术语。事物：在进化的DevOps中，为操作和维护所做的许多事情都将核心服务放置在适当的位置。它对于将基础架构，流程和工具放置到位非常有价值，因此开发人员无需与操作员互动太多 - 同时更有效。（在Netflix案例中，基础架构主要由AWS提供和运营。）
“实际上，您不想与银行进行更有效的沟通。您想使用自动提款机。您想为自己服务。”减少开发人员与运营与维护人员之间的互动的摩擦并不总是意味着沟通更加令人愉悦。它也可能涉及不必要的沟通。您可以这样认为：实际上，您不想与银行更有效地进行沟通。您想使用自动提款机。您想要自助服务。
在此DEVOPS模型中，操作的关键方面发生在应用程序开发过程之外，并且独立于应用程序开发过程。
当然，开发人员与运营和维护人员（和其他学科）之间的沟通仍然很重要。最有效的过程具有持续的沟通。这可以实现更好的协作，以便团队可以在失败之前识别出故障；反馈，不断改善和培养增长；和透明度。
IT领导者必须了解，使用此更新和进化的DevOps方法，开发人员和运营和维护团队需要不同的东西。
充分利用此模型的开发团队需要专注于改善应用程序体系结构和开发人员工作流程。这包括注意工具以及公司如何构建应用程序。
通常，这从微服务开始。Devops最适合更模块化的应用程序体系结构，该体系结构允许更快的迭代和更增量的释放。
您的DevOps团队的迹象是什么？也许他们正在创建许多脆弱的应用程序，而小型更改将引起重大伤害。或连续集成/连续部署的过程（CI/CD）由于大型部署而陷入困境。也许不同。团队不断地重写同一事物的服务，但是这些方法是完全不同的。
此类问题的后果之一是损害团队的实验能力。这是一个大问题。快速迭代是DevOps的核心目标。
对于接受此DevOps视图的公司而言，操作和维护团队的作用是为开发人员提供核心平台和功能并支持它们，但主要是在幕后。这与Devops的概念相反开发与运营和维护之间的障碍？不是真的。您仍然可以拥有协作文化 - 同时您仍然不需要清楚地进行交流。
提供核心功能并摆脱困境的操作和维护团队需要做三件事：部署现代，可扩展的容器平台；启用开发人员的工作流程；并在自动化安全性的同时降低风险。现代容器平台应能够在整个云上大规模运行。此工作流使用重复的自动化来实现一致性和效率。
在安全方面，这些团队在整个开发过程中尽可能地整合安全性。目标是以透明的方式进行此操作，这不会损害DevOps团队的敏捷性并管理风险。这意味着DevOps团队需要安全且值得信赖的容器，经过验证的软件供应链，以及确认容器中内容的简单方法。
如果您试图实施DevOps IT领导者，那么首先是时候问一些核心问题，为什么要对业务有意义。也许像Netflix一样，您的公司希望该模型可以提供更高的速度来实现更快的产品开发和上市周期。对于那些因采用早期云产品而受到绿色空间优势或创新的先驱者而受到绿色空间优势或创新的先驱者的企业的影响，速度可能是成功或失败的一个因素。
评估时考虑以下问题：
重新检查您的DevOps方法以及如何通过新思维来改进它。在数字世界中，您不能依靠将您带到这里的相同系统和流程。