DevOps面面观

什么是DevOps？众说纷纭

• WikiPedia上说：“DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。”
• 百度百科说：“DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。”
• IBM这样说：DevOps是企业必备的持续交付能力，通过软件驱动的创新，保证组织抓住市场机会，同时减少反馈到客户的时间。

DevOps不只是开发与运维的问题

一般而言，开发与运维有着不同的文化：开发部门的驱动力通常是“频繁交付新特性”，而运维部门则更关注IT服务的可靠性和IT成本投入的效率，降低风险。两者目标的不匹配，在开发与运维部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度。运维从维稳出发，自然希望生产系统部署上线次数越少越好，而上线频度降低，对开发人员是一个负激励：反正我发布的版本也不会上线，反正我再积极也不能实时的体现出来，团队积极性和人员士气都会受到打击。

与此同时，业务部门则希望业务需求尽快的推向市场，而维稳的要求导致价值交付用户的速度被延缓，价值无法迅速得到反馈验证。

当发布列车变成3个月一趟车次时，业务人员习惯于自己的需求无法快速得到满足，能想出的方法就是把所有的业务需求都设置成最高优先级，去抢占发布窗口。所有人都这样想这样做，拥堵就此产生，真正高价值的需求无法得到快速交付。（试想，如果每天有十次发布，大家还会拼得头破血流去抢一个发布窗口么？）

上线频度低的另一个副作用是，单次上线中包含的变更规模变大，风险也随之增加。事实上，减少上线次数不仅不会降低风险，反而让每一次上线都变得像一个火药桶，危机四伏。

从大处着眼

究其根本，DevOps目的是提升业务交付能力：

• 如何快速的交付想法？
• 如何让客户进行尝试（从而获取反馈）？
• 如何快速响应客户反馈？

DevOps不应该只是IT内部的几个部门玩的游戏。必须跳出IT的角度，端到端（业务端到客户端）分析，才能弄清公司需要依靠IT的哪些工作来支撑业务目标，支撑企业战略 ，从而实现更完整、真正的DevOps。需要将IT变成一种能力，融入公司的日常运作中，融入业务活动中。在快鱼吃慢鱼的时代，需要快速试错，不断整合来自市场的反馈。

所以最终，DevOps是一个端到端的问题，是产品管理部、开发部、测试部、IT运维部、信息安全部协同工作、共同支持。DevOps尝试建立一个业务价值交付管道，业务规划、需求梳理、计划、开发、构建、测试、部署、运维、监控 ，在此交付过程中涉及到的部门/团队、过程、系统、方法都归属于DevOps关心的内容。

从小处下手

理解了DevOps是一个端到端的过程，我们就会发现整个交付链条涉及太多的领域，导致问题也层出不穷，无从下嘴。因此在实际操作中，我们需要有一个切入点

DevOps的思想以精益与敏捷为核心，通过暴露问题、解决问题，从而实现持续改进。从精益的角度看，在代码投产之前，实际上未产生任何价值，都只是半成品。 要限制半成品，即在制品（WIP）数量，让其尽快流过生产线，让投入产生交付价值。

DevOps是一个复杂问题，我们却希望可以把一个复杂的问题简单化：正如装修时通过加压检查管道是否泄露，是否有阻塞，我们也通过加压的方式来暴露软件交付管道的问题。那么如何加压？以终为始，我们选择业务价值交付的那个点，也就是部署与发布来对整个交付管道进行加压。团队可以简单的问自己一个问题：“能不能一天部署10次？”如果没有办法？那么原因何在？流程不规范？自动化不够？沟通导致效率低下？过程无法复用？环境差异导致回归出错？逐一的暴露问题，解决问题，交付能力自然提升。

需要注意的是，根据《凤凰项目》中提到的TOC约束理论（Theory of Constraints），在瓶颈之外的任何地方做出的改进都是假象，在瓶颈之后做的任何改进都是徒劳的，因为只能干等着瓶颈把工作传送过来，而在瓶颈之前做的任何改进则只会导致瓶颈处堆积更多的库存。所以如何识别真正的瓶颈变得尤为重要，在发现问题之后多问几个为什么，力求找到根源原因。

• DevOps的由来

  Flickr公司的约翰·阿尔斯帕瓦和保罗·哈蒙德在2009年Velocity技术大会关于开发速率的一场演讲，“一天十次部署”，是2009年前后兴起的DevOps运动的一部分，提倡开发和IT运维通力协作，在完成高频率部署的同时，提高生产环境的可靠性、稳定性、灵敏性和安全性。2009年一天十次部署就算很快了，但现在只能算平均水平，2012年亚马逊公司宣布，他们平均每天能开展23000个部署。

  公司	部署频率	交付周期
  Amazon	23000次/天	分钟
  Google	5500次/天	分钟
  NetFlix	500次/天	分钟
  Facebook	1次/天	小时
  Twitter	3次/周	小时
  一般企业	1次/9个月	月、季度

  Wikipedia上说，有以下几方面因素可能促使一个组织引入DevOps：

  • 使用敏捷或其他软件开发过程与方法
  • 业务负责人要求加快产品交付的速率 （新兴技术趋势，例如云计算、移动应用、大数据和社交媒体）
  • 虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍
  • 数据中心自动化技术和配置管理工具的普及
  • 传统的管理方式导致“烟囱式自动化”，从而造成开发与运维之间的鸿沟

通过加大部署/发布频度来撬动整个交付过程

以应用部署自动化作为切入点，由部署自动化，往前倒逼测试自动化、构建自动化；进一步往前，配置管理、变更管理是基础要求；再往前，业务需求与敏捷计划同步关联，通过短周期迭代交付与反馈，加强业务与开发的协作沟通。

同样的，往后端与运维衔接，更小、更频繁的变更，需要让开发人员更多地控制生产环境，更多地以应用程序为中心来理解基础设施；需要定义简洁明了的流程，并尽可能地实现自动化，从而在完成高频率部署的同时，提高生产环境的可适应性。与此同时，可靠性、稳定性、弹性和安全性也同时提升。

由此也促成了开发与运维的协作，通过不断缩减批量规模，实现快速工作流，确保了部署环境时刻准备就绪，按需投产。频繁的发布、意味着每次发布包含的变化更少，每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长，逐步协调和弥合开发与运维之间的技能鸿沟和沟通鸿沟。

DevOps要实现：自动化、标准化、配置化

• 自动化：全面自动化，构建、部署、测试、升级、扩展、维护、监测、安全和策略管理。通过自动化，倒逼团队高效沟通，倒逼流程规范；自动化手段确保部署任务的可重复性、减少部署出错的可能性。
• 标准化：（流程，环境，配置）基础环境标准化，运行环境标准化，应用环境标准化/多样化。
• 配置化：通过配置，尽量避免代码，通过功能开关或者参数设置，来支持A/B testing、灰度发布。

DevOps与云

DevOps要支持云，虚拟化与云技术可以带来DevOps要求的标准化以及自动化。

• 环境标准化

  无论是针对基础设施还是运行时环境都要求环境标准化，并把这些环境投入开发、QA和IT运维的日常使用，这样就能消除大部分在部署流程中因为差异而导致的问题。不仅应该拿出可部署的代码，还应该拥有部署这些代码的确切环境，并在版本控制中一并控制与检查。

• 混合云下的DevOps诉求

  在云的场景下，如何利用虚拟化、容器等技术加速环境的创建以及标准化，如何通过自动化的方式加快环境搭建，如何在On-Prem、私有云、公有云，不同厂商不同类型的云的混合模式下，统一流程，统一DevOps的用户感受。

  同时，由应用层的自动化部署，同样可以发现Infrastructure层、Runtime层的问题，虚拟化与云的技术也与DevOps相辅相成，相得益彰。

• 华为云CodeArts服务

  CodeArts提供软件开发全生命周期的云端DevOps工具链，帮助团队真正实现自动化，标准化，配置化。

  CodeArts提供基于Git的版本控制系统，不只将代码版本化，而是版本化管理一切与环境有关的配置。

  CodeArts提供可自定义的自动化部署流水线，提交代码自动触发，帮助团队实现持续交付，为团队带来自动化，标准化。

DevOps实践

• 不做什么比做什么更重要：相比起向系统中投入更多的工作，将无用的工作剔出系统更为重要；无用的工作、无用的项目、无用的产品，排优先级，筛选出哪些是真正重要的工作。
• 运维参与研发评审：常见的现象是，运维人员很少被邀请参与架构决策或代码评审，开发代码是否会影响运维环境前期无人知晓，需要让运维人员参与架构评审，从运维角度提出对系统的要求。
• 非功能性需求同样重要：偿还技术上的债务。每个人都像重视功能性要求一样重视非功能性要求QoS（质量、稳定性、可维护性、持续性、可扩展性、可管理性、安全性、可操作性），非功能性需求对于实现业务目标同等重要，要把非功能性需求设计到产品当中。
• 整体协作：产品所有者、开发部、QA、IT运维部以及信息安全部通力协作，帮助彼此乃至整个企业取得胜利。
• 质量为先：上游团队不再给下游团队造成麻烦，开发部将20%的时间用于帮助确保工作顺利的通过整个价值流，加快自动化测试，改进部署基础架构，并确保所有应用程序建立有用的产品遥测。
• 基础架构即代码（Infrastructure as a Code）：
  • 把创建和部署流程自动化，把基础架构当成代码一样对待。
  • 各套环境之间，代码版本、运行时、环境配置需要匹配。
  • 需要将基础环境配置化、版本化管理。
• 运维服务化：DevOps会让开发部门承担更多的代码部署和维持服务水平的责任，要求把许多IT运维任务转变为自助服务。
• 版本化一切（Versionlize Everything）：应该把所有东西都进行版本控制，不只是代码，而是创建环境所需的每一样东西。
• ITIL：为了适应DevOps更短的交付周期和更高的部署频率，ITIL流程的很多方面都需要自动化，特别是变更、配置和发布流程等。
• 云计算：有效的利用云技术，可以为开发和测试人员动态设置基础架构资源，快速获得测试环境。
• 针对类生产系统进行开发和测试 （环境的标准化），利用可重复的可靠流程进行部署，监控并验证运维质量；
• 放大反馈回路：快速反馈回路，防止问题代码进入生产环节，并且让代码能够迅速部署投产，从而迅速发现并修复任何产品问题。（编写代码时，单元测试、集成测试、验收测试一直在类生产环境运行，不断确认，代码和环境将会按照预先设定的运行，并且总是处于可部署状态）

  

DevOps与精益、敏捷

DevOps是基于敏捷与精益原则的方法。DevOps是软件开发生命周期（SDLC）从瀑布式到敏捷再到精益的发展。

DevOps超越了敏捷，它的关注点是从SDLC中移除浪费。通常情况下，发现浪费或者瓶颈的形式包括：不一致的环境、人工的构建和部署流程、差的质量、IT部门之间缺少沟通和理解、频繁的中断和等待、部分完成的工作、额外的功能、任务切换等。

DevOps强调流水线，交付管道，与传统生产与制造业有着千丝万缕的联系。

DevOps实施中，可以借鉴精益理论中的很多思想，例如：降低批量规模、减少半成品、缩短并增强反馈回路、价值流图分析、时间线分析、消除浪费，以及敏捷中持续集成、持续测试、持续交付、持续监控、A/B测试、灰度发布、滚动更新等。

三步工作法

目前行业中通常采用三步工作法以实现DevOps：

• 第一工作法：帮助理解在工作从开发移向IT运维时该如何建立快速工作流。

  从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，需要小的批量规模和工作间隔，绝不让缺陷流向下游工作重心，并且不断为了整体目标（相对于开发功能完成度、测试发现/修复比率或运维有效性等局部目标）进行优化。

  必要的做法是：看板、持续构建、集成以及部署，按需创建环境，严控半成品，以及构建起能够顺利变更的安全系统和组织。

• 第二工作法：如何缩短以及放大反馈环路，从而在源头解决质量问题。

  价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防治问题再次发生，或者更快的发现和修复问题。这样我们就能在所需支出获取或潜入知识，从源头上保证质量。

  必要的做法是：

  • 在部署管道中的构建和测试失败时“停止生产线”。
  • 日复一日的持续改进日常工作。
  • 创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态。
  • 在开发和IT运维之间建立共同的目标和共同解决问题的机制。
  • 建立普遍的产品遥测技术，让每个人都知道，代码和环境是否在按照设定运行，以及是否达到了客户的目标。
• 第三工作法：如何建立文化，既能鼓励探索，从失败中吸取教训，又能理解反复的时间是精通工作的先决条件。

  创造公司文化，带动两种风气的形成：不断创世，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。不断加压，从而强化习惯并加以改进。（系统里要经常出些故障，长此以往，再遇到困难就没原来那么痛苦了。）

  必要的做法是：营造一种勇于创新、敢于保险以及高信任度的文化，把至少20%的开发和IT运维周期规划给非功能性需求，并不断鼓励进行改进。

KPI与度量

为了促进DevOps战略，调整绩效考核和激励机制是必要的，按各自为政的KPI考核只会造成部门之间的隔阂，只根据敲出代码的生产力来奖励开发人员，或者根据基础设施的可靠性来奖励运维人员，什么都无法改变；围绕业务系统而不是职责来组织工作，这就是DevOps打破IT分组壁垒的寓意。 团队一起协作，共同为他们的应用和系统负责。

以下是部分度量参考：

• 开发应用所花费的最高时间（开发速率）
• 失败部署的百分比（部署成功率）
• 客户产生了多少问题（客户接受度）
• 故障恢复的平均时间（团队解决故障的能力）
• 用户数（用户欢迎度）