概念
Dev：开发，和code打交道的
Ops：运维，部署底层架构
DevOps是一种思想论，结合了人-流程-技术，为客户提供了可持续增长的业务价值。
DevOps出现前后
没有DevOps之前
作为开发：职责是更多的代码，更多的feature
作为运维：职责是系统更加稳定，更为可靠
可以发现，开发和运维的KPI在底层是冲突的，更多的feature势必带来更多的不确定性，将给系统的可靠性带来挑战。
另外，传统的应用从需求提出到部署上线整个周期可能很长，短则数月长则至年。当PM提出新的需求时往往需求的反馈路径较长，无法得到开发的及时回应，且变更带来的难度也较大。从应用角度来讲，传统应用往往采用单体方式（巨石应用），修改某个部分一般也需要连带修改其他依赖它或者被它依赖的模块，这也带来了麻烦。
有了DevOps之后
从应用层面：巨石架构的单体应用按功能职责划分为微服务，单个服务的生命周期与其他服务解耦，这给整体应用的部分模块持续迭代更新带来了便利。
从软件生命周期层面：应用从需求提出到编程再到部署、测试上线、监控最后又重回需求，整体呈现一条闭合圆环，且圆环走完一圈的时间一般较短。同时，圆环末端监控环节也为新需求的提出提供了依据。这样，应用在一圈一圈的循环中持续构建和优化。
从部署上讲：传统应用一般部署在实体服务器上，或者VM等。而符合DevOps的应用一般部署在云上。
开发方式上的变化
waterfall开发方式
这种开发方式属于传统型应用的开发流程（没有使用DevOps），一个软件从客户提需求开始，到开发测试最后到交付是一把梭的，可能最后交付的时候和一开始提供的需求有偏差。且如果在中途客户对应用的需求做出了变更，也会带来很多的麻烦。这里我对瀑布的理解就是应用所有的API像瀑布一样在最终交付的时候涌现。
敏捷开发
敏捷开发其实就是应用了DevOps后的开发方式。之前提到了DevOps可以理解为一个短周期的需求实现圆环（包括从需求到最终监控再到需求的圆环）。那么在应用的开发过程中我们将不再依靠瀑布式的最终交付形式了，而是将一个应用拆分为众多需求，并且作为需求提出方将给需求按重要性赋予权重，而每个需求都对应一个“圆环”。开发在每一个需求圆环的实现过程中与客户进行沟通和对齐，使得最终交付和客户的意愿相同。圆环在每一次循环过程中都在为客户提供更大的、持续增长的业务价值，这也是DevOps精神的体现。
