本文摘抄自《DevOps的概念与实践》
1. 什么是DevOps
通常是指新兴的专业化运动，这种运动提倡开发和IT运维之间的高度协同，从而在完成高频率部署的同时，提高生产环境的可靠性、稳定性、弹性和安全性。
2. DevOps与敏捷有什么不同
相对于瀑布开发模式，敏捷开发过程的一个基本原则就是以更快的频率交付最小化可用的软件。在敏捷的目标里，最明显的是在每个Sprint的迭代周期末尾，都具备可以交付的功能。（部署的高频率经常会导致部署堆积在IT运维的面前）
DevOps和敏捷软件开发是相辅相成的，因为它拓展和完善了持续集成和发布流程，因此可以确保代码是生产上可用，并且能确实给客户带来价值。
DevOps不仅仅创建了一个面向IT运维的工作流，当代码已经开发完成但却无法被部署到生产上时，这些部署都会被堆积到IT运维的面前，客户因此也无法享受到任何价值，而且，部署经常导致IT环境的中断和服务不可用。
3. DevOps与ITIL及ITSM有什么不同
ITIL：即IT基础架构库(Information Technology Infrastructure Library, ITIL，信息技术基础架构库)由英国政府部门CCTA(Central Computing and Telecommunications Agency)在20世纪80年代末制订，现由英国商务部OGC(Office of Government Commerce)负责管理，主要适用于IT服务管理（ITSM）。ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范。
ITSM：即IT服务管理，是一套帮助企业对IT系统的规划、研发、实施和运营进行有效管理的方法，是一套方法论。ITSM起源于ITIL（IT Infrastructure Library，IT基础架构标准库），ITIL是CCTA（英国国家电脑局）于1980年开发的一套IT服务管理标准库。它把英国在IT管理方面的方法归纳起来，变成规范，为企业的IT部门提供一套从计划、研发、实施到运维的标准方法。
在支撑IT运维的业务流程方面，ITIL和ITSM无疑还是最好的，实际上，它们描述了需要被IT运维支持的功能集合，这些功能集合足以支撑DevOps式的工作流。
DevOps的目标不仅仅只是增加变更的频率，而且也支持在不中断和破坏当前服务的基础上确保功能部署成功，同时也可以快速检测和修复缺陷。
4. DevOps与可视运维
可视运维是一个说明性的指南，该指南使得高性能IT运维能顺利实现“从优秀到卓越”的转换，关键点之一是如何控制和减少计划外的工作。
DevOps不仅聚焦在创建快速和稳定的计划工作流，而且DevOps也有一个更全面的方法来系统的消除计划外的工作，定义开发弹性准则，并负责管理和减少技术债务。
5. DevOps的基本原则
DevOps的支撑原则--DevOps的三个基本点
由IT推动的业务价值流，它始于需求定义，进行开发构建，又交给IT运维，最后以一种服务的形式交付给客户。
绝不传递一个已知缺陷至下游
- 强调整个系统的性能，而非将性能局限到特定的工作领域里。
- 关于创建从右至左的反馈回路，几乎所有的流程改进计划的目标都是缩短和放大反馈回路，以便可以持续进行必要的修正。
- 打造一种文化用来促进两件事：持续不断的探索精神，勇担风险的精神以及从成功和失败中来学习的能力，同时记得：重复和实践是融汇贯通的前提。
探索精神和勇担风险的精神可以确保我们持续改进，持续学习。
分配时间去改进每天的例行工作，培养一种奖励冒险精神的风气，同时主动引入故障到系统中，从而提高弹性。
6. DevOps模式的应用领域
- 将开发延伸至生产中--包括拓展持续集成和发布功能至生产，集成QA和信息安全至整个工作流，确保代码和环境可在生产中直接部署
- 向开发中加入生产反馈--包括建立开发和IT运营事件的完整时间表用于帮助事件的解决，使得开发融入无指责的生产反思，尽可能使开发可以自助服务，同时创建信息指示器来表明本地的决策如何影响全局的目标。
- 开发嵌入到IT运维中--包括开发投入到整个生产问题处理链，分配开发资源用于生产问题管理，并协助退回技术债务，并且开发为IT运维提供交叉培训，增加IT运维处理问题的能力，从而降低升级问题的数量。
- 将IT运维嵌入至开发--包括嵌入和联络IT运维资源至开发，帮助开发创建为运维使用的可重用的用户故事，定义一些可以被所有项目共用的非功能性需求。
7. DevOps的价值
3个业务优势：
- 产品快速推向市场
- 提高质量
- 提高组织的有效性：比如将时间花在价值增加活动中，减少浪费，同时交付更多的价值至客户手中。
8. 信息安全和QA如何融入DevOps的工作流
DevOps的高部署频率通常会给QA和信息安全带来很大的压力！
相较于标准的功能单元测试，DevOps工作流依赖于检测和恢复更多一点。当开发以软件套件的方式交付的时候，部署变更和补丁就比较困难，同时QA也严重依赖代码检测来验证功能的正确性。另一方面，当软件以服务的形式交付，缺陷就可以被很快修复。而且，QA可以减少测试依赖，取而代之的更多依赖缺陷的生产监控，只要缺陷能被快速的修复。
代码故障恢复可借助于“功能标签”等手段，通过以配置的形式来启用或禁用某些代码功能，从而达到避免推出一个全功能部署，而只部署通过测试的功能至生产。
当功能不可用或性能下降等情况时，依赖于检测和恢复进行QA将会一种更好的选择，但当出现损失保密性或数据和系统不一致性的时候，就需要在部署之前进行充分的测试，而不是检测和恢复了！