项目实施DevOps时,我们是如何做测试的

正如我们所知,DevOps最近几年很风靡,很多企业正在如火如荼的推行它。然而,你可曾想过,从传统到敏捷、再到DevOps,开发模式的不断革新对测试提出了怎样的挑战?

最近我们项目在实施DevOps,因此想趁热打铁,就DevOps模式下如何做测试,谈一谈自己的认知。

DevOps有什么特征

DevOps是一系列软件开发实践,强调开发人员(Dev)和运维人员(Ops)之间的沟通合作,通过自动化流程,使得软件构建、测试、发布更加快捷、频繁和可靠。

1. DevOps强调一种文化

在很多企业中,开发和运维人员通常隶属于不同部门,有着不同的工作环境,采用不同的沟通方式,使用不同的开发或运维工具,并且有着不同的业务目标,这使得他们之间形成一道参不透的墙。

DevOps实际是一种文化上的变迁,强调开发、运维、测试等环节之间的沟通合作。意在帮助这些人向着一个共同的目标努力:尽可能为公司提供更多价值。为了支持这种合作的发生,需要在团队内部文化和企业组织文化两个层面做出努力。

2. DevOps是一种实践

所谓DevOps,就是将敏捷方法延伸到Production!

DevOps主要是为了将敏捷开发实践扩展到运维阶段,进一步完善软件构建、验证、部署、交付等流程,使得跨职能团队能够完成从设计到生产支持等各环节的工作。

3. DevOps包含一系列工具链

DevOps是一种融合了一系列基本原则和实践的方法论,并从这些实践中派生出了各种工具。这些工具体现在软件开发和交付过程的不同阶段:

  • 编码:代码开发和审阅,版本控制工具、代码合并工具
  • 构建:持续集成工具、构建状态统计工具
  • 测试:通过测试和结果确定绩效的工具
  • 打包:成品仓库、应用程序部署前暂存
  • 发布:变更管理、发布审批、发布自动化
  • 配置:基础架构配置和部署,基础架构即代码工具
  • 监视:应用程序性能监视、最终用户体验

DevOps对测试提出了哪些挑战

刚参加工作时,我参与了某Audi系汽车电子的软件研发,采用的是传统瀑布开发模式。在整个项目生命周期中,前半部分设计和编码,后半部分用来测试。然而我在东家工作了两年,也没能等到产品交付到用户手上。直到去年,我们的软件才得以量产并投入市场。在这4年中,产品从未交到用户手上,因此无法验证它所带来的价值,也没有任何机会得到用户反馈从而适应变化。

后来,我又参与一个银行项目,我们采用敏捷的开发模式,全功能团队,开发测试并行,每2-3周就交付一个版本。但因为没有真正发布到生产环境,我们仍然无法及时得到有效的用户反馈。

现在,我们采用DevOps的优秀实践,开发和运维协同工作。每个迭代完成,或者每修复一个线上缺陷就立即部署到生产环境。这样,我们就能够迅速从用户处获得反馈并且快速做出响应。

通过参与传统、敏捷和DevOps的项目,我深深地感受到流程的改进对团队以及项目的产出和质量所带来的改变。

那么,这些改变究竟是对测试提出了什么样的挑战? 我认为有以下几点:

1. 频繁部署

在采用DevOps之后,我们能够根据项目具体情况做到每天甚至一天多次部署。在生产环境频繁部署软件,最大的挑战就是测试。以前,测试基本上都在开发阶段之后和产品上线之前完成。但现在,不再有充足的时间留给QA团队去发现问题再抛给开发团队来修复。那么,速度成了测试面临的一大挑战。

2. 自动化

DevOps强调将流程自动化,测试作为其中一个重要环节,势必要大规模实现自动化。因此测试人员的自动化编码能力正在面临极大的挑战。

3. 实践和反馈

敏捷提倡我们要拥抱变化,更多的是要适应需求的不断变化。虽然一部分功能性需求是明确又具体的,我们清楚的知道用户想要什么,也因此易于测试。然而,也有一些非功能性需求的验收标准没那么明确,比如:提高应用性能达到良好的用户体验。我们如何才能验证用户体验是否真的良好呢?仅仅通过性能指标吗?当然不是,满足指标只能说明一部分问题,唯有真实的用户数据和反馈才是可最靠的。

4. 协作

敏捷强调全功能开发团队的共同协作,但这仅仅止于开发阶段。而DevOps注重Dev、Ops和QA三个群体之间的密切协作。因此,良好的角色定位能够帮助测试人员将价值最大化。

我们是如何做测试的

Laurent曾经在Hiptest上发表了博客《Shift left and shift right: the testing Swing》,提出了一个有意思的测试矩阵,从四个维度进行分析,描述了当软件开发模式从瀑布到敏捷、再到DevOps转型时,测试该如何响应变化。

Laurent提出一个测试左移和右移的概念:

  • 测试左移,就是指在开发阶段之前定义测试。
  • 测试右移,就是直接在生产环境中监控,并且实时获取用户反馈。

在敏捷开发的生命周期中,我们通过每一次迭代来丰富和更新产品,以使其最大限度地符合客户对系统的需求。当时测试的关注点基本停留在开发阶段,以保证产品达到上线标准。引入DevOps之后,我们不仅要关注产品的质量是否达标,还需要使价值假设得到及时的验证。因此,我们不仅要将测试左移,在开发环境验证功能的可用性,还要进行测试右移,通过监控产品在生产环境的运作情况,来验证其价值并获得反馈,从而持续改进。基于这些理解,我在项目上做了初步的尝试并取得良好的效果。我将这些尝试和实践总结为以下几点:

1.如何保证新功能得以实现?

在开发环境,我们开发新功能,并且通过测试保证其达到产品验收标准。

首先,使用BDD(Behavior Driven Development,BDD)的方式定义用户需求,这样用特定的语言来描述用户行为,能够使各个角色(测试、开发、产品负责人、市场等)对业务价值达成一致的理解,从而使其从需求到最后的测试验证,进行高度的协作和沟通,最后交付最有价值的功能。同时,QA能够提前Review故事卡,补充验收标准。除此之外,BDD方式的用户需求可以直接指导测试,后续我会写到。

其次,采用单元测试来验证最基本的代码逻辑。在编写单元测试时,建议Dev和QA Pair工作。单元测试可以认为是编码的一部分,要对系统的代码逻辑有深入的了解,因此,Dev是最合适的人选,而QA可以帮助测试覆盖的更全面。

最后,每一个功能都要严格按照故事卡的AC(Acceptance Criteria)进行验收,并采用探索性测试方法来对新功能进行无死角测试。

2.怎样验证新功能的价值?

我们将新功能部署到生产环境以后,接下来就应该衡量业务价值是否达到预期

验证预期的一个好方法是衡量用户的行为变化。比如:在上传图片的功能后面添加了一个预览按钮,但用户却极少用它,很可能是因为用户根本不需要这个按钮,或者按钮放在了不恰当的位置导致用户不方便使用,亦或是按钮样式不够友好,导致用户没有欲望使用它。这时候,该按钮的业务价值就没有真正达到,是时候调整一下了。

3.如何确保已有功能不被破坏?

在软件开发中,任何代码都不可能完全独立存在,一行代码的变更也有可能导致系统的全面崩溃。那么,如何保证在开发新功能的同时,已有功能不被破坏?换句话说,如何做到全面的回归测试?人力是最高成本,也有现实的局限性,比如,人手不够,重复做同样的事情人会变得烦躁,手不够快导致效率低下等。因此,自动化测试才是不二选择。

将BDD需求直接转化为自动化测试用例。每个测试用例都应该讲一个关于应用程序的故事。当一个测试用例使用一致的业务术语定义时,它的可读性会比较高,且容易自动化。与此同时,上一个迭代的用例在下一个迭代就可以迅速转化为回归测试的基线。

支持BDD的工具有很多,比如:Cucumber。简单举个例子,如图:

BA用BDD方式定义用户需求,QA Review并补充AC,然后将其编写为自动化测试脚本。如果QA的编码能力较弱,可以让Dev协助完成代码实现的部分。这也充分说明了协作的意义。

最后,也是更重要的部分,测试应该集成在CI中。每一次Build或者每天都要去执行测试,验证已有功能是否完好。这样才会对没有预期到的变化产生的问题给出快速反馈。

另外,做一些性能测试、兼容性测试、和安全性测试等等。

4.怎样验证产品的可靠性?

有时候,某些缺陷并不是源于代码的错误,而是一个不好的用户体验,或者只有当数据达到一定量时才会出现,测试人员是无法模拟这种类型的测试的,因此直接在生产环境监控变得高效又可靠。通常我们需要监控两种特性:性能和可用性。

使用工具持续获取用户数据,或者使用log持续获取性能信息。这有助于监控产品部署到生产环境后是如何正确运作的。快速启用一个功能,在生产环境实时监控验证其业务价值,获取到有效且快速的用户反馈,加之拥有持续部署的能力,我们能够在出现问题的时候快速做出反应,从而使得我们的产品更加可靠。

这里实际上融入了《QA in Production》的理念。现如今,已经有很多工具和方法支持在生产环境做测试了。篇幅太长,这里就不做详细阐述了,请参考原文

到这里,再来回顾一下,我们的实践是否真的卓有成效。

  1. 用BDD的方式定义用户需求、编写测试,有益于不同角色之间的一致理解和共同协作。
  2. 自动化测试解决了频繁部署所带来的挑战,同时保证产品的整体功能持续得到回归和验证。
  3. 在线监控能有效地验证不确定需求,通过生产数据分析和预警问题的发生,并且快速获取用户反馈从而及时调整。除此之外,这一点也充分体现了Dev、QA和Ops的协作,像监控等原本只能Ops做的事,现在Dev或QA一样可以做。

写在最后

测试是一种活动,曾经我们通过它来验证产品是否达到上线标准。现在DevOps模式下,我们需要在各个阶段不断地执行测试活动,以达到产品质量的持续改进。

而QA(Tester)仅仅是一种较多进行测试活动的角色。敏捷一直强调“团队为质量负责”,测试不再是QA(Tester)的专属。DevOps模式更是对测试、尤其是自动化测试提出了更高的要求,也对QA的编码能力提出了极大的挑战。作为团队成员,每个人都有责任了解开发流程、提高测试技能,把好测试这一关。但是,测试活动作为QA(Tester)的主要职责之一,提高自动化测试技能,就是当下每个QA(Tester)最为紧急且重要的事情了。


更多精彩洞见,请关注微信公众号:思特沃克

Share

企业实施DevOps的七大挑战

DevOps这个词在近年来可谓大火。从2014年底我开始给一些企业做持续交付/DevOps相关的评估和咨询,似乎每个企业都表示想要推行DevOps,或者说他们正在做DevOps。这把火蔓延的速度远远超过当年敏捷在IT行业的传播。然而有些企业管理者对DevOps的认知让我们意识到,由于各种有意或无意的因素,这个概念不幸地成为了一个让人困惑的buzz word……

什么是DevOps?

这里我想列出四种我们在市场上、企业咨询以及社区交流过程中接触到的认知:

  1. 一些企业的运维部门找我们,说要搞DevOps。我请他们约开发部门的同事一起来沟通,却得到类似于“不用管他们,我们自己搞……”的回复。再问那打算搞啥呢?答案可能是“我们想谈谈自动化运维……”。
  2. 另一种认知是,敏捷宣言提出了“业务和开发要紧密协作,拥抱变化,将变化视为提升价值的机会而非麻烦。”那么DevOps则是将敏捷思想向运维延伸,通过开发和运维的紧密协作,让交付的最后一公里也能拥抱变化,兼顾吞吐量和稳定性。
  3. 进一步,有些企业提出了自运维“No-Ops”理念,让运维的职能融入产品交付团队,由团队自主、自助地完成部署发布,同时自己承担线上问题支持等工作,完全让运维工作去中心化,实现“Who build it, who run it”。
  4. 我们还看到,一些咨询或解决方案厂商的宣传将DevOps刻画成了一个全新的、从设计、需求到发布运维端到端的研发体系,似乎有了DevOps这把榔头,软件研发的各种问题都解决了。有了DevOps,苦逼的程序员们就迎来解放了…

作为企业管理者,要在组织中引入DevOps并推动变革,首先要对DevOps的目标有清晰的认识,并明确DevOps在自己企业的上下文中意味着什么。我反对一些厂商将DevOps吹得太大,但这也绝不仅仅是运维单方面的目标。DevOps运动本质上是关于开发(含测试)和运维的协作,在“为用户创造最大化价值”的一致目标下,让软件交付给用户并获得反馈的过程更加敏捷。至于要不要将开发运维一体化,则取决于具体产品的特征,在不同场景下可以有不同的协作模式。

DevOps行业报告提出了两个顶层的用于衡量IT组织效能的指标:吞吐量和稳定性。在一些人看来,这两个目标就像鱼和熊掌不可兼得。追求交付吞吐量,就会带来更大的不稳定性和风险;而传统运维管理以稳定性为目标,就必然牺牲对变化的响应力。之所以会有这样的悲观认知,是因为仅仅站在当前的时空看待问题,而无法超越自己的能力局限。企业管理者需要理解,进行DevOps转型,就是要超越自己的能力局限,超出当前的时空看问题,通过组织设计、过程改进和工程技术的提升让组织能力上升到一个新的维度,我们完全可以做到同时提高IT交付的吞吐量和稳定性,而不是在两者之间取舍平衡。

然而,要突破自身的能力局限,这并非易事。下面谈到的实施DevOps过程中的七大挑战中的每一个都需要组织下决心投入,并耐心等待回报,没有足够的认知转变和卓越领导力难以实现。

挑战一:自动化测试投入不足,收益低

敏捷宣言自提出时,就已经将自动化测试作为敏捷、极限编程的核心实践来强调。然而这么多年过去了,在组织中真正有效进行自动化测试的并不多,各种问题都在影响着组织和团队对自动化测试的信心。

要想同时提升吞吐量和稳定性,以自动化替代手工方式快速、频繁的对软件质量进行验证是首要的手段。如果说在以往谈论敏捷开发的时候,自动化测试是对团队的较高要求,那么到了DevOps时代,这就是最基本的入门要求。毫不夸张的说,如果软件系统没有一套较完善的自动化测试体系,就请不要谈DevOps了。

最直接的问题是投入不足。很多管理者意识里是将自动化测试看做一项额外的、可有可无的任务。他们关注的是短期的项目管理目标,而不是长期的产品持续演进,往往只有进度压力不大的时候才投入人力来做一做,或者单独聘请一个团队来补充测试用例,然后离开,而不是作为开发团队交付软件产品的一部分。这样的模式很难产生一套长期有效的测试套件,反过来进一步削弱了管理者对其进行投入的信心。

另外常见的一些问题包括:

  1. 缺乏对自动化测试策略的正确认知,过多集中在界面上做测试,缺少单元测试和API测试。界面功能测试案例的开发和维护成本高,执行速度慢;想想上千个案例全部执行完可能需要跑上半天、一天,然后有几十个案例因为环境或网络问题而执行失败,却不是因为代码问题。结果是我们看到不少团队从来没有一次将所有案例全量执行过,只能每次手动挑选一部分案例来跑。
  2. 缺乏一套独立的自动化测试环境,而是和手动测试共用一套环境。这种做法一方面会导致自动化测试和手动测试在资源和测试数据上相互影响,使得测试不稳定;另一方面自动化测试过多依赖外部集成环境,缺少必要的依赖隔离,使得测试案例执行不稳定、执行效率低。
  3. 自动化测试、手动测试和生产等各环境不一致,使得自动化测试的结果不够可信。
  4. 由测试人员或单独的团队来写自动化测试,而不是让开发人员写。这首先导致开发人员在设计和编码时很少考虑为了更高效稳定的自动化测试进行优化,加大了测试开发的难度;其次测试人员必须等到开发基本编码完成了才能开始写测试案例,并且需要请开发人员讲解API或界面元素的设计,这是一个低效的过程,浪费时间。
  5. 没有将自动化测试纳入持续交付流水线自动化地频繁执行。我们看到不少团队是在完成手动测试后、上线之前选择性地执行自动化测试案例来进行回归;这样的用法没有最大化其价值,对质量的反馈速度太慢。

要解决以上问题,并产生一套有效的自动化测试套件是一个巨大挑战,需要管理者和团队转变质量意识;需要企业从项目化的管理转向产品化的管理,人们才能真正长远地去考虑对自动化测试的投资;需要影响业务人员在需求容量上的期望,为书写自动化测试提供时间。

挑战二:高度集中的IT基础设施服务

在传统模式下,像服务器申请、配置变更等IT服务是由高度集中的基础设施管理团队负责。产品交付团队需要向集中的IT服务团队提出申请;而该团队往往承接着来自很多交付团队的需求,于是只能将请求进行排队依次处理,并且主要依靠手动处理;结果是交付团队不得不长时间等待,才能得到所需资源。这个过程中的手动操作,使得经过一段时间后,基础设施的配置变成了一个黑洞,没人能够说得清各个服务器之间的状态差异,当问题出现时需要耗费很长时间来进行分析定位。我把这样的时代称之为IT基础设施服务的“农耕时代”。

IT基础设施的管理要更加敏捷,提高变更吞吐量并同时提高稳定性,首先需要在基础设施的管理上实现这四个目标:

  1. 标准化
  2. 脚本化
  3. 版本化
  4. 可视化

在此基础上,基础设施管理团队不再排队处理所有交付团队的请求,而是专注于提供一个基于标准化、脚本化、版本化和可视化方式管理基础设施的自助服务平台;组织授权给各产品交付团队利用平台的能力,以代码化的方式随时按需进行基础设施的准备和变更。缩短等待时间的同时,因为进入生产环境的基础设施变更已经以一致的方式在各个测试环境经过了验证,减少了人为手动操作可能引入的错误和遗漏,确保了各个环境的一致性;也让前期的自动化和手动测试更加可信,从而使得系统的稳定性也得到提高。这样一个模式我称之为IT基础设施服务的“云时代”。

对企业来说,从这种基础设施管理集中式控制向去中心化授权的转变也是一个巨大挑战。首先基础设施自助服务平台的建设需要投入;更重要的是,能够授权交付团队依赖自动化方式,而非人工来保障基础设施配置的质量,本身就需要管理者的思想转变。在我看来,一些管理者倾向于依靠人来控制,而不信赖经过反复验证的自动化过程,只有一个原因:人出了错可以追责和惩罚,而自动化过程出了错,不容易找到某个单一的人来担责,总不至于惩罚机器。

这里还有一个挑战不得不提,这种转变带来了传统运维模式下运维人员的技能要求转变,从以往手动的服务器操作,变成需要写DSL、需要会编程。这必然影响到一群人的职业发展,这会给变革带来阻力;企业应当给这群人提供足够的培训,提供新的职业发展机会。

挑战三:部署与发布未分离

在产品交付团队追求频繁变更、提升交付吞吐量的时候,即便进行了严格的同行评审、通过了完善的自动化测试、确保了基础设施环境的一致性,但由于周期短、频率高,要平衡投入产出的收益,在软件进入生产环境时,还是有风险存在。因此一些管理者无论如何不敢在部署发布流程上进行放权,减少审批控制。这种不安全感是来自传统的发布过程缺少一种安全性策略,也就是没有将“部署”与“发布”分离。

“部署”和“发布”是两个不同的词,然而很多年里当提到将软件最后发布给用户使用时,两个词通常是混用的。为什么呢?以往,我们将软件发布给用户的手段很单一,就是将软件部署到生产环境跑起来,用户就可以用了,这两个词所代表的动作是同时完成的。

要让发布环节变得更加安全,就需要将这两个动作分离。“部署”即是让新的或修改的软件安装到目标环境上运行起来。这应当是一个技术决策,即是否执行这个动作应当完全由技术团队依靠对变更进行的同行评审和测试来决定,随时可以执行。这个动作过程中,技术团队重点关注的是:

  • 部署过程自动化
  • 版本更新过程对用户无感知
  • 能够快速回滚。

而“发布”应当是一个业务决策,即允许业务和产品人员来控制新特性对用户的可见性。首先对受控的小范围用户开放,经过一段时间的反馈信息收集,包括对系统稳定性和用户行为、喜好的观察,然后决定是否将其开放给更大范围的用户。如果系统存在质量或设计问题,可以很快关闭新特性,或回退到旧的版本。在这个发布的过程中,交付团队和业务人员重点关注的是:

  • 系统稳定性
  • 用户实验反馈

要实现这样的分离也是一个很大挑战。首先技术上,需要引入蓝绿部署、金丝雀发布,以及特性开关等手段;但要让每个团队都自己去建立这样一套机制成本太高,企业需要从平台战略的角度提供这样一种便捷的能力来实现灵活可配置的在线受控实验;另一方面,这样的分离意味着重新定义了在软件部署发布过程中IT团队和业务人员的职责,需要IT和业务的紧密协作。

挑战四:缺少自助式的持续交付平台

DevOps不仅仅是关于运维的自动化,同时也是关于开发、测试到运维各个职能围绕着每一次软件变更的紧密协作。在这个过程中,开发关心的是代码库、编译、构建;测试关心的是测试验证和测试环境;运维关心的是部署与发布控制、监控及支持等,各个环节的任务涉及到一系列工具构成的工具链。然而在对很多客户的调研中,我们发现普遍存在的现状是:

  1. 开发、测试和运维各自有自己的一套工具来完成自己关心的任务,而这些工具既不相同,也不相互关联;软件包在不同工具之间的转移更多依靠人工来完成;
  2. 由于工具上的割裂,每个人并不清楚同一个变更在其它角色哪里到底发生了什么,也不关心;
  3. 由于从获取代码、编译、扫描、构建、测试、部署、发布到获得反馈的整个过程中涉及到很多工具的运用,很难有哪个团队能够靠自身力量在每一个环节都做得成熟。

要在企业中实现DevOps,有一定规模的IT企业非常需要给产品交付团队提供一个软件持续交付平台,让软件从代码提交构建到交付给用户的整个过程得以在这个平台上完成,包括所有自动化任务的配置和调度,支持信息可视化辐射,和內建一些必要的流程控制环节,例如操作权限和信息审计等。这样一个平台应纳入IT企业的战略性平台之一,其价值我认为有几点:

  1. 作为一个杠杆,在规模化的组织中撬动各个交付团队的持续交付/DevOps工程技术能力,将其快速拉到一个基线,大大降低各团队自己实施的成本;
  2. 通过统一的部署流水线将从代码提交到交付给用户的整个过程高度可视化出来,信息透明;让开发、测试和运维以高度一致的方式工作在同一个流水线上,真正建立起协作;
  3. 每一次的软件变更在这个完整的流水线中得到充分的验证,尽早发现有缺陷的变更;而经过了完整验证的变更可以随时部署出去;
  4. 在组织级能够将一些必不可少的控制环节內建到自动化过程中,比如质量保障过程、过程度量、权限控制及过程审计信息等,从而弱化很多传统依靠人为检查的管理流程,实现精益敏捷的轻流程目标。

我们已经明显看到有不少互联网公司,比如阿里、腾讯在组织级提供类似这样的交付平台,然而更多IT企业还没有跟上。

还有一个更重要的关键词必须强调:“自助式”,这是平台设计的前提。我们在有些组织看到确实有类似的持续集成、持续交付平台。然而对这个平台的使用就如同前面提到的集中式IT基础设施服务一样,当交付团队需要为新的应用或服务建立一套新的自动化构建任务,或需要修改现有配置时,必须向平台的负责部门提出申请,由集中式的团队来帮助建立或修改配置。这些配置任务在集中式团队排队和等待,成为新的瓶颈。而产品交付团队自身始终不具备自动化能力,每次变更配置都不得不等待,导致需要的自动化任务跟不上架构的变化,任务失败后定位和解决问题很低效。最严重的是,团队的开发、测试人员根本不关心持续集成的执行和结果。这种模式下,平台其实远远发挥不了它应有的作用。

正确的做法是,平台团队只需要专注于提供自动化、自助式的持续交付平台,将产品交付团队当做自己的用户,听取使用反馈,持续演进;平台的设计必须要兼顾过程的标准化和流水线配置的灵活性;该团队不负责为各产品配置构建任务和流水线。这个配置工作应完全由各交付团队自己来完成,必须要具备“在需要修改配置时随时自己就可以修改”的能力。若没有该能力,组织就要提供培训和赋能。

挑战五:IT架构耦合度高

上图左下方的这栋建筑,住着很多户。如果其中某一户对自己房子的布局和功能不满意,想要重新设计,这时一个房间的设计改动必然影响到其它住户,甚至可能危机整栋建筑。如果要想允许每一户人随时修改自己房子,不用太担心危及整个系统,缩短整个改动的周期,就需要像图中其它的小房子一样,彼此之间松耦合,靠简单、标准的道路来连接。

我们的IT系统也是一样,要实现DevOps的目标,更快地响应业务变化、提高交付吞吐量,每个子系统的粒度就要小,彼此之间松耦合,各自可以独立地进行测试和部署。很多企业多个系统因为耦合紧密不得不在同一时间点部署发布,为了确保每一次投产不出问题,需要投入大量人力来进行协调,投产部署过程要处理更大的复杂性,也更容易引入质量问题。

另一方面的影响是,若单一系统规模大、复杂性高、系统间耦合度高,就难以给予交付团队更大授权、实现开发团队自主运维。

DevOps转型过程中的这一挑战在于,企业必须对现有IT系统进行解耦,将目前很多代码级依赖、数据库级依赖、或业务上的紧密依赖进行解耦,走向围绕业务领域边界建立的、靠轻量级服务和消息集成的服务化架构,要从设计上使得相互依赖的服务之间在升级时做到前向兼容,这是一个困难且耗时的过程;在这个过程中如果没有恰当的架构演进策略,缺少正确的方法引导,导致在服务拆分不合理,或缺少与之配套的服务治理能力,结果可能适得其反。这方面我们有过很多经验教训。ThoughtWorks在实践DevOps的过程中,往往就伴随着大量的向微服务方向进行架构拆分和改造的工作,这一过程可能长达数年,逐步演进。但绝不能知难而退,投入必不可少。

挑战六:职能化组织中的开发运维部门墙

在多年以前,当传统企业的业务发展对数字化的依赖程度还不高,当管理者将IT系统的开发视为一种耗费人力但又价值并不高的非核心能力时,快速膨胀的软件研发队伍纷纷从原有的业务部门中拆分出来,成为了独立的部门或信息技术子公司;随着软件系统的复杂性越来越高,在专业化、流程化的考虑下,实现功能的开发、保障质量的测试和保障运行稳定的运维按职责和技能不同被拆分成了各自独立、相互制衡的部门。结果是各部门有了自己的目标,彼此不同甚至相互冲突,都着眼于各自内部优化;但很不幸地,在这个过程中企业的终极目标——最大化为用户/客户创造价值,这个必须要所有职能作为一个有机的整体运作才能实现的目标——却被弱化了。如下:

在这样的组织设计中,各部分在一致目标下的协作不足,而更加注重过程控制和相互制衡,要真正实现DevOps是不可能的。举几个例子:

在给一些企业评估其持续交付和DevOps能力时,普遍的情况是开发完成的工作进入生产环境要经过冗长的审批过程,审批基于一大堆文档;然而事实是(不要欺骗自己),那些并不了解产品细节和每一次变更细节的审批者,很少甚至从来没有在审批过程中发现过潜藏的问题,但这一过程却严重拉长了新版本上线获得用户反馈的周期;可以说,如果开发团队在提交文档时,某些文档忘了修改、还保持和上一次申请时一模一样,估计那些审批者也发现不了(或者根本就不会细看);

另一个普遍的现实是前面提到过的,开发、测试和运维各自有一套工具来完成自己关心的任务,而这些工具相互割裂、重复建设,没有协作。不一致的工作方式和工具既降低了交付吞吐量,也给质量保障引入了更大风险。

让软件开发的最后一公里——运维环节变得更加敏捷和适应变化,开发和运维职能的紧密协作是DevOps运动的最核心思想。要达到该目标,企业如何为开发和运维建立一致的目标,通过协作而非制衡的方式来共同面对同时提升吞吐量和保障稳定性的挑战是企业实施DevOps最重要的命题!组织需要下面这样一种治理结构:

围绕着提供给用户的产品和服务,建立包括产品设计、开发、测试和运维在内的产品交付团队。这并不意味着组织一定要立即在汇报线的设置上做出改变,关键是如何设置目标和组织日常工作!除了各业务产品,同时集中的IT运维服务部门也应走向产品化,也就是从以往为各个业务产品提供运维支持,转向专注于为业务产品交付团队提供支撑其交付的平台,以及进行运维监控、运营分析的平台;可能也从用户支持统一体验的角度出发,给各业务产品提供面向最终用户统一的支持、服务热线和客户服务渠道。

这种转变对组织是很大的挑战,涉及到多年形成的治理结构的改变。首先需要各级管理者思想上的改变,从基于不信任前提的控制型、分化制衡型管理思想,转变为基于信任前提的服务型、协作型管理思想,这在ThoughtWorks提倡的适应性领导力中有深入探讨。这种转变从一开始,很难在组织大范围开展,建议的是先建立特区,再逐步试点扩大,最后实现突破;在转变的过程中必然会涉及到部门职责范围、绩效考评、人才能力模型等深层次的转变。这种转变需要组织管理者、转型推动者发挥领导力,展现出变革的魄力和执行力才能得以成功。

挑战七:缺少敏捷文化

前面谈到的强职能化组织结构也深刻地影响着一个组织的文化。在与曾经咨询过的一个客户探讨到如何进行DevOps转型时,开发和运维部门坐在一起探讨。大家就运维流程如何改变、自动化能力如何建设等都没有异议,然而自始至终无法突破的终极问题就是:无论我们如何改变,如果万一生产环境出了问题,谁承担责任?因为DevOps能力的建设需要一个过程,开发团队不敢承诺完全承担责任;而运维因为弱化审批和控制力,也认为不该为其承担责任。最终不了了之。

我认为,根本的问题出在文化,旧有的组织治理模式产生了各扫门前雪的官僚文化,没有责任共担,以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维,可能源自组织的绩效考评和激励制度。

现代关于“系统论”的研究已经在很多著作中强调,一个组织就是一个由人构成的复杂系统,组织中每一个人所能获得的信息是有限的(包括最高管理者也是),每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。如果系统发生失败,例如生产环境出现问题,这必然是由于系统各个部分相互作用(从想法提出到软件投产各个环节的相互作用、系统与其它系统间的相互作用)产生的结果,对其中任何局部进行惩罚无非是寻找替罪羊,有害而无益。这时候组织真正应该做的,是相信每一个人都已经做出了最大努力,将相关干系人拉到一起对问题的根因进行分析,找到能够有效避免类似问题再次出现的解决方案,并确保该方案得到实施,对其效果进行验证。

再举一个例子,Petrik曾经在DevOpsDays上提到了一个DevOps的优秀实践:Chaos Monkey(混世魔猴)。这只自动化的猴子会每隔一段时间随机将生产环境服务器关闭,以此来测试生产环境的快速恢复能力,促使各团队提升系统的稳定性。我曾经和国内企业的开发、运维部门讨论过这个实践,有趣的是无论开发还是运维都跳出来反对该实践,认为无法落地。如果没有这只“猴子”,大家可以给领导讲自己的系统很稳定(只要没出问题);然而这只“猴子”可能会随时暴露出自己的系统并不像自己所宣称的那样稳定,会降低自己在上级心目中的“有能力”印象,随之而来的可能就是问责、惩罚。这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。

真正能够实现DevOps的组织,我们认为需要具备下面这样一些文化:

总结

无论是组织治理结构、管理流程、工程技术能力还是文化特征,DevOps运动都和精益产品开发、敏捷宣言所倡导的理念一致。我认为一个组织如果没有充分经历过敏捷文化的熏陶,也很难实现DevOps的目标,充其量在自动化工具和技术能力上有所提升,收益很有限。

因此我们不应当将DevOps作为一个孤立的运动去看待,更不能仅仅从工具角度去实施,而是应当将DevOps作为企业在数字化进程中为追求创新和快速市场响应、为提升组织适应力所进行的精益敏捷组织转型的一部分,这是一项系统工程。 尽管挑战重重,只要管理者首先从自身的管理思想出发做出改变,从组织小范围开始,将各种职能的人员聚拢到一起,设置共同的愿景和目标,打破束缚,给予足够授权,以紧密协作、责任共担的方式共同面对挑战,就能取得成功。然后再将小范围的经验在更大的范围逐步扩散,并适时地对企业深层次治理模式做出调整,就能够在整个企业范围内产生积极影响力,带来组织效能的巨大提升。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

DevOps实践-打造自服务持续交付-下

本文首发于InfoQ:

http://www.infoq.com/cn/articles/devops–build-self-service-continuous-delivery-part02

上一篇文章中,主要讲了DevOps转型的动机、策略和方法,本文将会为大家带来更多DevOps转型的落地策略和实践。

实践过程

下图是我们为团队设计的持续交付流水线,目的是能让Platform团队和交付团队之间的触点能够被融入到持续交付流水线中,并且以基础设施代码作为协同媒介,通过自动化的方式实现开发与运维(即基础设施与软件系统)的无缝对接。

我们来看看我们给持续交付流水线赋予了哪些能力:

  1. 站在交付团队的视角,我们决定将基础设施构建,流水线构建,部署等活动都代码化,与应用代码放在同一个代码仓库中。
  2. 交付团队通过提交我们的基础设施代码到仓库后,自动触发持续交付工具创建或更新流水线。
  3. 接着会自动触发构建,静态检查,测试覆盖率校测,代码规范验证等任务,最终输出构建产物并将构建产物推送到仓库。
  4. 然后会根据交付团队对基础设施和环境的定义到当前要部署的网络环境中去创建或更改虚拟机、网络、存储方式等
  5. 最后,当基础设施创建成功以后,就会去仓库下载指定版本的构建产物进行最终的部署活动。

但需要注意的是:

  1. 为了持续优化交付流程,我们对开发的许多活动进行的数据收集和分析,以报表的形式去分析展示代码提交频率,系统和代码的质量情况,缺陷和构建情况等,帮助团队找到自己的瓶颈或问题。
  2. 帮助团队能够实时监控自己应用的运行状态,设计和查看不同纬度的日志总汇等。

那我们来看看通过什么技术可以实现这样的持续交付流程:

我们选择了一种轻量级、低耦合的技术组合Ansible+Jenkins+AWS。我认为其核心是Ansible。

下面我们来看看Ansible可以帮助我们做些什么:

  1. 创建和更改AWS中的资源
  2. 自动化部署和基础设施测试
  3. 建立开发与平台团队之间的沟通体系

考虑到基于yaml语法的Ansible配置简洁且易读,所以我们选择直接用它作为提供给交付团队的公有DSL模板,利用Ansible Playbook的模块化思想将开发团队的职责和平台团队的职责很清晰的分离,平台团队关注Ansible提供给交付团队的服务是否满足需求和DSL模板是否易用,而交付团队只用关注如何基于公有DSL去定制自己的基础设施,环境依赖和部署等。

于此同时也满足了很多开发对于Ansible和AWS的兴趣和热情,更使得之后在交付团队落地变得更容易。

接下来通过一个实例来看看:

左边是Platform团队的仓库,这个仓库里面包含了创建基础设施、环境配置和部署的实现。

右边是交付团队的仓库,其中deployment目录下,是公有的DSL模板,其中包含多种环境(开发、测试、预生产环境等的独立配置),以及一套基于DSL的代码模板,其中包含创建基础设施和部署应用这两部分DSL代码模板。

接下来,我们来看看它们配合与集成的方式:

他们会在持续集成流水线中被动态组合到一起:

  1. 在创建基础设施和部署的时候会分别拉取基础设施代码库和应用代码库。
  2. 此时应用代码为调用入库,公有基础设施为功能框架库,两者配合,完成环境的创建和应用部署。

在做微服务的团队,接受度非常高,能够快速上手,而且甚至有团队因为自身的一些需求,自己去写一些Ansible模块,然后向我们发起pull request。

当然,我们在推广这套流程的过程中发现,一些实践能够帮助我们更快速落地:

  1. DevOps团队的成员由各交付团队和原运维团队组成,这样的组成方式,能够保证团队的视角可以关注到整个持续交付过程的每个环节。
  2. 交付团队成员与DevOps团队成员定期轮岗制,DevOps小组中的文化(如自动化优先)可以蔓延开,让交付团队更快适应。
  3. 结对、Showcase和培训,主要目的是知识的传递,让更多地团队逐步采用新的交付模式,得到更多改进中的反馈。
  4. 提供给交付团队的自服务代码仓库对每个人开放,交付团队被授权优化、新增基础设施,让DevOps文化和职责落地到交付流程中。

现在来看,集中式、审批式、被动响应请求的中央运维团队不再是整个交付流程中的依赖和瓶颈,已基本转向带自服务化、审查式、主动优化的去中心化交付团队:

我们通过技术驱动改进,让团队之间的合作方式发生了巨大改变,开发与运维之间的那道墙也渐渐消失,以前被动响应请求中央运维团队逐步被平台团队所替代,平台团队中一部分人会负责基础设施平台的发展,负责公有云与企业内部系统的对接、完善安全、灾备、提供基础设施的自服务机制,另一部分人会为产品团队提供可定制的工作、平台、并为产品团队赋能。这时交付团队开始管理自己的环境、维护流水线、负责生产环境变更。

在推广和落地自服务持续交付流程的过程中,我们也遇到了很多遗留系统和复杂部署应用的交付团队,他们无法直接对接这套交付流程。

例如有一个40-50人的团队,它是基于AEM开发整个公司所有的前端门户,AEM是Adobe公司的CMS系统,其安装和部署很复杂,以前都是通过手工安装和拷贝的方式进行部署,而且他们在开发-》测试-》部署阶段可能会动态扩张多套环境来支持,且每次代码变更的提交都会对已经安装的AEM进行修改、配置、重启等操作。

整个开发和测试流程都很复杂,而且效率很低,出现问题和故障的风险也很大,如果我们直接利用Ansible把AEM的安装和部署过程都自动化,由于AEM本身部署的复杂性,可以预见以后这部分更新和维护的工作还是很难交由交付团队自治。所以我们第一步要做的就是为其设计新的持续交付流水线,然后在这个流程中去定义和识别两个团队的职责和关注重心,最后再通过打造高效的自服务使整个交付流程得到改进。

首先我们根据校服团队提交变更的平率,从低到高依次定义了三条持续集成流水线(如下图):

  1. 创建和测试基础设施资源
  2. 配置基础设施资源和环境
  3. 部署应用程

因为AEM安装和更新很复杂,所以我们引入了镜像技术。基础设施和基础设施配置两条流水线的产物为一个image,应用流水线在部署阶段会去检查是否存在新的环境镜像,如果存在,就会基于快速创建一个新的AEM环境,然后进行应用代码的部署。

通过新的自动化持续交付流水线大大加速了AEM团队的开发和测试速度,也使得整个环境更加可控和易维护。对于交付团队来说,他们可以自己去维护包括基础设施、环境变更和应用部署等全生命周期交付活动。对于Platform团队来说,只用去考虑镜像的生命周期管理,如何去优化镜像的创建速度等,这些可以帮助到更多其它团队解决类似问题的领域。对于这种特殊情况,我们尽管引入很多与大多数团队不同的交付流程和技术,但所有的工作和优化都是基于之前打造的自服务持续交付流程、协议和工具平台之上的,保证了不同的交付团队与Platform的配合方式的一致性。

实践启示

通过在大量交付团队落地基于自服务的持续交付流程,两种团队的职责更加清晰了:

所有好的实践都必须考虑规模化的问题,如果无法大规模的被接受和落地,再好的实践也没用。对于咱们这个转型的过程,我也给出一个套路:(如下图)

有了套路,接下来总结一下应用这个套路进行DevOps转型过程中的一些经验和思考:

  1. 易用的通用DSL模板设计,提供交付与Platform团队统一的DSL模板(build and update anything)。
  2. 构建通用持续交付流水框架,提供给交付团队定制化流水线的能力,使流水线主要关注点始终在产品的成功交付。
  3. 以技术驱动DevOps文化大面积传播,让Platform团队成员走入交付团队,协作改进、知识传递,确保实践落地。
  4. 将一切自动化、自服务化。交付团队应该被授权优化、新增基础设施服务,让DevOps能力和职责在交付团队落地生根。

最后,我提取了5点对我们来说非常重要的策略或是推进方法:

  1. 小步快跑,在有大方向的基础上,需要将每一步改变都设计得足够小,这样才能足够快的去改进。
  2. 交付团队赋能,给每个人都留一扇门,在他意识到要做些事情的时候,可以很快付诸行动。
  3. 逐步用基础设施自服务化替代运维部门的审批流程。 建立持续反馈和改进机制。
  4. 以DevOps团队为杠杆,撬动更大范围自服务交付。

非常感谢你的耐心阅读,希望我的文章能够给你带来哪怕一点点启示。有任何问题或是想与我讨论的点都可以给我发Emial: jxzhong@thoughtworks.com


更多精彩洞见,请关注微信公众号:思特沃克

Share

DevOps实践-打造自服务持续交付-上

本文首发于InfoQ:

http://www.infoq.com/cn/articles/devops–build-self-service-continuous-delivery-part01

DevOps转型的动机

我们的客户是一家海外本土最大的金融保险集团,他们在发展到一定规模以后,意识到自己就像一头笨重的大象,举步维艰,通过对整个交付流程的思考和分析,发现了以下一些严重影响交付速度的问题:

  1. 一些好的关于产品改善和创新的想法很难落地。涉及到一些遗留系统的配合:调整、部署、扩展等,使团队对发布没有信心。新的服务或者应用的构建,很难快速上线,被卡在了生产环境部署阶段。
  2. 各种不同种类的应用、服务的部署方式和流程不一致。运维部门作为一个支持部门,很难为大量团队提供快速反应。运维人员对于需要部署和运营环境之上的产品也不够了 解。
  3. 微服务运营过程中,交付团队难以做到快速集成和部署。运维团队对微服务的部署运维方式不理解,依旧老瓶装新药,很难适配新架构下的交付模式。开发团队大多关注代码和架构,对于产品如何能在生产环境稳定运行、需要考虑哪些安全性和可持续性的因素并不是很了解。

问题分析和挑战

通过对这些问题和各个团队反馈的深入分析,发现其中最大的瓶颈在于交付团队与运维部门之间的各种依赖和沟通浪费,而这个瓶颈又是解决大多数问题的前提。

我们将瓶颈具象化后(如上图),可以看到两种团队之间其实是存在一堵墙的,一是因为传统的部署流程非常繁琐和低效。二是因为两种角色关注点和目标的不一致。

如果在这样的情况下,想实现微服务架构转型,实现更快速和安全的交付,只会更快的暴露出这堵墙引起的各种问题。开发阶段,系统的架构和依赖环境都是Developer说了算,对生产环境的关注度不高。部署、发布阶段,Operations会考虑如何构建一套稳定的基础设施,又如何去部署和运维开发的产物,但是往往对于产物的了解不充分,对于产物的周边生态和与它们关系的了解也不够。

那么引入DevOps文化,消除开发与运维之间的壁垒,逐步打造更高效的交付流程就成为我们破局的关键,那我们应该怎么做呢?

改革之初,我们发现并去尝试了Bimodel(双模IT), 我们看看它是否能解决我们的问题:

先简单介绍一下什么是双模IT:

它将IT系统分成了两种模式:

  1. 一种是新型的数字化、高市场适应性的IT,这部分业务聚焦企业新市场和业务的开拓,创新和发展,强调IT自身对于市场的高适应力。
  2. 另外一种模式下,我们则需要稳固发展,对于传统模式我们倾向于更加严谨和标准的流程去保护现有业务,稳定性比速度更加重要。

我们从采用这样一种模式的实践案例中发现:组织内部会出现连两种速度的交付流程,好的情况可能是采用敏捷开发流程的交付线,有着快速的交付能力,相反,对于继续采用传统开发流程和运维方式的团队,保持着稳定但低效的交付能力。

从业界很多公司的现状和发展趋势来看,双模IT确实是很多组织存在的现状或是必然经历的过程,但不是一个好的模式,从实际的交付过程来看,存在4点问题:

  1. 双模IT的划分方式更多是基于软件系统,而不是从业务活动出发进行的,所有软件系统的交付都应该是面向业务价值的。
  2. 双模IT会让我们误以为速度的提升会引起质量的下降,但是对于我们在ThoughtWorks的很多敏捷实践中学到的:随着交付的推进,质量内建是团队共同负责和持续改进的重点。交付速度的提升,往往都伴随着质量的保障,而不是忽视质量。
  3. 实际生产中,一个新的产品或者功能往往会依赖很多遗留系统提供的服务,如果它们仅仅只能达到稳定和低效的交付,对企业来说对市场整体的响应能力也会越来越低。
  4. 企业的创新不仅仅只是从零创造一个新的产品,还有很多机遇现有的资源。一个新的系统和功能往往不仅会既涉及到新服务、应用的创建,也会涉及到遗留系统的修改,调整和改造。

由此可见双模IT是在以一种试图掩盖问题的方式来逃避目前最重要的问题:开发和运维之间的壁垒。感觉像是一个病人先是放弃治疗,然后又努力的寻找延长寿命的方法,有些隐患终会爆发。

打造自服务持续交付

紧接着,我们开始采用了一种看似不可行的方式开启了DevOps转型,建立公有DevOps团队。有很多人可能会说这是一种反模式,怎么可能会建立一个团队专做DevOps相关的事情,那和以前的运维部门又有什么区别?DevOps提倡的Dev与Ops高频度合作的文化是不是就无法大面积传播了?

因此我们需要很明确的定义我们对这个团队的期望和它的职责是什么,它是怎样和交付团队合作,影响交付团队,最终能让DevOps的文化可以大面积传播。这个团队的目标是要像杠杆一样,翘起更大面积的DevOps变革。

所以我们认为公有DevOps团队应该与其它的端到端交付团队的人员构成是一样的。不同的只是目标和价值,主要体现在帮助更多的团队植入DevOps文化、优化持续交付流程。最终达到的目标是每个团队都可以自治,每个团队都可以进行端到端的开发、测试和部署,并可以自驱动的持续改进。与此同时,这个团队不仅仅只是为交付团队提供更多涉及基础设施、持续交付流水线、部署等活动所需要的自动化能力,还会支撑交付团队根据自身的上下文去定制和规划自己的持续交付流程和部署策略等。

(图片来自:http://t.cn/R9jnzHR)

现在,相比于DevOps团队的叫法,我们更愿意称呼这个团队为Platform团队,一个原因是我之前所说的避免被错误理解,另一个原因是随着各个交付团队逐步实现自服务持续交付,这个专有团队也有了更高的目标:持续打造和优化一个能够支持各交付团队快速交付的平台。

当时,我们首先为团队定义了新的工作方式:以自服务,自动化和协作 作为核心文化,希望团队通过提供便捷的基础服务,让交付团队拥有自动化的交付流水线,并通过更多的沟通协作,尽可能让每个交付团队都能够独立自主的设计、创建和更改自己的基础设施。然后再根据各个交付团队的实施情况和结果来对流程和服务持续改进。

所以第一件事,我们首先设计了一个高效的持续交付流水线,让Platform团队和交付团队建立触点:

如下图所示,蓝色的基因链为交付团队的持续交付环,红色的基因链为平台团队的持续交付环。两种团队以某种低耦合的弱连接进行全程协作,Platform团队在整个端到端的交付过程中都要能尽量通过构建自动化能力来支撑交付团队能够快速、安全的进行持续集成、部署等活动。这样的合作方式也给我们提供了优化触点的可能性,也能够通过优化和改进,缩小这个持续交付周期,让交付更高效。

请原谅我在这篇文章进入高潮时卖个关子,由于考虑到大家的阅读体验,所以文章分成了上、下两个部分,上半部分主要讲DevOps转型的动机、策略和方法,下半部分会讲我们如何实际应用基础设施即代码来建立Platform团队和交付团队的触点, 又怎样让遗留系统团队和微服务团队的交付速度成倍增加。敬请期待!


更多精彩洞见,请关注微信公众号:思特沃克

Share

从集装箱历史看DevOps的发展进程

什么样的技术会带来生产力的极大提升?技术含量是否与生产力提升成正比关系?

带着问题,我们先看一个例子:在工业革命时期,瓦特用于“改良”蒸汽机的技术,就是极大提升效率的技术。

这里有一个误解,有人认为瓦特发明了蒸汽机。其实不然,瓦特只是改良了纽卡门蒸汽机,通过橡胶增加密闭性同时优化机械结构,使得原本只能用于提水的笨重机器,变得能被广泛应用,为第一次工业革命的兴起奠定了重要基础。

从上面的例子可以看出技术含量的高低与带来生产力的大小并没有直接关系。

传奇的集装箱

我们来看另外一个有趣的故事,希望你能从中得到启发。那就是改变运输业、对制造业有着深远影响的一项革命性技术——集装箱(英文container,你没看错,它的名字和现在火的一塌糊涂的“容器技术”同名 )。

说到集装箱不能不提马尔科姆·麦克莱恩(1915—2001),20世纪四十年代美国一家运输公司的老板,由于改造(改造不是发明)了集装箱、提高了集装箱的便利性,推动了整个运输行业的巨大变革,而被尊称为“集装箱运输之父”。

那么问题来了:改造蒸汽机也许有些技术含量,但是技术含量连罐头都不如(抽真空和密封技术)的集装箱怎么可能有这么大的影响呢?

(集装箱之父麦克莱恩:改造不仅限于集装箱本身,还包括港口和货轮等运输环节)

我们知道工业社会最重要的竞争来自于节约成本,如果一个技术可以节省95%的成本就相当于带来20倍的效率提升。这种技术可以说是颠覆性的,而集装箱就是这样的技术。

麦克莱恩在纽约港第一次做的集装箱运输实验就实现了20倍的效率提升:使用集装箱运输啤酒,将每吨啤酒的运输成本从4美金变成20美分。

过程是这样的:从啤酒工厂把啤酒装入集装箱开始,通过陆路转海路运输到目的地,省去了工厂到陆路运输、再到海洋运输的中间人力搬运过程,因此从工厂到码头的装卸时间大大缩短,由数天压缩到数小时,从而使得美国到欧洲的货运时间足足减少了4周。并且由于集装箱的堆叠使得每一艘船只的储运量比以前提高了6倍。

在传统运输过程,货物没有统一的包装标准,这既限制了运输工具的运载量,又增加了货物在从陆路运输到海路运输低效的手工搬运过程。集装箱这个标准化的运输单元,就为在整个运输系统优化中间流转效率提供了一种可能。

(运输体系中间环节)

看到这里,我不由得联想到传统软件研发测试与发布的过程。虽然每个过程内部自动化程度很高,但是部门之间的流转却依靠低效的手工操作,这些过程大大降低了整体效率。

系统性创新的窘境

但是非常意外的是,麦克莱恩在接下来10多年的航运生意中不仅没赚到钱,反而是亏损了。这就太奇怪了,一个能让效率提升20倍的技术,为什么会不赚钱呢?

原因在于,在当时的运输行业,大部分货物并没有使用集装箱,大量的手工搬运使得船只装卸货物并没有节省多少时间,还有集装箱运到目的地后,箱内的货物需要分别运到不同的地方等等。

因此集装箱技术并不在于“箱子”本身,而在于需要整个运输系统的创新——在道路、桥梁、卡车、码头和吊装设备等基础设施没有针对“箱子”进行优化的情况下,集装箱技术无法发挥出原有的效能。

让我们回到最开始的问题:“什么样的技术会带来生产力的极大提升呢?”

那些创新了人与事物连接方式,且极大降低这种连接成本的技术,才能真正促进生产力的提升。

DevOps正是这样的技术,它是针对研发系统的一次系统性创新。其创新性在于针对整个研发系统中的各个子系统进行交付与反馈的优化,从而有效提升整体效率。

相对于传统软件6个月发布一次,2009年John Allspaw 和Paul Hammond在Flickr可以实现每天发布10次,将软件发布频率提升了将近两千倍,极大地降低了软件发布的成本。

但是大部分公司在实施DevOps的过程中,并没有有效提升发布频率,这一点与集装箱在最开始的10年内并不赚钱的道理是相似的。

(应用研发平台:描述构建软件包,在不同的环境进行测试、最终发布生产环境的过程)

问题在于系统性创新初期,各个环节没有对新技术进行优化,部分环节甚至会阻碍新技术发展,导致新技术无法提升效能。

转机带来的启示

一切直到1967年才出现转机。美国发动了越南战争,美军需要将大量物资运输到亚洲。在长期的优化实践中,美军得出高效运用集装箱的3C原则:一种货物、一个地址、一个客户

从此,集装箱的时代到来了。只在1967年一年的时间里,麦克莱恩就从美国国防部赚了4.5亿美金。低廉的海运成本、大大缩短的运输时间以及到货时间的可预期,让全球制造业的分工协作效率得到极大的提高。行驶在大洋上的货轮,就像在生产车间里运输原材料的叉车一样,使得制造业不必大量囤积原材料,后来丰田的“零库存”计划更是将原料的管控能力发挥到了极致。

为什么3C原则可以极大提升效率?它正是通过解决运输“中间环节”过程的低效问题,使得总体效率得到极大提升。下面分别加以说明:

  • 一种货物:在货物“装箱”过程,统一货物的来源与种类,标准化货物装箱过程。
  • 一个地址:在货物“分拣”过程中,不会打开集装箱,只做一次装箱。
  • 一个客户:在货物“送货”过程,只有一个客户,简化送货的过程。

DevOps流程的3D原则

与如何高效利用集装箱类似,在DevOps实施过程中,通过优化流水线中间流转过程,提升总体效率。

下面举出与3C原则对应的3D原则:

  • 一键式部署(Automatic Deploy):部署过程中,标准化部署过程,实现一键式部署
  • 一次构建打包(Automatic Delivery):在测试环境、UAT环境和生产环境的流转过程中,只打包一次,软件包按顺序自动交付到各个环境,最终发布到生产环境
  • 一次配置分发(Automatic Distribution):在生产环境发布过程,建立统一的配置分发管理,将繁琐的分布式环境配置一次分发到各个数据中心,简化发布过程。

“科技是第一生产力!”如果我们以技术含量来衡量一个创新会很容易走入误区。集装箱发展历史告诉我们,从状态的流转环节入手,降低流转成本是提高总体效能的另外一个途径。

集装箱发展历史的前十年完成了道路、桥梁、隧道、卡车、码头设施、吊装设备的优化,以适应集装箱的发展。这个进程的难点在于,以一家运输企业推进整个运输体系针对集装箱的优化。

随着技术的发展,DevOps的周边环节正在逐步完善,DevOps实施的3D原则,也让我们走入故事的后半段,就像集装箱的故事那样。


更多精彩洞见,请关注微信公众号:思特沃克

Share