利用DevOps踏上软件交付的加速之路

一次又一次，我们不断听说众多企业客户利用DevOps机制实现快速交付。各大厂商每天也在不断宣扬着利用此类部署获得成功的实际案例，并鼓吹称借此能够实现每天十套、五十套甚至上百套业务线的部署工作。而在LinkedIn、Netflix、Etsy、Facebook以及其它成熟企业当中，这一数字甚至能够突破上千套。不过，这一切到底意思着什么?

[[135922]]

IT领导者最喜欢谈论这些看起来令人振奋的数字，而且往往会将快速交付作为对话的主要关注焦点。然而这类软件交付方式到底是否稳定可靠?其中哪些部署方案能够切实取得成功?整个部署流程又由哪些步骤来构成?

这些问题往往最终造成分析瘫痪，但却给不出任何一种有实际意义的结论。事实上，企业最常见的反往往是“在我们公司，我们没办法实现某种目标，因为……”我们知道这种说法根本站不住脚。那些以瀑布式机制通过单一部署流程按月或者按季度进行产品交付的传统企业完全能够与其它团队一样，成功过渡至快速部署并由此拥有理想的交付能力。

那么我们要如何才能以软件交付为起点享受此类成功果实?世界上并不存在万灵药或者一步到位的解决方案，但大家却能够通过方法论指导自身达成快速交付目标。下面让我们一同了解起步阶段的必要任务。

基本原则

让我们通过以下这些关键性原则来照亮通往光明彼岸的道路。它们分别是：

• 接受失败
• 分析失败原因，但不苛责任何相关人员
• 在了解理由后快速修正失败因素
• 永远保持迭代

简而言之，我们的目标应该是快速部署、快速失败、快速学习而后快速改进。这是一项永无止境的任务，而且我们也需要始终以这样的思路看待整个流程。相信大家都曾经经历过，一个项目在启动过程中会将这些原则考量在内，但随着项目的终结、这一切最佳实践也随之消散。除非将持续改进作为核心诉求传递给交付对象，否则任何一种努力都有可能随着时间的推移而最终失效。

在将上述原则牢记在心之后，我们接着迈出下一步。

软件是怎样被开发出来的?

我们的第一站有时候并不从属于交付组织，而体现在开发组织当中。这也就是“移情”思维的作用所在，即站在对方的角度看待问题。DevOps概念也恰恰是针对这一焦点; 我们首先需要确保负责交付功能的开发人员具备获得成功的一切要素。

软件到底是如何被开发出来的?这一切对于生产流程究竟意味着什么?大家不妨向自己提出以下问题：代码是如何被引入源代码树的?可接受代码应该具备哪些特点?(举例来说，是否存在代码格式指南或者必要测试等支持机制。)

一旦弄清了以上问题，接下来的关键就是将代码进行改善，从而将其推向交付的下一个阶段。但这往往正是瓶颈的出现之处：虽然过去的历史案例能够起到有效的指导作用，从而以引入检查点的方式来尝试并改进产品质量，但这些检查点通常以人为方式驱动——很明显，人为方式总是有着种种自身缺陷。

最重要的一点是分清楚代码交付或者功能交付与软件本身交付之间的区别所在。虽然二者对于下一阶段的工作来讲都是非常重要的前提性条件，但双方的职责往往各有所专。在整体系统当中，我们的需求始终是一致的：寻求机会，通过拆分流程步骤的方式降低摩擦(即那些由传统机制带来的毫无价值的非必要因素)或者利用自动化方式推进整个周期。

考虑到这一点，开发团队与运营团队之间的对话将带来持久的启发性成效，因为在充分交流之后、双方都将清醒地意识到导致流程缓慢的原因所在。请大家继续集中精神，让我们继续进入下一个议题。

接下来的几个问题请务必牢牢记在心中：

• 哪些员工能够编写软件?是否每位员工都有能力编写软件?
• 在学习软件编写的过程中，是否存在着明显的入门壁垒?
• 将工作代码向同事展示到底有多困难?
• 同事运行我们的展示代码到底有多困难?
• 哪些员工能够部署这些软件?
• 在学习部署软件的过程中，是否存在着明显的入门壁垒?
• 我们需要在哪里进行任务分配?
• 我们需要在哪里讨论新功能的引入?

#p#

以“高档位”推动流程加速

到这一步，大家可能已经拥有了一套软件方案当中需要改进的各项条目的明确列表。但是，我们该把关注重点放在哪里?当下的默认思路是先理清发布机制，而后再尝试与外部团队进行良好协作。然而这其实是最不明智的作法，因为它最终将导致开发与运营团队之间产生无法逾越的鸿沟。因此对于大家来说，最好的判断也许是将对接放在第一位。

我们的第一步工作应当集中在两大主要目标身上。第一是将自身嵌入到开发工作流程当中……通过现有流程从开发任务内提取项目元素，并提出针对性的主张。这些主张将成为我们的“第一个追踪对象”，并帮助我们理解哪些变更能够实际起效、而哪些不能。此外，它们还能够带来有价值且中肯的反馈意见，这往往是其他对项目进度并不关注——或者说其主要精力集中在了其它工作上——的同事所无法提供的。总而言之，从小处着手几乎是必要且最理想的处理方式。

在这一阶段，DevOps会提出大量的所谓“移情”性观点。无论是在改善产品方面投入怎样的努力，一旦摩擦元素开始在开发者的日常工作当中出现，那么变更带来真正成功的可能性也将变得愈发低下。举例来说：对大家而言，对底层交互平台的变更也许能显著改善沟通效果，但如果这种作法破坏了现有交付通道，那么结交新朋友的几率很可能反而有所下降。

将自己的主张整理成开发报告，并提交给所在团队——反之亦然——最后将其纳入整个执行流程。另外，也不要忘记始终遵循前面提到过的基本原则……快速部署、快速失败、快速学习与快速改进。尽快修复易于处理的流程漏洞。再有，高度关注任何给定时间段内引入的变量数量，不要害怕进行变更，但同时始终保持变更的一致性并加以衡量。只要能够长期坚持做到以上几点，我们的整个交付流程将得到理想的调整与改进。

与之同理，通过这一流程建立起真正的项目成果。早期的成功能够确保开发人员得以通过最低限度的努力运行任意代码版本(无论是git检查版本还是其它主要版本)。

这使我能够利用来自其他同事的代码测试自己的开发成果修复效果、确认漏洞以及其它类似的工作。拥有了运行任意代码的能力，我们就能够合作加快代码的开发流程、降低开发末期可能遭遇的问题数量，这意味着大部分难题在流程早期就已经得到了解决。这样的效果对于阶段性交付环境——很可能是本地开发环境——而言非常重要。不过除此之外，构建起一套允许开发人员以小型独立任务方式运行代码的平台同样能够有效支撑起后续的生产交付流程。

一旦大家发现流程及开发工作当中出现了失误，请千万牢记一点：针对该失误进行分析与修复，但不要因此则苛责任何人。首先，这类问题的项目早期阶段会大量出现，相信这也是我们每个人的共识。John Allspaw在他的文章当中谈到了这一点，并将激励作为最主要的思维立足点：

另一个经常被忽视的问题是这些解决方案的具体实现手段。此类修复流程不应该由某一个人或者自上而下的方式予以驱动。相反，团队中的所有成员必须都能够成为解决方案的组成部分。时间与鼓励将在长期工作当中起到非常积极的促进作用。

最后，部署。项目的最终意义就是部署代码。到这一步工作已经基本结束，接下来要做的就是专注于开发与运营团队之间的相互作用，不过双方也需要在一部分任务当中共同协作。除非大家能够以毫无瑕疵的方式完成日常部署，否则彼此沟通将贯穿整个部署流程。在每天的工作当中，我们都应该尝试一次代码部署——无论我们是否能够预见到其实际效果。另外，每天找出一到两个问题并加以修复：包括流程中的故障或者手动阶段中的问题。重复这些任务，直到我们能够以最低命令数量完成日常部署目标(最好是一行命令就搞定)。

前方的道路还很崎岖，请做好心理准备!

在不断推进的过程中，我们将反复面对两大关键性主题。第一就是通过沟通解决问题。随着时间的推移，部署工作的推进速度将不断加快或者愈发精简，但即使是最出色的团队也需要想办法克服由沟通障碍所带来的挑战。

第二则是解决相关工具的使用能力问题。一旦工程师们开始引入实现过程所必需的工具，一切人为及流程因素都将居于次要地位——或者说以工具为核心加以适应。这往往是道难以克服的关隘，因此此类工具要求软件交付相关组织之内的各位成员真正参与到沟通当中。

考虑到这一点，我向大家推荐两款能够切实帮助各位突破阻碍的工具：CahtOps与Workflow。二者都属于非常出色的解决方案，值得我们用专门的章节来加以阐述。不过受限于篇幅，我们在这里一言以蔽之：它们是软件交付工作中必不可少的组成元素。

请记住：问题的关键并不限于单一工具。这些工具只是达成目标的一种手段。人与流程需要成为对话中的核心组成部分。ChatOps能够通过沟通及合作来创造并推动开发进程。Workflow则从基础设施流程角度出发实现整体协作。二者都应该成为软件交付工作中的必备元素。

内容概述

为了获得成功，作为技术人员的我们需要了解自己的组织当中发生了什么、技术手段如何帮助交付流程达到预期效果，而技术元素又是如何被部署并被哪些用户使用的。如果没有清晰的理解，我们将陷入遇到问题就引入工具，但工具的出现反而增加了问题复杂性的恶性循环。在这种情况下，工具往往会成为流程推进的瓶颈或者彻底沦为花瓶——因为人们根本就不打算真正加以使用。在快速发展的今天，精益化业务流程不会允许我们把时间浪费在故障身上。

您是否了解所在团队是如何交付软件并在流程中实现协作的?您的团队与服务交付对象之间是否存在着紧密的反馈通道?您是否有能力实现快速行动，甚至以更快速度修复问题?

时至今日，软件交付速度已经被广泛视为市场竞争中差异性优势的典型代表。通往这一目标的道路既不平坦也不顺畅，但一旦实现、我们的组织也就同时做好了迈入下一个快速成长阶段的准备。

原文标题：Beginning software delivery acceleration with DevOps