DevOPS就那么回事

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或者故障恢复需要多长时间；
- 用户数：显示应用程序对于用户而言的有用程度。