0. 导论 DevOPS（Development & Operations）是软件工程里过程、方法和系统的综合实现。这里Dev和QA都归在Development里。 DevOPS的想法： 1） 是让开发、测试、运维各个部门之间沟通、协作更紧密（有点儿打破部门边界、模糊角色的意思）； 2）按时交付，快速交付（这一点和敏捷开发、精益创业一致或者说就是它们的实现）
很早以前有个概念叫——“持续交付”大体就是这个意思。
持续交付或者频繁交付涉及到“热补丁”的概念，考虑的不仅仅是软件集成、部署，同样需要快速测试云部署。所以，DevOPS需要的有以下几点： 1. 持续集成（Continuous Integration） 2. 持续交付（Continuous Delivery） 3. 自动化测试（Automatic Testing） 4. 云计算基础设施（数据中心自动化）； 5. 部署自动化，快速发布，可回退； 另外，不可忽视的一点是协同办公软件（wiki、SharePoint等）的使用才能有效减少沟通成本。
1. 问题主要在研发和运维上： - Dev的需要“频繁交付新特性”，而运维部门则更关注IT服务的可靠性和IT成本投入的ROI。两者目标不匹配； - Dev通常不考虑代码会对运维造成什么影响。在代码交付之前，从不邀请运维人员参与架构决策或代码评审； - Dev对配置或环境进行修改之后，经常没有及时与运维人员沟通，导致新的代码不能运行； - Dev愿意使用快速开发工具：对代码修改更快的反馈，更低的内存消耗，等等。这样的工具集与运营人员面对的生产环境会有不同。生产环境对稳定性和性能的要求远胜于灵活性。
2. 痛点是大家的： 更小、更频繁的变更，意味着更少的风险，更容易的回退。 - 发布管理：很多企业发布管理仅存在与口头沟通或共享的Excel。DevOPS中，发布需要清晰的准入条件，即：发布的风险、依赖、各阶段的完成标志。并且需要保证各个角色遵守事先规定好的流程。 - 发布/部署协调：DevOPS团队需要关注发布/部署过程中的执行。DevOPS团队需要跟踪发布状态，必要时尽快问题escalation，严格执行流程。 - 发布/部署自动化：DevOPS必须使用自动化发布/部署工具。自动化发布/部署工具应该可以在非生产环境下由非运维人员使用。
3. 协调机制 可以是人或者人配合制度、工具。传统的Project Manager需要更懂业务、技术。Product Manager需要兼顾项目风险评估、把控、预防，以及进度持续跟进。
4. 评估参考方法：（转自百度百科） - 开发应用所花费的最高时间：帮助理解可以多快得开发应用； - 失败部署的百分比：看出是否部署成功； - 客户ticket数：显示产生了多少问题； - 故障恢复的平均时间：显示从应用程序bug或者故障恢复需要多长时间； - 用户数：显示应用程序对于用户而言的有用程度。
