DevOps实践精要（DevOps Master认证讲义知识精解）

DevOps是什么？DevOps是如何产生的，DevOps的理论基础是什么，与敏捷和精益的关系是怎样的？DevOps的应用和实践，可视化看板、流水线、在制品限制、持续迭代等。DevOps Master认证考试讲义精解

DevOps 实践精要

• 什么是DevOps
  • IT管理的转变
    • IT管理方法不是一成不变的。信息系统开发和运维所使用的方法与几十年前明显有别
    • IT管理从聚焦于IT系统，转变为聚焦于管理IT服务
  • IT实践的发展
    • 新涌现出来的实践，被打上了“DevOps”（开发+运维）的标签
    • DevOps的内涵，已经大大超出其原始的含义
    • 如同ITIL 超出 “ 库 的概念、 COBIT 超出受控对象的含义一样，
  • DevOps的起源
    • DevOps的出现源于两个因素
      • 敏捷软件方法的广泛采用
      • IT 基础设施即程序代码的管理方式
    • 瀑布软件开发模型
      • 每个阶段所涉及的人员职能 被专业化分工
      • 当开发的是功能可预先定义、对快速产品交付没要求的大型信息系统时 这个模型能够确保我们创建高质量产品，并进行有效与精细的成本控制
      • 有效应对市场机会而不延误截止日期、不降低产品质量，极为困难
      • 瀑布模型示意图
    • 经典的项目管理约束金字塔
    • 基线编程（XP）
      • 只关注在软件开发周期的其中一个阶段上
        • —— 即实际开发阶段
    • 敏捷软件开发方法
      • 优点
        • 端到端的软件开发周期进行了简化加速
        • 极大地加速与促进软件的开发和重构
        • 更重视左项的价值
      • 敏捷宣言
        • 个体和交互 胜于 流程和工具 可工作的软件 胜于 面面俱到的文档 客户协作 胜于 合同谈判 响应变化 胜于 遵循计划
      • 敏捷原则
        • 通过持续不断地及早交付有价值的软件使客户满意
        • 欣然面对需求变化，为了客户的竞争优势，敏捷过程掌控变化
        • 经常地交付可工作的软件，倾向于采取较短的周期
        • 业务人员和开发人员必须相互合作
        • 激发个体的斗志，以他们为核心搭建项目
        • 提供所需的环境和支援，辅以信任，从而达成目标
        • 传递信息效果最好效率也最高的方式是面对面的交流
        • 可工作的软件是进度的首要度量
        • 敏捷过程倡导可持续开发
        • 坚持不懈地追求技术卓越和良好设计
        • 极力减少不必要工作量的艺术
        • 最好的架构、需求和设计出自自组织团队
        • 团队定期地反思如何能提高成效
      • 敏捷开发的关键要素
        • 客户与开发者之间更紧密的交互
        • 批量大小的降低
        • 以短间隔（周期）交付的产品
        • 团队的有限规模
      • 使用敏捷方法
        • 软件开发团队每隔2到4周发布一个新的可行产品
        • 最终用户可以更近距离地参与到开发过程当中
        • 快速的反馈，并由此激发更快速的变更
      • 使用敏捷的误区
        • 敏捷收益缺失，通常与瀑布的优势或者敏捷的劣势无关
        • 在开发之前还有不少的环节，要关注项目的全价值链
        • 在开发之后应用需要快速部署到生产环境 以便客户能接收到向他/她们承诺的所有收益
        • 获取IT预算是一件十分困难的事情，新采购的预算流程过长
        • 触碰IT基础设施相当不安全，变更对IT运维部门来说很困难
        • 先进的软件开发方法由于IT运维侧的阻碍而停滞不前
      • 管理基础 设施即代码
        • 两种技术的涌现
          • 虚拟化
            • 虚拟化使有效地使用硬件成为可能
            • 在系统软件之间引入了额外的抽象层
          • 云计算
            • 按需的自服务
            • 宽泛的网络接入。
            • 资源的池化。
            • 快速的伸缩性
            • 可度量的服务。
  • DevOps定义
    • DevOps是敏捷软件开发与精益生产思想的一种演进
    • 应用到IT端到端的价值链中，使得业务基于现代信息技术，通过文化、组织与技术变革而获得更大的成功
    • DevOps的4大要点
      • DevOps并没有取代敏捷及精益实践
      • DevOps本质是IT部门与业务部门所考虑不仅是软件开发，而是整个价值链
      • 应用DevOps所获得的预期价值也很重要
      • 关注3大基本要素：文化、组织和技术手段
    • DevOps关注的3个基本要素
    • DevOps的价值体现
      • 加速新产品及产品补丁面向市场
      • 更快响应客户需求
      • 改善IT系统可用性与可持续性
      • 更高效使用有限资源
    • DevOps内涵
      • a. 敏捷软件开发与精益生产思想的一种演进，
      • b. 应用到IT端到端的价值链中，
      • c. 使得业务基于现代信息技术，
      • d. 通过文化、组织与技术变革而获得更大的成功
  • 为什么要实施DevOps
    • 背景：时间跨度包含的环节
      • 针对一种或若干种业务想法构建、起草方案，并进行论证；
      • 评估和选择一个业务想法来实施；
      • 规划实施所需要的行动，并获取资金；
      • 准备人员和业务流程；
      • 与此同时：规范化需求、开发原型、初始化测试、开发完整特性的IT系统、 全面的测试、发布和部署；
      • 与此同时：进行市场活动、准备市场营销、准备销售渠道和工具
      • 发布新的产品或服务
    • 好处一：缩短市场响应时间
      • DevOps的相关技术
        • 降低批量大小
        • 减少移交次数
        • 持续识别
        • 消除损耗
      • DevOps组织遵循 “ 为速度而优化（Optimize for speed） 的模式
      • IT部门被视为一个真正的业务伙伴而非成本中心
    • 好处二：减少技术债务
      • 当程序员选择一个非最优的方式来解决问题以缩短开发时间时，技术债务就产生了
      • Martin Fowler的技术债务矩阵
      • DevOps密切关注如何减少技术债务，或者说是管理技术债务
      • 如何实现
        • 持续重构程序代码，将运维中获得的经验吸纳进来
        • 规划相应的工作来消除之前出现的瓶颈
        • DevOps强烈推荐应用“尽可能频繁地直面问题”的实践
    • 好处三：消除脆弱性
      • 现状
        • 大多数组织的IT基础设施处在非常脆弱的状态
        • 混乱其实就是这个时代下公司信息技术领域日常的真实写照
        • 在传统范式里，新代码在测试证明它可工作之前，是不可运维的
      • 脆弱的原因
        • • 技术解决方案是多年以来逐步地、基于不同组件基础之上构建的；
        • • 使用大型的第三方系统，针对公司目标进行了大量的定制；
        • • 使用内部开发的遗留系统，而关键的程序员和团队已经不在公司了；
        • • 大量的系统以非常繁杂的方式相互耦合在一起， 并且与外部数据源及消费者集成；
        • • 由于需要快速实施的需要以及预算的限制，解决方案的质量经常不是最优的；
        • • 维护与支持工作增加了许多临时变通方案（“拐杖”）， 仅考虑让系统能运行下去；
        • • 程序代码、架构、基础设施、技术解决方案乃至合同责任的文档，非常不尽如人意。
      • 如何做到
        • DevOps提出以最激进的方式改变IT系统的脆弱性，即完全消除它
        • DevOps中代码与系统作为一个整体，在任何时间都是完全可运行的
        • 反脆弱系统可以从功能障碍和混乱中持续演进
      • 反脆弱实践
        • 弹性系统的设计，是基于它们固有的复杂性和脆弱性
        • 设计容忍失败和灾难恢复的机制，这样就不用太 担心失败可能造成的负面影响
        • 在生产环境有意引入混乱与不稳定性
    • DevOps着力处理的三个任务
      • 缩短市场响应时间
      • 减少技术债务
      • 消除脆弱性
  • 关于DevOps的一些误解
    • DevOps是敏捷的一部分
      • 目标很简单：更频繁地交付价值
      • DevOps把“敏捷开发”的想法延展到了整体的敏捷IT交付、 整个组织、整个流程以及整个价值链
      • 从DevOps 中获得回报，通常需要更大的公司文化变革
      • DevOps的目标集，并不仅限于加速交付，还包括减少技术债务和消除脆弱性
    • DevOps是工具和自动化
      • DevOps确实依赖于某种自动化工具的可用性与有效性
      • 但是没有也不可能有一个放之四海而皆准的DevOps必选软件列表
      • DevOps具体实施可以独立于工具软件
    • DevOps是一个新的职业
      • 具备实施软件交付流水线的能力，也不能保证取得成功
      • 实施DevOps的实践，也不太会节省成本
• DevOps理论基础
  • 精益生产
    • 含义
      • 精益生产可以被缩小为识别与消除浪费
    • 浪费的三个层面（3M）
      • Muri （超负载）
        • 价值存疑的工作
      • Mura （不均衡）
        • 不均衡的需求水平， 这些需求分散着、波动着
      • Muda （浪费）
        • 工作期间发生的浪费
    • 浪费类型的对比
    • 工作中的浪费
      • 管理成本（基本上是由管理者而非员工完成的任何事情）；
      • 不满足客户期望或需求的产品或服务（与品质的经典定义一致）；
      • 未发挥员工的潜在创造性和智力；
      • 未能调动员工的资源来改进流程和技术；
      • 不充足的员工培训；
      • 使用不正确的度量，或根本没有使用度量；
      • 对信息系统的低效使用（低质量的自动化及对信息技术的无效应用产生的浪费，如工作期间的游戏与社交聊天）
    • 精益生产思想的实际应用
      • 使用专门工具来识别浪费；
      • 应用其他的专门工具来消除或减少浪费；
      • 利润！！！
  • 敏捷
    • 事实
      • 组建小的独立且自给的团队（最多10～12人）
        • 聚焦于有限的范围
      • 通过基于冲刺（Sprint）的迭代过程，创建并测试程序代码
        • 每个迭代交付出一个可行的产品
      • 维护一个功能与非功能需求的列表（backlog），作为下个迭代计划的输入
      • 把大的任务分解为小的部分（故事），以约定的工作负载单位进行评估并排序
      • 客户代表积极参与到过程中
      • 团队定期召开短时间的站立会议，讨论任务计划、进展与当前困难
      • 进行定期的回顾，以帮助团队自我学习及改善其工作
    • 挑战
      • 敏捷仅覆盖到价值链的一部分，这也导致了总 体效果的差强人意
      • 敏捷开发方法并未考虑到信息技术运维工作的特点与复杂性
        • 对于运维来说方法的可应用性有所下降
      • 团队的工作就会被限定为固定重复的工作迭代，精神上的满足感越来越少
    • 敏捷带来的问题
      • 许多检视失败的发起人处在直接的商业利益当中
        • 假装敏捷不是一项业务
        • 掩盖困难与负面案例
      • 没有说清楚有些实践可行或不可行的上下文，不断回归教条化
      • 价值主张模糊且未经证明
      • 想当然地进行规模化
      • 增加及累积技术债务
    • 相关框架
      • Scrum
      • LeSS、SAFe
    • 如何解决敏捷框架中的问题
      • 去应用实际知识与技能
      • 促进敏捷实践进一步演进到DevOps中
• DevOps原则
  • 价值流
  • 部署流水线
    • 实施部署流水线带来的挑战
      • 忽视理念（流程、人与文化）的对自动化的过度热情
      • 没有足够的已开发的测试来确保流水线的稳定运行
      • 实施后期，测试运行过多，导致一个变更流经流水线花费时间过长
  • 一切都应存储在版本控制系统中
  • 自动化配置管理
    • 任何环境的任何变更，只能通过存储在版本控制系统里的脚本来实施
    • 所有的变更都需要受控，系统可以被快速地重置到稳定状态
  • 完成的定义
    • 要等到客户接收到或者开始接收其所预期的价值才算完成
    • 意味着整个价值流已经被完整地流经，一直到生产环境
    • 有助于团队将工作聚焦在结果即客户价值上
    • 消除掉对具体领域工作的有限的责任
      • 取而代之的是对团队整体结果的共有责任
• DevOps关键实践
  • 和传统实践的关键区别
    • 发布是日常活动
      • 文档化一切变更
      • 计划专门的措施，以及开发按步骤操作指南以便恢复系统
      • 根据确认过的变更时间排期来进行发布计划
    • 发布是业务决定
      • 蓝绿部署
        • 在生产环境中有两套拷贝：“绿”和“蓝”。
      • 金丝雀发布技术
        • 即新功能首先针对一小部分用户可用，
      • A/B测试验证业务假设
        • 即一部分用户（参考组）使用老的版本
        • 另一部分（试验组）采用新的版本
        • 测试并验证业务想法，并在系统后续的开发中进行调整
    • 一切都是自动化的
      • 自动化操作包括
        • ● 创建环境（测试环境、中间环境等）；
        • ● 配置基础设施组件；
        • ● 执行测试；
        • ● 部署和分发，包括监控工具的配置
      • 对DevOps而言，提升管控级别至关重要
      • 应该自动化一切手工操作
    • 事件是立即被解决的
      • 当某些事情“破坏”了基础设施时，此时的决策是断开失败的组件
      • DevOps意味着最大化地将物理硬件进行虚拟化
    • 缺陷是立即被修复的
      • 系统必须总是可工作状态 ，为了控制技术债务，绝大多数缺陷将被设置优先级以便尽快修复
      • 立即修复缺陷需要对计划、排序以及运维进行大规模的优化调整
    • 流程是持续更新的
      • 传统项目管理流程优化严重滞后
      • DevOps理念中识别出来的流程短板都应该立刻消除
      • DevOps建议尽可能地重复执行可能存在问题的步骤， 有助于更好理解应该如何改进，并对工作进行调整
    • 像初创公司一样行动
  • 非同寻常的团队
    • DevOps团队是一个令人吃惊的作战单元
      • DevOps团队负责一个小的但是清晰定义的IT系统或是IT基础设施
    • 一个DevOps团队不是临时的项目团队；而是为长期存在而组建的
      • 团队的存续周期不是预先设定，也不是固定的
    • DevOps团队是跨职能的
      • 意味着团队有能力完成所负责的领域价值流上的所有工作
    • 团队的大小非常重要
      • 团队不能太小，太小的团队无法形成跨职能
      • 超过二十人的团队很难协调，或是需要管理层级，或是逐渐拆分成子团队
      • 大型团队要承受额外的沟通成本、以及团队成员之间不可避免的信息丢失
    • 自管理的团队
      • 团队应该有能力独立地解决浮现出来的所有管理问题，并且在遇到困难时积极寻求专家或是导师的支持
      • Scrum Master不是一个特定的人员，而是一个角色
    • 面对面沟通
      • 整个团队坐在同一个房间，让每天的每个人之间的接触无可避免
      • 低质量的工作、缺陷、事故将不只是被发现并登记在某些信息系统中，它们会立即得到更正
    • DevOps团队的关键特性
  • 工作可视化
    • 看板
      • 从看板可以观察出有哪些地方不正确地采用了DevOps 方法
      • 如果优先级排序是错误的，进入价值流的待办事项马上就会超载
      • 将看板和精益原则的推动式系统相结合
      • 若有大量的任务需要显示并追踪，看板将变得不可读
    • 可视化的好处
      • 可以构建拉动系统
        • 改善工作流；
        • 减少停滞时间；
        • 减少协调的需要
      • 改善正在进行中任务的透明度；
      • 改善对剩余工作以及当前状态的了解；
      • 改善优先级排序；
      • 降低交接次数；
      • 有助于识别效率低下的环节；
  • 限制在制品（WIP）
    • 长待办清单会造成
      • 需要频繁地评审任务优先级的混乱产生
      • 频繁地在任务间切换
      • 频繁地由于外部因素 而变更优先级
    • 任务切换需要增加额外的时间重新排列优先级，以及切换内容上下文
    • 多任务模式极大地增加了任务的持续时间
    • 在价值流的每个阶段基于已接受任务的总数来进行人为限制，被称为WIP限制
    • 工作中的浪费
      • 去做没有客户要的工作，是一种浪费
      • 在空闲时间捡起一个任务，稍后再搁置，也是一种浪费
    • HiPPO（Highest Paid Person’s Opinion）
      • 工资最高那个人的意见
    • 工具
      • 累积统计团队速率
        • 累积流图
      • 管理WIP
  • 减小批次大小
    • 大的批次很少是同样大小的，甚至小到所谓的单件流。
    • 由于小的批次降低了价值流中的等待时间，首次交付的时间以及总体的前置时间都会得以缩短
    • 小的批次减少了进行中任务的总数
    • 小的批次降低了缺陷数量
    • 批次越小，返工引起的浪费也就越少
  • 留意运维需求
    • 常见的非功能性需求集合
  • 尽早检测并修正缺陷
    • 当测试尽可能多地被自动化时，会收获最大的收益
    • 测试环境应该尽可能准确地与生产环境保持一致，以快速发现缺陷
    • 测试“左移”
      • 更有效的组织测试，以最大化地在早期阶 段发现最常见的错误
  • 管理的而不是受控的改善和创新
    • 为什么需要持续改善
      • 流程有自我恶化的趋势
        • 员工不只是在技术方案上抄捷径，也会在工作方式上这样做
      • 外部因素变化频 繁
      • 信息技术自身也在快速进化
      • 技术债务需要被消减，工作需要被改进，新的技术需要被掌握
    • 改善闪电战（Kaizen Blitz）
      • 用于改善的时间未必是事先规划的，而是按需分配
      • 引入外部参与者，外部的视角能够帮助将问题挪出死角
      • 专注于消除识别出来的不足与瓶颈
    • “黑客马拉松”
      • 分配一段特定的时间，专门用来探索新的技术，并尝试创造出新的产品和工具
      • 对内部采用的技术进行大量优化，简化架构并消除日益累积的依赖
    • 两个重要的观点
      • 这一实践需要被管理，而不是听之任之；
      • 你公司的实践，很可能与其他的组织不同；
  • 为创新提供资金
    • 及时且充足的资金是任何举措的前提
    • 传统的决策，是基于预算周期的中长期计划做出的
    • 传统预算模式意味着在部门和团队之间激烈的竞争
    • 不受限的资金以及期限，不足以产生有竞争力的让消费者趋之若鹜的产品
  • 任务优先级
    • 传统的方式
      • 分析任务
        • 评估
          • 比较并排序
            • 获取审批或允许
    • 传统方式的弊端
      • 导致严重的延期
      • 任务的信息会随着时间演进而趋于过时（决策耗时越长，它基于的数据就越不可靠）
      • 这些步骤的重要性被严重夸大
      • 一个长时间的初始评估阶段，催化了一种混合模式，被称为Water-Scrum-Fall
    • 问题产生的原因
      • 收益的评估并不容易
      • 需要预估任务需要多少资源也很困难，特别是首次做的那些任务
      • 把急迫性从考虑范围移除会非常危险
    • 排序最基本的原则
      • 鼓励降低批次大小，保留价值
      • 加速产品交付
      • 确保更均衡的工作负载
    • 延期成本（CoD，Cost of Delay）
      • 对做出决策的重要性进行经济评估
      • 可以用财务回报进行预测
      • 要考虑到价值随时间的动态变化
      • 得到了CoD指标的数值，就很容易在不同任务之间进行比较
      • 拥有较高CoD的任务应该进入队列
    • CoD除以持续时长（CD3，Cost of Delay Divided by Duration）
    • CoD方法的优势
      • 对一个正处在价值流最初始阶段的任务进行计算很容易
      • 经济化的决策对所有人都保持透明
  • 持续识别、发掘并评估约束
    • 限制价值流上的任务，从而不要让瓶颈过载
    • 我们需要发现消除瓶颈的办法，摆脱它
    • 当消除了识别出来的约束，就可以取消先前建立的短期规则，开始寻找下一个最显著的瓶颈
• DevOps实践应用
  • DevOps适用性及限制
    • 不适宜使用DevOps的情况
      • DevOps不是特别适合那些自己没有软件开发团队的组织
      • 组织使用它们自己的软件，而开发者并非自有员工
      • 单体的、紧耦合的IT架构
    • 制约采纳DevOps的因素
  • COTS现成商业软件
    • “最小化自主软件开发并且尽可能多的采购现成软件”的原则
    • COTS的使用会成为采纳DevOps的严重阻碍
    • DevOps与COTS的“兼容性”
      • 不要在战略地位的业务线上使用COTS
      • 在你重要的业务领域中消除COTS，迁移到自主软件开发
      • 针对相关的应用以及它们的管理策略
        • 开放式应用
        • 平台式应用
      • 减少手工和复杂的安装与配置，使用可控的脚本自动化部署
  • DevOps指标度量
    • 关键指标
      • 前置时间
      • 工作负载
      • 产品质量
  • 架构演进
    • 单体架构
      • IT系统的任何文档很快就变得过时
      • 众多的开发人员并行工作在系统功能上，在各自的部分都需要资源来进行协同
      • IT系统的开发和运维以自然的方式切割 运维以及支持的员工无法介入复杂的系统架构细节
      • 很难识别小的自主团队能负责的领域，因而敏捷开发最主要的好处也被抹杀
      • 由于大量的强关联，改变和发展架构变得异常困难
    • 面向服务的架构（SOA）
      • 存在很高的复杂性，而这让它们很难适用于DevOps实施中
    • 微服务架构
      • 服务之间完全通过指定的程序接口或消息队列进行通信
      • 任何服务都不应该知道其他服务的内部实现或是对其有任何的依赖
      • 遵循“ 无共享 的原则
      • 修改任意的服务都可以独立于其它的服务进行
      • 让遵循DevOps的基本原则成为可能，如：价值流、部署流水线、自动化配置管理
      • 容器化的引入对近些年微服务架构的扩展产生了巨大的贡献
  • DevOps与ITSM
    • 误区: DevOps与ITIL不兼容
      • DevOps 实践可以与 ITIL 流程相互兼容。
      • ITIL 流程中的许多⽅⾯可以完全通过⾃动化实现
    • IT服务管理的关键原则
      • 由IT以服务的方式来交付业务价值
    • 极致情况下，IT与业务之间的边界完全消失
      • BizDevOps
  • 货物崇拜
    • 盲目注重形式而非目标的意义及原则的行为，被称为货物崇拜
    • 团队寻求去掌握一种新的管理实践，却没有把足够的精力放置在“管理”上
  • 以价值流为核心
    • 了解并发现了需要改进的领域，就有可能演化出价值流的理想版本
    • 工作改进不应该被视为是一次性的事件，而是永久可持续的工作
    • 为移除限制并最小化浪费，可以选取那些最适合的工具。
• 结论与总结
  • DevOps并非包治百病的良药
  • DevOps主要解决三个急迫并且复杂的问题
    • 缩短市场响应时间
    • 减少技术债务
    • 消除信息科技的脆弱性
  • DevOps已然是初创IT公司企业文化的一部分
  • “不断去接受新的挑战——即便是你不确定是否完全准备就绪。”