DevOps实践1：初识DevOps

一、DevOps的诞生

早期所采用的软件交付模型，称之为“瀑布（Waterfall）模型”。

瀑布模型，简而言之，就是等一个阶段所有工作完成之后，再进入下一个阶段。这种模型适合条件比较理想化（用户需求非常明确、开发时间非常充足）的项目。大家按部就班，轮流执行自己的职责即可。但是，项目不可能是单向运作的。客户会有新需求、产品也会有问题需要改进。

2001 年由软件领域的 17 位顶尖大师共同提出敏捷宣言，在敏捷宣言中，一个重要的原则是“频繁地交付可工作的软件，交付周期可以是数星期也可以是数月，推荐更短的周期”，并强调使用小批量任务进行增量发布，而非大规模的作业和瀑布流程的发布。同时，强调建立自组织的小团队，让成员在高度信任的环境中愉悦地工作。

敏捷运动的兴起，大幅度提升了软件开发效率，但在开发部门和运维部门的目标和动因之间存在的巨大冲突并未得到解决。开发部门通常负责对市场变化做出响应，以最快的速度将新功能或者变更上线。而运维部门则要以为客户提供稳定、可靠和安全的服务为已任，让任何人都很难甚至无法引入可能会危害生产环境的变更，这通常是产生技术债务（注1）的一个因素。

软件的快速迭代升级加速了“恶性循环三部曲”（注2），阻碍了业务目标的实现，不但波及公司的内部，而且还影响外部，导致质量低劣的软件和服务、糟糕的客户体验。

在管理和技术领域里所发生的精益运动、敏捷宣言、敏捷基础设施和Velocity大会、持续交付、丰田套路等重大事件的发展下， DevOps 应运而生。

二、DevOps的定义

DevOps由Development（开发）和Operations（运维）组合而成，被称为开发运维一体化。

维基百科对DevOps的定义是，DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

         

从目标来看，DevOps让开发人员和运维人员更好地沟通合作（破墙工具），同时通过自动化流程来使得软件整体过程更加快捷和可靠。

DevOps 基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系，并参考了高信任管理文化、服务型领导、组织变动管理等方法论。把所有这些最可信的原则综合地应用到 IT 价值流中，将DevOps 贯彻于整个技术价值流中，涉及产品管理、开发、QA、IT 运维和信息安全专员等不同角色，在更低的成本和努力下，保障产品的高质量、可靠性、稳定性和安全性。

三、DevOps的基础原则：三步工作法

第一步：流动原则

建立从开发到运维之间快速的、平滑的、能向客户交付价值的工作流。

为了最大程度地优化工作流，通过使工作可见、限制在制品数、减小批量大小、减少交接次数、持续识别和改善约束点、消除价值流中的困境和浪费，持续地优化全局目标。

第二步：反馈原则

在从右向左的每个阶段中，应用持续、快速的工作反馈机制。通过在整个价值流和组织中建立快速、频繁、高质量的信息流，包括反馈和前馈回路，可以让系统更安全。

在问题发生时识别问题，群策群力解决问题并构建新的知识，在源头控制质量，并且不断地为下游工作中心做优化。通过这种方式，我们能从源头控制质量，并在流程中嵌入相关的知识。这样不仅能创造出更安全的工作系统，还可以在灾难性事故发生前就检测到并解决它。

第三步：持续学习与实验原则

通过建立学习型组织和安全文化、将日常工作的改进制度化、把局部发现转化为全局优化、在日常工作中注入弹性模式、领导层强化学习文化，创造更安全的工作系统，也能承担更多的风险。不管是谁参与了工作，所有经验都可以持续地积累，组织里可以相互借鉴彼此的经验和智慧。

四、总结

本章描述了 DevOps 的诞生和定义，简单介绍了基础原则三步工作法。其中提升技术价值流的流动性对实施 DevOps 来说至关重要，而建立快速的反馈机制，对于实现技术价值流中的高质量、可靠性和安全性至关重要。三步工作法的第三步原则实现了学习型组织，实现了职能部门之间的高度信任和跨部门合作，接受了“复杂系统中总会发生故障”的事实，并鼓励谈论任何问题以建立一个安全的工作系统。第三步工作的成果不仅是获得了高绩效，而且还提升了弹性、员工的工作满意度以及组织的适应性。

在下期，我们将讨论从何处开始 DevOps。

注1：

技术债务：类似于金融债务，是指我们当前所做出的决定会导致一些问题，而这些问题随着时间的推移会越来越难解决，未来可采取的措施也越来越少。即使我们审慎地承担技术债务，也依然会产生利息

注2：

恶性循环三部曲：

第一部曲开始于 IT 运维背负技术债务。如应用程序和基础设施过于复杂、异常脆弱、文档不完备等。

第二部曲开发团队产生新的技术债务。如利用各种捷径完成紧急任务，导致的技术债务增加。

第三部曲工作质量持续恶化。工作耦合得更加紧密，即使是很小的行动也会导致较大的事故，更加害怕和拒绝做出变更。工作需要更多的沟通、协调和审批；团队必须等待更长的时间，等待相关的工作完成。