在企业中，软件开发和软件运维通常是由不同部门（组）来完成的。现实环境中，根据软件生命周期，还在交付运维前，往往需要经历需求、设计、编码、测试等阶段，大规模的软件开发还需要在此基础上进行细分，这些细分基于在不同的软件工程模型，如：瀑布法、原型法、迭代法等表现形式各不相同。随着业务竞争对软件交付速度的提升，DevOps 逐渐成熟并为更多的软件人员所采用。
DevOps有着明显的有点，采用DevOps模式可以使团队成员工作成果的责任更加明确，并有效管理软件人员数量的弹性。同时，DevOps也要求跨职能的团队成员，这意味着团队成员需要完成从需求运维的全工序工作，对习惯于从事深入单一技能的人员提出了挑战。不仅如此，DevOps还需要回答在不降低交付质量的前提下：
如何实现团队沟通协同？如何寻找和培养多技能人才？如何分配工作任务？如何保持项目整体节奏的一致性？
笔者认为，要实现DevOps的关键成功因素包括敏捷的价值观、架构标准化、微服务化、精益等。
敏捷价值观，团队成员一致同意高频、快速交付高质量的工作成果，并形成团队文化。然而众所周知，传统IT组织架构中开发、运维、测试以及安全部门各自目标不同，其内在文化也不同。在DevOps下，共同的团队文化是成功的首要因素，每个成员都需要具备多目标分解的能力和承担相应责任。
架构标准化和微服务化，通过微服务化，提高可复用性，这也是当前DevOps最常采用的架构，被视为现行的标准架构。
精益的核心思想是减少不必要的浪费，例如：测试能够发现工作成果的缺陷，但测试是不是必须的呢？对质量是设计出来而不是检测出来的这一思想来讲，测试是一个可以通过设计和执行降低的比例的过程。减少测试从质量管理的角度来看即是减少工序浪费，因此通过精益的思路来控制设计与执行环节，减少不必要的测试，可以有效杜绝浪费。简单罗列一下的测试类型就可以知道传统的软件开发中，测试所占交付的时间成本了，常见的测试包括：单元测试、系统集成测试、用户验收测试、冒烟测试、回归测试等。
最后，需要说明的是DevOps对基于传统软件工程组织架构的SoD模型提出了挑战。SoD模型需要适应性修正。返回搜狐，查看更多