DevOps工作三步法:第一步流动原则


这个原则的目标是建立从左至右快速的、平滑的、能向客户交付价值的工作流。
字数:2700 |大约阅读时间 6 分钟
标签: DevOps   DevOps实践指南  

本文内容主要来源

本文内容主要来源于《DevOps Handbook》-DevOps实践指南,本文概述的原则是DevOps工作三步法的第一步,它的目标是先建立最底层的基础,即:DevOps技术实践和合理的应用架构;只有这样才能使工作快速而稳定地从开发端流动到运维端;与此同时还能保证不会给生产环境带来混乱,不会中断客户的服务。这就意味着需要降低在生产环境中部署和发布变更的风险。可以通过 持续交付 的技术实践来实现这个目标。

The first way flow

持续交付基于稳定的自动化部署流水线,团队能够使用自动化测试持续验证代码,确保代码始终处于可部署的状态,开发人员要保证每天都向主干提交代码,以及设计和实现有利于实施低发布风险的环境和软件架构。

在流动原则的指导下,需要开展的重要的工作内容如下:

  • 奠定部署流水线的基础
  • 实现快速、可靠的自动化测试
  • 实现并实践持续集成和持续测试
  • 通过自动化、架构解耦等方式实现低风险发布

以上技术实践能够有效地缩短创建类生产环境的前置时间。同时,持续测试可以为所有团队成员提供快速的反馈,使小型团队能够安全、独立地开发、测试和向生产环境部署代码,从而将生产环境的部署和发布作为日常工作的一部分。

此外,通过将QA人员和运维人员的任务集成到DevOps实施团队的日常工作中,能够减少救火、困境以及繁琐的重复劳动的发生,使团队成员的工作高效且充满乐趣。这不仅能提升团队的工作质量,还能提高组织的竞争力。

流动原则相关的详细技术实践请参考请《DevOps实践指南》一书的第三部分,这部分包含第10章到第13章,一共描述了5个技术实践。

在流动原则里我们强调的而是全局的目标而不是局部的目标,局部目标的例子如下所示:

  • 特性开发完成率
  • 测试发现/修复缺陷的比例
  • 运维的可用性指标

我们需要减少价值流中的工作交接的次数,由于当交接次数多到一定程度时,所有人就会彻底的迷失,无法回答工作的上下文联系是什么?也不清楚我们要解决的是什么问题?或者组织的全局目标是什么?

价值流的应用实例

如果我们选择做DevOps转型的项目是棕地项目,我们就需要对当前的工作,进行细致的值流研讨和分析;需要画出当前的状态。如下图的示例所示(注:这是一个示例,你的棕地项目分析完之后并非如此)。

VSM as is

为了在实施DevOps的过程中持续的度量和改进,我们需要分析出当前价值流的核心定量指标:

  1. 总计前置时间 = 求和价值流中每个工作步骤里的LT 【这个指标是DevOps项目的北极星】
  2. 总计增值时间 = 求和值流中每个工作步骤里的VA
  3. 完成且精确百分比 = 连乘值流中每个工作步骤的%C/A

如果是绿地项目,我们在第一个工作周里,价值流图是没有这些数值的。我们需要每天都在CI/CD流水线工具中采集相关数据,在每个人的日常工作中关注和记录相关数据,在第二周和后续的每一周里度量和分析以上指标,最好用仪表板展示工具,将这些数据实时地显示在所有项目组成员都可以轻松看到的位置。

对这个价值流进行持续的优化,使它更高效的工作,并不断的进化和改进。如果是棕地项目,那么在分析完以上的机制流之后,可以定制新的进化版的价值流图,并按照新版本的价值流图重新开始项目的执行。如下图的示例所示(注:这是一个示例,你的棕地项目改进优化完之后并非如此)。

VSM as is

优化和改进日常工作

Goldratt博士的约束理论(TOC)

在实践运用流动原则的技术实践时,可以使用Goldratt博士给出的方法,随时识别并解决价值流中的约束点,这个五步法如下:

  • 识别系统的约束点。
  • 决定如何利用这个系统约束点。
  • 基于上述决定,考虑全局工作。
  • 改善系统的约束点。
  • 如果约束点已经突破了,请回到第一步,但要杜绝惯性导致的系统约束。

以上五步法是DevOps实施项目组日常工作的必备流程优化工具。

常见的4个约束点

传统企业或者团队里最容易发生的约束点有一定的共性,一般可能会按照以下顺序逐个攻克和优化:

  1. 环境搭建
  2. 代码部署
  3. 测试的准备和执行
  4. 紧密耦合的架构

可以清楚的看到大多数约束点比较偏Ops这一侧,而攻克所有这些约束点需要Dev和Ops一起协作完成。

常见的9中浪费

在DevOps工作团队里需要尽快能地避免以下浪费现象的发生:

  • 半成品
  • 额外/多余工序
  • 额外/多余功能
  • 任务切换
  • 等待
  • 移动
  • 缺陷
  • 非标准或手工操作
  • 填坑侠

以上浪费现象最早是从制造行业的精益管理中总结出来的,这些也是完全可以应用到技术价值流中,IT相关的工作能对每一条有很多痛点清晰的解读,你可以尝试在自己的工作环境中寻找以上所有浪费现象。

DevOps工作三步工作法 in《凤凰项目》

在本书中,我们阐述了这一基础原理,即所有开发运维模式都来自“三步工作法”,它旨在阐明指导开发运维的流程与实践的价值观与理念。

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

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

**第二工作法 **是关于价值流各阶段自右向左的快速持续反馈流,放大其效益以确保防止问题再次发生,或者更快地发现和修复问题。这样,我们就能在所需之处获取或嵌入知识,从源头上保证质量。

“必要的做法包括:在部署管道中的构建和测试失败时“停止生产线”;日复一日地持续改进日常工作;创建快速的自动化测试套装软件,以确保代码总是处于可部署的状态;在开发和IT运维之间建立共同的目标和共同解决问题的机制;建立普遍的产品遥测技术,让每个人都能知道,代码和环境是否在按照设定的运行,以及是否达到了客户的目标。

第三工作法 是关于创造公司文化,该文化可带动两种风气的形成:不断尝试,这需要承担风险并从成功和失败中吸取经验教训;理解重复和练习是熟练掌握的前提。”

“尝试和承担风险让我们能够不懈地改进工作系统,这经常要求我们去做一些与几十年来的做法大不相同的事。一旦出了问题,不断重复的日常操练赋予我们的技能和经验,令我们可以撤回至安全区域并恢复正常运作。

必要的做法包括营造一种勇于创新、敢于冒险(相对于畏惧或盲目服从命令)以及高信任度(相对于低信任度和命令控制)的文化,把至少20%的开发和IT运维周期划拨给非功能性需求,并且不断鼓励进行改进。”

From: [美] 金(Gene Kim ),[美] 贝尔(Kevin Behr),[美] 斯帕福德(George Spafford). “凤凰项目一个IT运维的传奇故事.”。

DevOps教练在知乎

See Also