1.理论基础
本篇是基于公司内部的一次DevOps分享，PPT是自己准备的一些内容。
目前主流的开发模型相信大家都清楚，这边简单介绍一下：
• 瀑布开发模型：生命周期很长，一般会完整的走如下流程：需求调研->详细设计->编码->测试->部署->运维，且下一环节需要等上一环节完成后才可以继续进行，往往需求阶段和测试阶段会占据很长时间，且需求调研结束后很少再做修改，因此，在一个长周期的开发完成之后反馈给客户，往往会进行一次较大的修改和调整，后期修改成本及其大。
• 敏捷开发模型：这种开发模式以一种不断迭代的方式缩短开发周期，把一个整体大的需求分成若干小的需求，进行迭代开发，并将产品反馈给客户的时间缩短，不断从客户得到反馈，并且不断修改直至客户满意，这种方式大大缩短了客户和开发测试之间的距离，把修改的成本缩短到一个小需求的生命周期，节省了修改成本。但是并没有解决开发和运维之间的协同合作，因此，DevOps应运而生。
• DevOps模式：该模式强调一个运维和开发不断沟通的能力环，在开发阶段我们沿袭敏捷的开发模式，在运维阶段，我们强调自动化的运维，并不断讲已经上线的产品中的问题反馈给开发，以进行问题修复。
我们可以看到，对于一个软件的生命周期，基本流程都类似，只是在各个阶段我们做了不同的优化，而且这种优化也是经历过考验的可以实施的最佳实践。
2.什么是DevOps
那么什么是DevOps呢？有人认为DevOps是运维+开发，有人认为是自动化，也有人认为是Ias，当然，这些认识都是有其道理，也是DevOps中不可或缺的一部分，但大多都是盲人摸象，没有对DevOps有个整体的认识，对于DevOps的认识，请转至第一章：深入剖析DevOps系列（1）
3.Develop和Operation的历史问题
开发和运维人员素来就被一种叫做部门墙的隐形之墙所隔离，这种问题由来已久，
原因1：开发和运维的目标不一致，开发的目的是不断的增加新功能，不断完善需求，不断发布新版本，总之对于开发来说，唯一不变的就是变化，但是，对于运维来说，首要的问题是要求稳，因为一切问题的来源都是变化。
原因2：两个角色所在的部门考核标准不一样，对于开发来说，新开发一个需求考核就递增一点，是个累加的过程；而对于运维来说，即使将发布工作做的极致，起点也只是0，因为，这本来就是运维应该做的，一旦出了问题，便会从0开始递减，是个递减的过程。
4.DevOps要解决的问题
DevOps首要解决的问题就是Develop和Operation间的这堵部门墙，一种模式就是借鉴敏捷开发的模型，将运维人员纳入到整个团队，之于团队的定义，就是有着共同目标的一群人
亚马逊有一种模式，叫做2 pizza team，用2个pizza就能搞定的Team定义为DevOps Team，当然，这个是一种抽象，目前最佳实践的DevOps team比例为1:4:1:1,即一个需求，4个开发，一个测试，一个运维，当然，可以根据不同公司的不同需求做一些调整。
5.DevOps遇到的强力阻碍
对于现在很多公司来说，存在很明显的责任推脱问题，相互推诿，相互指责，屡见不鲜，对于DevOps乃至整个公司来说来说，这不是一种好的工作状态，所以DevOps强调信任，沟通，相互学习和责任共担。开发，测试和运维之间的各种活动都需要把其他人作为关键干系人，做到测试和运维了解需求，开发和运维了解测试，测试和运维了解开发等等，当然，了解并不是让开发去做测试的事情，或者运维去做开发的事情，我们强调的，是沟通和相互了解~
