DevOps實踐指南

敏捷、持续交付和三步法

开发团队实施了很多年的敏捷软件开发,有着自己的关于完成的定义。即使你现在去翻阅一本最新出版的 Scrum 敏捷开发指南,翻到关于完成的定义的章节时,还是可以看到类似这样的定义:“冲刺的目标是要产生一个潜在可发布的产品增量,达到大家一致认可的完成程度。”我对这样的定义感到非常忧虑:它能意味着每个冲刺的开发结果可以正常地运行在类生产环境中吗?能意味着可以按照业务人员的需要马上开展小范围的真实用户实验吗?运维人员能否在系统濒临崩溃之前自行关闭这个功能?

现在可以确定的是,DevOps 的理论、原则和实践就一条“更好的道路”,就是我们需要的答案;它能让开发和运维深度地融合为同一支“球队”,使他们朝着“进球”这一共同目标协同努力,而不再是彼此对抗和怀疑。

开发部门和 IT 运维部门的目标是对立的,这通常是产生技术债务的一个因素。IT 公司需要负责的事情很多,其中包括下面两个必须实现的目标: 对变化莫测的市场做出反应; 为客户提供稳定、可靠和安全的服务。开发部门通常负责对市场变化做出响应,以最快的速度将新功能或者变更上线。而 IT 运维部门则要以为客户提供稳定、可靠和安全的 IT 服务为已任,让任何人都很难甚至无法引入可能会危害生产环境的变更。这种配置方式让开发部门和 IT 运维部门的目标和动因之间存在巨大的冲突。

除了人们在当前这种工作方式中受煎熬之外,我们能创造的价值的机会成本更令人震惊——作者认为,我们每年错失创造约 2.6 万亿美元价值的机会,在撰写本书时,那相当于世界上第六大经济体法国的年经济总产值。考虑下面的估算——IDC 和高德纳公司都估计,2011 年,约 5%的全球 GDP(即 3.1 万亿美元)用于 IT(含硬件、服务和电信)。如果我们估计这 3.1 万亿美元中的 50%用于运营成本和维护现有系统,而且这 50%的三分之一用于紧急和计划外工作或返工,也就是说大约 5200 亿美元被浪费了。

https://itrevolution.com/the-three-ways-principles-underpinning-devops

第一步:流动原则 (Flow/Systems Thinking)

2.1 使工作可见

看板或 Sprint 计划板

2.2 限制在制品数

当使用看板管理工作时,可以限制多任务的出现,例如对看板的每一列或每个工作中心设置在制品数量的限制,并把卡片数量的上限标记在每一列上。

2.3 减小批量大小

在精益中,一个重要的经验是:为了缩短前置时间和提高交付物质量,应当持续不断地追求小批量模式。理论上,最小的批量是单件流,也就是每次操作只执行一个单位产品的处理。1

在技术价值流中,单件流可以通过持续部署实现。其中,每一个提交到版本控制系统的变更都会集成、测试并部署到生产环境。

2.4 减少交接次数

要么努力减少交接次数,要么用自动化方式执行大部分操作,要么重新调整组织结构,让团队不必依赖其他人就可以独立地为客户提供价值。因此,要通过减少队列中的等待时间以及非增值工作的时间来增加流动性

2.5 持续识别和改善约束点

看不懂改善約束點的時間點等細節說明.

2.6 消除价值流中的困境和浪费

浪费和困境是软件开发过程中导致交付延迟的主要因素。

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

我们的目标是将这些浪费和困境(任何需要填坑侠的场合)都可视化,并系统地进行改进,减轻或消除这些负担,从而实现快速流动的目标。

2.7 小结

提升技术价值流的流动性对实施 DevOps 来说至关重要。为此,我们需要将工作可视化,限制在制品数,减小批量大小,减少交接次数,持续地识别和改进约束点,以及消除日常工作中的困境。

第二步:反馈原则 (Amplify Feedback Loops)

第一步工作法描述的原则,使得工作能够在价值流中从左向右快速地流动。第二步工作法描述的原则,则使得在从右向左的每个阶段中能够快速、持续地获得工作反馈。我们的目标是建立安全和可靠的工作系统。

3.1 在复杂系统中安全地工作

Steven Spear 博士在他的哈佛商学院博士论文中揭示了丰田生产系统背后的因果机制。他认为,我们可能无法设计出绝对安全的系统,但是可以通过采取以下 4 项措施让复杂系统更安全地工作:

管理复杂的工作,从中识别出设计和操作的问题;
群策群力解决问题,从而快速地构建新知识;
在整个组织中,将区域性的新知识应用到全局范围;
领导者要持续培养有以上才能的人。

3.2 及时发现问题

在技术价值流中,由于缺少快速反馈机制,我们经常会得到糟糕的工作结果。例如,在瀑布型软件项目中,代码的开发可能花上一整年,在开始测试之前(甚至在向客户发布软件前),我们得不到任何质量反馈。在反馈稀少且滞后的情况下,工作结果是很难达到预期的。

相反,我们的目标应该是在技术价值流的每个阶段(包括产品管理、开发、QA、信息安全和运维),在所有工作执行的过程中,建立快速的反馈和前馈回路。这包括创建自动化的构建、集成和测试过程,以便尽早检测出那些可能导致缺陷的代码变更。

3.3 群策群力,战胜问题获取新知

只有尽可能在早期阶段,通过全民总动员的方式来解决小问题,才能把灾难性事故消灭在萌芽状态。换句话说,当核反应堆的堆芯熔毁了,那就太迟了,已经回天乏术。

为了在技术价值流中实施快速反馈,我们必须建立等同于安灯绳和全民响应的机制。这要求我们也创造出这样一种文化,让人们在发生问题时就去拉动安灯绳,无论是在生产事故发生时,还是在价值流的早期出现错误时,并且这个行为是安全的甚至是受鼓励的。例如,当有人提交了一个代码变更,而这导致了持续构建或测试过程失败的时候。

触发了安灯绳时,我们就聚集在一起解决问题,停止开展任何新工作,直到问题解决。这给价值流中的每个人提供了快速反馈(特别是那个导致系统故障的人),让我们能够快速地隔离和定位问题,避免出现更复杂的状况,导致问题的因果关系变得模糊。

阻止开展新工作有助于实现持续集成和部署,这就是技术价值流中的单件流。能通过持续构建和集成测试的所有变更都可以部署到生产环境中,任何导致测试失败的变更都会触发安灯绳,并且会将大家聚集起来解决问题。

3.4 在源头保障质量

质量控制无效的例子如下。

需要其他团队帮忙完成一系列乏味、易出错和手动执行的任务,这些任务本应该由需求方自己采用自动化方式完成。
需要那些远离实际工作场所且公务繁忙的人批准,迫使他们在不了解工作情况和潜在影响的情况下做出决策,或者仅仅是例行公事式地盖章批准。
编写大量含有可疑细节,且在写后不久就过时了的文档。
将大量工作推给运维团队和专家委员去审批和处理,然后等待回复。

根据同行评审来评定所提出的变更,确保这些变更会按照设计运行。尽可能多用自动化方式执行通常由 QA 和信息安全人员来进行的质量检查。按需执行自动化测试,而无需开发人员向测试团队请求或发起测试工作。这样,开发人员能够快速地测试自己的代码,甚至把代码的变更部署到生产环境中。

我们用这种方式真正地让所有人都负起了质量责任,而不是仅让一个部门来负责。信息安全并不是信息安全部门专属的工作,正如可用性不仅仅是运维部门的专属工作一样。

让开发人员也对系统质量负责,不但能提高系统的质量,而且还能加速学习。这对于开发人员来说尤为重要,因为通常他们是距离客户最远的团队。正如 Gary Gruver 所说:“当有人因为 6 个月前开发人员所造成的事故而对着他们咆哮时,开发人员其实学不到任何东西-这就是我们必须尽可能快地(几分钟之后,而不是几个月后)向所有人提供反馈的原因。”

3.5 为下游工作中心而优化

精益定义了我们必须为两类客户而设计:外部客户(最有可能为我们提供的服务付费的人)和内部客户(紧随我们立即接收和处理工作的人)。根据精益原则,我们最重要的客户是我们的下游。为他们而优化我们的工作,需要我们对他们的问题给予同情心,从而更好地识别出会阻碍快速和平滑流动的设计问题。

在技术价值流中,我们通过为运维而设计来为下游工作中心做优化,包括运维的非功能性需求(如架构、性能、稳定性、可测试性、可配置性和安全性)与用户功能同样重要。

这样,我们就在源头保障了质量,并形成了一套非功能性需求,可以主动地将它们集成到构建的所有服务中。

3.6 小结

建立快速的反馈机制,对于实现技术价值流中的高质量、可靠性和安全性至关重要。为此,要在问题发生时识别问题,群策群力解决问题并构建新的知识,在源头控制质量,并且不断地为下游工作中心做优化。

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

第一步建立了从左到右的工作流,第二步建立了从右到左的快速、持续的反馈,第三步要建立持续学习与实验的文化。通过应用三步工作法能够持续提升个人技能,进而转化为团队和组织的财富。

技术价值流的核心是建立高度信任的文化。它强调每个人都是持续学习者,必须在日常工作中承担风险;通过科学的方式改进流程和开发产品,从成功和失败中积累经验教训,从而识别有价值的想法,摒弃无用的想法。另外,所有局部的经验都会快速转化为全局性的改进,从而帮助整个组织尝试和实践新技术。

为日常工作的改进预留时间,从而进一步促进和保障学习。通过不断向系统加压的方式,来强化持续改进。在可控的情况下,我们甚至通过在生产环境里模拟或者注入故障来增强弹性(resilience)。

通过建立持续、动态的学习机制,帮助团队快速并自动地适应不断变化的环境,进而帮助企业在市场竞争中脱颖而出。

4.1 建立学习型组织和安全文化

在复杂系统中工作时,精确地预测出结果是不现实的。因此,在日常工作中,即便未雨绸缪、小心谨慎,意外依然会发生,甚至有时还会发生灾难性的事故。

在技术价值流中,通过努力打造安全的工作系统,我们能建立起生机文化的基础。在意外和故障发生时,关注如何重新设计系统,从而防止事故复发,而不是去追究人的问题。

例如,可以在每次事故发生后进行不指责的回顾,对事故发生的原因和过程做出客观解释,并就优化系统的最佳措施达成一致。在理想情况下,这不但能防止问题复发,还有助于实现更快的故障定位和恢复。

4.2 将日常工作的改进制度化

在技术价值流中,为了防止灾难性事故的发生,团队陷于实施各种临时解决方案的工作中,反而没有时间去完那些有价值的工作。因此,用临时方案解决问题的模式往往还会导致问题和技术债务的累积。所以《精益企业》的作者 Mike Orzen 说: “比日常工作更重要的,是对日常工作的持续改进。”

通过明确预留时间来改善日常工作,包括预留时间来偿还技术债、修复缺陷、重构和优化代码和环境。可以在每个开发周期的间歇中预留一段时间,或者安排改善闪电战(kaizen blitze)时段,让工程师通过自组团队的方式来解决他们感兴趣的问题。