什么是devOps呢？，从概念上来说，devOps是一套方法和工具集，它在保证质量的前提下，着力于缩短变更从提交到部署到生产的时间。devOps最早的提出是为了解决dev（开发者）和ops（运维者）的理念冲突，dev希望更高频的发布，而ops除了稳定的初衷会比较抗拒发布。理念提出至今，devOps已经不再是最初只关注于dev和ops两侧，而是着力于变更的整个生命周期（需求、开发、编译、打包、测试、部署、发布、运维）；对于关注的生命周期，个人理解的是各家公司根据各自理解会有所不同，有的关注点是从变更提交（也就是开发）环节开始，有的则是从提出变更（也就是需求）环节就开始。但核心都是一样的，目标都是在保证质量的前提下，更快地把变更发布。
devOps理念是从09年就提出了，但是在这几年容器化技术流行之后才流行开的。个人理解的是，以前虽然大家提devOps，但是没有特别通适的方案来显著提升发布速度，开发提交后，还是要运维同学来实时部署，过程中虽然也可以通过一些脚本来做自动化，但是因为流程没有统一，方案很难做到通适，所以没有流行开。容器化技术出来之后，基于容器化的概念，可以通过自动化工具来做编译、打包生成容器镜像，和编排平台对接起来后几乎可以做到一键化部署，大部分原先由运维同学手动或用脚本完成的工作，现在可以通过自动化工具来完成，整个流程大大缩短了ops的耗时而且通适性。而且基于容器化的理念，减少了和线上环境的差异，能减少以前因为差异而出现的问题；同时，基于容器化理解，也为做弹性扩缩容提供了可能。所以容器化技术的流程也带来了devOps的流行。从这里其实可以理出一个思路，从传统模式转为devOps，编译、打包、部署的工作量其实并没有减少，只是完成者由运维同学转嫁到自动化工具或平台上去了；同样的思路，所以devOps中出现了很多开发过程的工具（代码检测等）、自动化测试工具等；说devOps落地方案时经常提到的一个词会是自动化，个人理解的更为本质的其实是工作承担者的转移；比如，我们把一些原本由运维同学负责的编译、打包、部署的工作转移到自动化工具或编排平台；把一些代码检查工作也转移到平台而且能自动触发；再深一步想的话，不一定是自动化，不一定要把一些工作转移到工具集，如果能把一些分散的工作集成到平台团队去，由专人集中或批量处理的方式，我觉得也可以作为devOps的落地策略；因为本质是提效，自动化、批量化、精细分工都是提效的思路。
devOps的流程也带了一些新变化；因为缩短了发布的周期，间接导致发布更高频，那么在更高频的发布下如何保证服务的可用呢？从架构上而言，它就需要我们采用能支持高可用的架构，所以间接也带来了微服务的流行（当然他们是谁带出谁这个没法说，只能说互相影响）；也因为更高频发布，所以可能有更高概率出问题，如何更快速的发现问题呢？所以这就带来的devOps对于监控的要求；微服务流行后，服务分步、调用链路比以前更为复杂，如何应对这些情况呢？这又带来了service mesh等概念；而且，因为我们现在做容器化，又把服务拆分了，又要保证高可能，很多时候会涉及多实例，那如何提高服务器资源的利用率，压缩成本呢？这又带来上云，弹性扩缩容等概念；既然已经上云了，每次新项目我们都要搭建同样的底层体系，有没有什么方式可以让我只关注于业务，不需要关注于底层、公共服务呢?这又带来了serverless的概念；而且我们刚刚说了这么多种可能和变化，是否最新的就一定是最好的呢？不一定的。真实的生态我们可以理解为是一个类似于金字塔的结构，基于底层理念总是能有一些更高抽象的理念，但是社会现实并非是只有金字塔尖尖，社会现实是整个金字塔；这里面会有一些公司用老技术来架构，也会有一些公司尝试新技术，也会有一些新旧穿插的情况。