DevOps发展的9个趋势

DevOps包含了太多方面的技术和实践,很难通过一个统一的工具链来描述其发展。即便如此,我们仍然可以从ThoughtWorks技术雷达的条目变动中看出一些趋势。今年,我有幸作为主编参与了最新一期技术雷达的译制,作为DevOps的爱好者,十分高兴能在这一过程中看到DevOps未来发展的几个趋势,总结成了这篇文章。

趋势1:微服务目前仍然是DevOps技术应用和发展的主要领域

微服务将单块应用系统切割为多个简单独立的应用。从技术上说,这是通过工具把应用程序的内部复杂度转化为外部复杂度,需要一系列工具支撑微服务本身以及服务之间的通信。从组织上说,微服务团队要满足“快速发布,独立部署”的能力,则必须具备DevOps的工作方式。

如何拆解微服务一直是微服务技术应用的最大难点之一,领域驱动设计是比较理想的微服务拆解方法论。社会化代码分析帮助团队通过更精确的数据找到更加合适的拆分点。CodeScene是一个在线服务,它能帮助识别出热点和复杂且难以维护的子系统,通过分析分布式子系统在时间上的耦合发现子系统之间的耦合。此外,它还能帮你认识组织中的康威定律,这会大大降低微服务解耦的难度。

此外,微服务系统本质上是一个分布式系统,分布式系统之间的通信一直是很重要的问题。本期介绍的Kafka StreamsOpenTracing就是这类技术的条目。Kafka作为一个成熟的分布式消息系统已经被广泛采用,而Kafka Streams则将最佳实践以“库”的方式呈现给开发人员,使得操作Kafka更加自然和简单。而OpenTracing则弥补了跨越多个微服务之间请求追踪的空白。

另一方面,无服务器风格的架构(Serverless architecture)把DevOps技术在微服务领域的应用推向极致。当应用程序执行环境的管理被新的编程模型和平台取代后,团队的交付生产率得到了进一步的提升。一方面它免去了很多环境管理的工作,包括设备、网络、主机以及对应的软件和配置工作,使得软件运行时环境更加稳定。另一方面,它大大降低了团队采用DevOps的技术门槛。

然而,端到端交付以及微服务中的函数管理问题日渐突出。尽管AWS API gatewayAWS Lambda几乎成了Serverless架构的代名词,但这二者结合的开发者体验并不佳。于是出现了Serverless frameworkCLAUDIA这样的管理工具。

AWS Lambda带来的优势也深深影响了企业级应用领域,Apache OpenWhisk就是企业级无服务器领域的选择之一,它使得企业级应用也可以采用无服务器风格的架构构建应用程序。

在微服务端到端交付流程上,Netflix开源了自家的Spinnaker,Netflix作为微服务实践的先锋,不断推出新的开源工具来弥补社区中微服务技术和最佳实践的缺失。而Spring Cloud则为开发者提供了一系列工具,以便他们在所熟悉的Spring技术栈下使用这些服务协调技术(coordination techniques),如服务发现、负载均衡、熔断和健康检查。

而在微服务的安全上,最常见的需求之一 是通过身份验证和授权功能来保护服务或API。这部分功能往往是最重要且不断重复构造的。而Keycloak就是一个开源的身份和访问管理解决方案,用于确保应用程序或微服务的安全。且几乎不需要编写代码,开箱即用。它支持单点登录,社交网络登录和标准协议登录(如OpenID Connect,OAuth2和SAML等)。

趋势2:以Docker为核心的数据中心方案逐渐走向成熟

在过去的两年,Docker社区有了突飞猛进的发展,似乎每期技术雷达都会出现Docker相关的条目。而Docker往往和DevOps联系起来,被认为是推动DevOps发展的杀手级工具,以至于有些人会以团队是否采用Docker作为团队是否具备DevOps能力的标志。

而这一社区的创新数量则日渐平缓。一方面,开源社区激烈的竞争淘汰了一部分技术。另一方面,以Docker为中心的完整数据中心解决方案在不断的整合开源社区的零散工具并形成最佳实践。为端到端的开发和运维提供更完整的交付体验,各大厂商也相继开始推广自己的企业级整体收费解决方案,这表明Docker的使用已经走向成熟。

​在本期的技术雷达里的条目中出现了Mesosphere DC/OS,这是构建统一技术栈数据中心的一个征兆。在这方面Docker EERancher都是非常有力的竞争者。根据我的判断,在未来的Docker社区里,统一容器化数据中心的竞争者将会进一步减少。而之前的私有云方案则慢慢会被“以Docker为核心数据中心级全栈交付”取代。

趋势3:不完整的DevOps实践阻碍着DevOps的发展

很遗憾看到单一持续集成实例不完整的持续集成(CI Theatre)这样的条目出现在技术雷达里。可以感到企业应用DevOps技术的紧迫性。这同时也暴露了DevOps领域里“缺乏门槛较低且成熟的技术实践”的问题。

大部分企业在DevOps转型中仅仅关注到了工具的升级。却忽视了价值流、生产流程中各个活动中的最佳实践以及DevOps团队文化的构建,这会使团队陷入“已经完成DevOps转型的假象“,而停止了团队的自我改进。

DevOps的实践包含组织改进和技术升级两个部分,技术往往是最容易的部分。而缺乏组织改进的技术提升往往很难给组织带来质的飞跃。具备DevOps文化的团队则会不断反思和学习,通过共担责任和相互合作不断完善组织的DevOps实践。

趋势4:领域特定的DevOps实践开始出现

DevOps的最早实践来自于互联网企业的Web应用,相应的思想被引入企业级应用并促进了一系列工具的发展。虽然并不是每一种应用软件交付形式都适合DevOps,但随着DevOps的工具不断成熟。其它领域的DevOps实践也开始尝试借鉴Web应用领域的自动化工具,并逐渐形成领域级的DevOps实践。

在人工智能领域,TensorFlow就是这样一个例子,它可以有多种DevOps友好的安装和部署方式 ,例如采用Docker进行部署。

在区块链领域,超级账本(HYPERLEDGER) 就是这样一个例子,它提供了一套工具和服务,结合DevOps相关技术和实践形成了一个完整的解决方案。

随着DevOps相关概念和技术不断向各个产业领域的深入发展,可以看到DevOps技术和实践带来的巨大影响力。然而,每个技术领域都有自己所关注的特性,并不是以往的DevOps实践可以全覆盖到的,这恰恰成为了DevOps技术和实践发展的契机。我很期待领域特定的DevOps技术实践给DevOps带来的发展。

趋势5:采用DevOps进行技术债务重组和技术资产管理

技术债务类似于金融债务,它也会产生利息,这里的利息其实就是指由于鲁莽的设计决策导致需要在未来的开发中付出更多的努力。

投资银行业往往采用多种金融工具组合的方式来处理企业的不良债务。而清理技术债务的实践和工具却乏善可陈。

技术债务不光阻碍了企业通过新技术带来便利,还使企业偿还技术债务所承担的成本越来越高,例如技术人才的流失,技术利息等综合性风险。

虽然极少会出现企业因技术债务而走向衰败的案例,但新晋企业凭借新技术和商业模式颠覆传统行业并夺取市场份额的报道却不断发生。 这从另一方面说明技术债务综合提升了采用新技术的机会成本,使企业不断失去创新和领先的巨大潜力。

DevOps技术栈的多元化为分散遗留系统技术债务风险提供了一套灵活而又低风险的工具和方法论。不断帮助企业从遗留系统的负担中解脱出来。

而微服务则是首先通过领域拆分技术债,并用相应工具重组技术债。分离优质技术资产和不良资产,通过分散风险来降低抛弃成本。 而将API当做产品(APIs as a product)可以从一个全新的演进视角去看待技术债,通过可用性测试和用户体验研究帮企业剥离出技术债务中的优质资产和不良资产。

另一方面,本期技术雷达中出现了封装遗留系统这样的实践,它往往配合着Vagrant,Packer和Docker这样的工具一起使用。一方面它将技术债务的风险进行了隔离,另一方面它防止了遗留系统上产生的技术债利息的增长。

趋势6:安全成为推动DevOps全面发展的重要力量

安全是DevOps永远绕不开的话题,也往往是新技术在传统行业(例如金融和电信)应用中的最大阻碍。一方面,组织结构的转型迫使企业要打破原先的部门墙,这意味着很多原先的控制流程不再适用。另一方面,由于大量的DevOps技术来源于开源社区,缺乏强大技术实力的企业在应用相关技术时不免会有所担忧。

从代码中解耦秘密信息的管理则让我们避开了一些开发过程中可能会产生的安全隐患。采用git-crypt这样的工具可以帮我们保证在开发的过程中源代码内部的信息安全。而采用HashiCorp Vault则提供了脱离应用程序代码的秘密信息存储机制,使得应用在运行过程中的秘密得到了有效保护。

Linux Security Module则一直在技术雷达的“采用”区域,通过SELinux和AppArmor这样的LSM兼容帮助团队评估谁可以访问共享主机上的哪些资源(包括其中 的服务)。这种保守的访问管理方法将帮助团队在其SDLC流程中建立更好的安全性。以往这是Ops团队需要考虑的问题,而对DevOps的团队来说,这是每一个人的事情。

“合规性即代码”(Compliance as Code)是继“基础设施即代码”,“流水线即代码”之后的又一种自动化尝试。InSpec作为合规性即代码的提出者和实现者,通过自动化手段确保服务器在部署后的运维生命周期中依然保持安全与合规。它所带来的意义在于将规范制度代码化,得到了确定性的结果和解释。

在不远的将来,不难想象人们所面对的法律和法规规定不再是一堆会导致歧义的语言文字条目,而是一组由自动化测试构成的测试环境。

安全性和易用性往往被认为是鱼与熊掌不可兼得的两个方面。在DevOps之前,团队吞吐量和系统稳定性指标曾经也面临这样的境遇,然而DevOps使得二者可以兼得。同样我也有信心看到在未来DevOps的领域里,更多易用且安全的工具将会不断出现。在降低DevOps所带来的安全风险的同时,也提升团队开发过程的顺畅性和用户便利性。

趋势7:Windows Server和.NET平台下的DevOps技术潜力巨大

长期以来,Windows和.NET平台下的DevOps一直都是一个被低估的领域。一方面,社区缺乏对 Windows Server平台的兴趣。另一方面,Windows Server却有接近90%的市场占用率,在Web服务器领域则有33.5%的市场占有率

有充足理由证明这是一个潜力巨大的市场。 我们看到了CAKE和FAKE这样的条目,作为.NET平台下替代MSBuild的构建解决方案, 它增强了.NET平台自动化方面的能力。而HANGFIRE则提供了更易用和灵活的自动化进程调度框架。我很期待未来有更多Windows Server和.NET平台领域的创新。不久前,Docker已经可以在Windows下运行。可以预见到,Windows Server和.NET平台将会是下一阶段DevOps技术实践中值得深入发掘的领域。

趋势8:非功能性自动化测试工具的逐渐完备

自动化测试水平往往是衡量DevOps技术能力高低的重要指标,尤其是针对生产环境应用程序的非功能性自动化测试工具。一直以来,技术雷达都在尝试从不同的角度宣扬自动化测试的重要性,从软件的开发阶段延展到了整个应用生命周期甚至整体IT资产的管理上。

这期的技术雷达仍然关注了非功能性自动化测试,TestInfra是ServerSpec的Python实现,它使得用Pytest测试基础设施成为可能。而MOLECULE旨在帮助开发和测试Ansible的Role 。通过在虚拟机或容器上为正在运行的Ansible Role测试构建脚手架,无需再手工创建这些测试环境。正如技术雷达所说的:“虽然这是一个相当年轻的项目,但我们看到了其蕴含的巨大潜力。”

趋势9:Python成为DevOps工作中所不可或缺的语言

早在DevOps刚刚开始盛行的时候,Python就是一个被寄予厚望的语言,因为大部分DevOps工具和实践都需要用到Python。虽然也有人尝试用Ruby或者NodeJS构建DevOps工具,然而都没有Python所构建的工具流行。与此同时,仍然不断有人把其它语言下编写的工具转化为Python的版本,TestInfra就是这样一个例子。

随着Python在大数据、人工智能、区块链、微服务以及Docker中的发展,可以预见Python在日后的领域仍然会发挥重要的作用。

以上对DevOps趋势的解读仅为个人观点,如有不当之处还望指出。关于更多技术在技术雷达中的使用建议请参考这里,谢谢。


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

Share

实例化DevOps原则

【摘要】

  • DevOps原则所追求的愿景,就是“让业务所要求的那些变化能随时上线可用”;
  • DevOps的起源表明,其原则是从Agile与Lean的实践当中提炼而来,因此与Agile和Lean的原则并无二致;
  • 本文所讨论的DevOps原则可以用“人、产品、流程和工具”这4个维度来进行组织。

【正文】

“你在做用户故事拆分?这不是在做DevOps。”这是笔者在2016年以咨询师的身份,参与一家大型跨国金融企业的Agile和DevOps转型时所听到的话。在这家企业,Agile和DevOps明显指的是不同的东西:前者专指每日站会、计划会、回顾会等Scrum的实践和用户故事实践;后者专指自动化、工具链和基础设施等实践。过了一段时间,笔者把本文所列举的一些DevOps原则发到一个相关微信群里面,得到了这样的反馈:“怎么满眼都是敏捷和精益?”“感觉DevOps被一群不操作Op的人给玩儿坏了。”

这些经历让笔者开始关心这些问题:既然Dev指的是“开发”,Ops指的是“运维”,那么到底什么是DevOps?它的原则是什么?它和敏捷、精益的关系是什么?让我们先观察一下DevOps的起源[1][2]

DevOps的起源可以分为两条线

第一条线是:比利时独立咨询师Patrick Debois

2007年他在比利以咨询师的身份,参与了一个政府数据中心迁移中的测试工作。他在做测试时,需要频繁往返于Dev团队和Ops团队之间。Dev团队已经实践了敏捷,而Ops团队还是传统运维的工作方式。看到Ops团队每天忙于救火和疲于奔命的状态,他在想:能否把敏捷的实践引入Ops团队呢?

第二条线是:当时雅虎旗下的图片分享网站Flickr

这家公司的运维部门经理John Allspaw和工程师Paul Hammond,于2009年6月23日在美国圣荷西举办的Velocity 2009大会上,发表了一个引燃DevOps的演讲。这个演讲的题目在当时很抢眼--《每天部署10次以上:Flickr公司的Dev与Ops的合作》[3]

这个演讲有一个核心议题:Dev和Ops的目标到底是不是冲突?传统观念认为Dev和Ops的目标是有冲突的——Dev的工作是添加新特性,而Ops的工作是保持系统运行的稳定和快速;而Dev在添加新特性时所带来的代码变化,会导致系统运行不稳定和变慢,从而引发Dev与Ops的冲突。然而从全局来看,Dev和Ops的目标是一致的,即都是“让业务所要求的那些变化能随时上线可用”。

这样抢眼的题目和鲜明的观点,自然抓住了当时还在比利时的Debois。他在“推特”上发帖:“可惜没法去现场参加。”朋友Paul Nasrat回帖说:“为什么不在比利时搞一个你自己的Velocity大会?”这两条线使得Debois撸起袖子,于2009年10月30至31日,在比利时的第二大城市根特,以社区自发的形式举办了一个名为DevOpsDays的大会。这次大会吸引了不少开发者、系统管理员和软件工具程序员。这两天大家聊得太开心了,会议结束还不过瘾,回去继续在“推特”上聊。限于推特140个字符的制约,Debois把DevOpsDays中的Days去掉,而创建了#DevOps#这个“推特”聊天主题标签,DevOps诞生了。

Flickr公司的两位演讲者所表达的“Dev和Ops的共同目标是让业务所要求的那些变化能随时上线可用”这一观点,其实就是DevOps的愿景。而要达到这一点,可以使用一个现成的工具:精益。源自丰田生产方式的“精益”的愿景就是“Shortest lead time”,即用最短的时间来完成从客户下订单到收到货物的全过程。这恰好能帮助实现DevOps的上述愿景。《持续交付》的作者之一Jez Humble也体会出精益在DevOps中的重要性,以至于他把DevOps的CAMS框架修订为CALMS[4],其中增加的L指的就是Lean(精益),这一点下文还会提及。

从上面DevOps的起源中能够看出三点:

  1. DevOps源自草根社区,最初并没有什么自上而下设计出来的理论框架;
  2. DevOps背后的原则,就是上面两条线中所涉及的敏捷和精益的原则;
  3. DevOps的愿景是让业务所要求的那些变化能随时上线可用。

一旦了解了上面第2点,就不会有前文中所说的“Agile和DevOps是不同的东西”和“感觉DevOps被一群不操作Op的人给玩儿坏了”这样的说法。

因为DevOps源自草根,没有什么框架,所以如何定义DevOps成了DevOps社区里面的一个大难题[5]。一些DevOps从业者,纷纷设定自己的DevOps框架。其中比较有名的框架有上文提到的Damon Edwards所定义并被Jez Humble所修订的CALMS,和Gene Kim所定义的The Three Ways[6]

CALMS:

  • Culture – 文化:公司各个角色一起担当业务变化,实现有效协作和沟通;
  • Automation – 自动化:在价值链中尽量除去手工步骤;
  • Lean – 精益:运用精益原则更频繁地交付价值;
  • Metrics – 度量:度量并使用数据来优化交付周期;
  • Sharing – 分享:分享成功和失败的经验来相互学习。

The Three Ways:

  • The First Way: System Thinking (系统思考:强调全局优化,避免局部优化);
  • The Second Way: Amplify Feedback Loops (经过放大的反馈回路:创建从开发过程下游至上游的反馈环);
  • The Third Way: Culture of Continual Experimentation And Learning(持续做试验和学习的文化:持续做试验,承担风险、从失败中学习;通过反复实践来达到精通)。

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

本文试着从“人、产品、流程和工具”4个维度,来梳理DevOps的一些原则。为什么会有这4个维度?

先看前三个维度:“人”、“产品”和“流程”。在一百多年前的工业经济时代,由于物质匮乏,所以当时占主导地位的泰勒科学管理理论将“流程”这个维度放到了第一位,让企业首先通过标准化的“流程”达到规模化的制造能力,来满足供不应求的市场。市场上可购买的商品少,人们对“产品”的质量、设计也就不介意了,所以“产品”排在了第二位。而标准化的流程把工人的素质标准降到了最低,只要带着一双手来,在流水线上重复一个动作就好了,不需要动脑子,因此“人”排在了最后的位置。

一百年后,工业经济霸主的地位已被知识经济所取代。在具有知识密集特点的敏捷软件开发的上下文中,这三个维度的顺序颠倒了:“人”的优先级最高,因为只有依靠“人”的创造力才能应对多变的业务需求;给用户提供价值的“产品”依旧排第二位,因为这是企业赖以生存的根基;而“流程”可以为了“人”来高效地实现“产品”而进行定制,所以优先级最低。而强调自动化的DevOps离不开好用的“工具”,“工具”又可以依据流程来定制,因而可以补在“流程”的后面。

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

下面所描述的DevOps原则,来源于敏捷、精益和DevOps的一些具体实践。虽然没有涵盖DevOps的所有实践,但已经包括笔者最近一年在DevOps的实践中所感悟的主要内容,而且今后会继续完善。

一般的文章对于“原则”的阐述都比较抽象,有点像上面提到的CALMS和The Three Ways这两个框架的定义方式那样——仅仅把几个名词或短语放到那里。对于不熟悉Agile、Lean和DevOps的人来说,看了上述框架还是不知道DevOps到底是做啥的。

为了让DevOps原则的描述更加具体生动,笔者参考敏捷宣言的写法和实例化需求的做法(即用具体的实际例子来编写验收条件),使用了“高于”和“而非”的句式来对比两个具体实践的实例,且尽量用一些具体的实践来代表相应的原则,如“部署流水线”等。其中,“高于”表示右边的实践虽然不如左边的好,但还是有价值的。“而非”表示右边的实践并不值得推荐。这就是本文标题中“实例化”的由来。

1. 人

领导者身体力行持续改进 高于 关注工具和基础设施

很多企业(包括笔者所辅导的企业)都在实践DevOps。要想让DevOps这颗树苗茁壮成长,企业要为其提供一个良好的土壤——即企业文化。而企业文化,是企业领导者引导塑造的。DevOps对于国内大部分企业来说,都是一个前所未有的新事物。必须通过不断做试验,才能找到培育它生长的土壤方,做试验就是为持续改进做准备。笔者所辅导的企业,工程师被项目进度压得喘不过气来,根本没有时间学习新工具和新方法,更别提做试验了。

(图片来自:http://www.yes123.com.tw/)

所以只有领导者身体力行,不仅自己亲自做试验和进行持续改进,并给工程师足够的时间来做试验和持续改进,这样所创造出良好的环境,才能让那些自动化工具和基础设施在企业内部得到有效利用。

试验并改进流程 而非 指责人的过失

丰田公司有一句口号:“对流程苛,对人员柔”,意思是说:每位员工都会尽力做好工作的,那些在工作中所出现的问题都是流程的问题。因为根据这种有问题的流程来工作,无论是谁都会出同样的问题。前面说过,DevOps对于国内大部分企业都是新事物,需要做试验来“摸着石头过河”,做试验就有失败的时候,此时就要调整流程,而不是怪罪于人,否则企业没有人会去继续尝试DevOps。

产品思维 高于 项目思维

根据这一个原则可以定义“人”的组织结构——团队结构,即可以按照产品而不是项目来组建团队。这样的产品团队包括了Dev、Ops、BA、Tester、PO和Architect等各种角色,他们相互配合且不依靠团队以外的其他角色就能独立自主地交付软件产品,这个产品团队负责该产品从生到死的全生命周期,并且只要产品还在,这个团队就不会解散。这种设置会让团队的不同角色目标一致,比起从目标不一致的各种职能团队(比如Dev团队、Tester团队和BA团队)抽调人员拼凑成临时的项目团队,磨合期更短,更加有战斗力。

2. 产品

质量和安全内建 而非 晚期度量和检查

产品需要质量和安全来保证价值。人们长期认为“高质量”意味着“高成本”,因为要维护高质量,需要在产品出厂前做大批量检测,并销毁那些次品,这就花费了高昂的成本。但丰田公司却说“高质量是免费的”[7]。这是怎么做到的呢?这其实就是前文提到的丰田公司“对流程苛”的结果。丰田公司通过持续改进流程,“一次就根据最佳流程或实践把事情做对,并持续改进这些流程和实践,使其一直保持最佳”,这样就能在脱离后期大规模检查的情况下保证高质量,同时其成本也趋近于零。

客户反馈 高于 按期交付

产品是否实现了价值,只有通过客户的反馈才能知道。很多团队往往过分关注交付期限,而忽视客户反馈。这样做的后果,就是虽然按期交付,但是产品却不是客户所期望的,造成返工或项目失败。

基于不可变容器的微服务 高于 单块应用

产品需要能快速地开发、测试和部署才能有效地交付价值。对于复杂度高的大型产品,如果可以由多个微服务组合而成,每个微服务都能独立地开发、测试、部署和上线。这比起必须集成各个模块才能进行手工测试的单块应用来说,更能实现各个微服务之间的并行研发,加快每个微服务的开发下游至上游的反馈环的反馈速度,进而缩短项目进度,让价值交付得更快。不可变容器指的是软件产品被封装到一个类似docker这样的容器内上线,且上线后不可手工修改其配置。如果一定要修改,也只能通过部署流水线把要修改的内容重新打包成另一个新的不可变容器来上线。这样做的好处是能够实现部署和发布自动化以及进行更好的版本控制,消除线上手工配置所带来的无法审计的风险。这一实践是本文写作时期的推荐实践,该实践今后还会继续演进。

3. 流程

管理层实践Improvement Kata和Coaching Kata进行流程持续改进 高于 用结果导向进行管理

佛家说:“菩萨畏因,众生畏果”。传统按结果导向进行管理的一个弊病,就是团队成员会把注意力放到结果上,而不是产生这样结果的原因——即过程改进之上。这样的后果就是,大家会把精力放到如何让报表好看,而不是真正地提高团队成员的持续改进能力来真正达到所期望的结果。企业管理层可以参考《丰田套路》[8]一书来带头实践Improvement Kata和Coaching Kata,让企业产生持续改进的文化。其中,Improvement Kata是通过一系列“确定目标—>考察现状—>识别困难—>制定方案—>观察成效”的PDCA反馈环来做持续改进;Coaching Kata是通过导师“一对一带学徒”的方式来让企业全员掌握持续改进的方法。

全局优化 而非 局部优化

由于大部分按职能组织团队的企业内部都存在部门割据的问题,导致大家都在做本职能部门内的局部优化,而没人做部门间的整体优化。有些部门间的扯皮时间甚至长达数月,严重影响了产品的交付。这提醒我们,全局优化来提高企业整体竞争力,才是各个部门赖以生存的保障。

单件流 高于 库存

单件流指的是,正在制作的产品的各个模块,能从最初的对其增加价值的加工步骤,直接传递到下一个增值加工步骤进行加工,并最终被传递到客户手中,在这个过程中,各个步骤之间没有发生等待或者排队的现象。而如果在各个步骤的传递过程中发生了等待或排队,那就等同于建立了库存。

软件开发中常见的库存包括排队等候开发的需求、排队等候测试的代码、排队等待修复的缺陷和排队等待上线的产品特性;隐藏很深的库存可能由诸如那些有固定期限(比如每月一次)的“用户验收测试”的流程造成——月初几天就开发测试完毕的产品特性必须要被存放近一个月,等到月底“用户验收测试”后才能继续往下游走。软件开发中的上述库存就是让项目延期的最大原因。而企业如果能做到单件流,那么就相当于消灭了库存,让价值在不同环节之间流动得最快,进而实现了前文所提到的全局优化。

4. 工具

自动化 高于 手工

按照固定流程所进行的手工工作,比如手工回归测试和手工部署工作,无趣、缓慢且无法审计。如果能将其代码化,且用版本控制系统管理起来,并加以自动化,这既能节省以后手工运行的大量时间,又能体验到开发测试和部署脚本工作的乐趣。

基础设施及代码 高于 手工配置

传统Ops的部署工作有些需要用鼠标在界面上点来点去,效率很低;效率高一些的Ops用了自动化脚本,但很多脚本都没有进行版本控制,更别提针对脚本的自动化测试了。 如果能够将基础设施的维护工作都通过编写代码并加以版本控制来完成,那么会带来很多好处,比如Ops可以不用通过访问生产环境,就能知道生产环境上的配置情况;非运维人员如Dev,就有机会去学习这些运维配置代码并且加以修改,提升整个团队的DevOps能力;另外工具能方便地读取这些代码,来自动化地维护基层设施,大幅度提升Ops的工作效率。

部署流水线 而非 每日构建

程序员每天都会用代码提交来为软件系统增加价值。而如何有效地保证每次提交的代码质量过关而不会有损现有系统的价值呢?这就需要一个代码构建系统自动地验证代码在编译、测试和打包等工作的过程中,是否符合质量要求。有些团队还在每晚做一次代码构建,这个昔日的“最佳”实践如今已经不再被推荐。一个团队程序员们每天代码的提交会有很多,如果晚上构建发现了错误,第二天从这些众多提交中发现谁导致的错误,将是一个很困难的事情。推荐的做法是每一次代码提交,都能自动触发部署流水线来检查该提交是否通过了自动化单元、验收和性能等测试。一旦发现问题,就能轻松定位是谁在哪个环节出现了什么问题。

总结

DevOps的原则来自从业者们在日常工作中运用敏捷、精益原则的具体实践。这些原则可以按照“人、产品、流程和工具”4个维度来组织。这些原则和实践的目的,都是要实现DevOps的愿景——让业务所要求的那些变化能随时上线可用。

下图是本文实例化DevOps原则的一个可视化总结。

感谢笔者在ThoughtWorks的同事Patrick B. Sarnacke、顾宇、马博文、黄博文、蔡同、万金、张凯峰、周文晔和亢江妹。他们在阅读了初稿后,给笔者提出了精彩的反馈,使得本文得以改进。

后记:

在本文所讨论的上下文中,原则(Principle)指的是主观的“影响行为的坚定信念”(a moral rule or a strong belief that influences your actions),而不是客观的”自然法则“(a general or scientific law that explains how sth works or why sth happens)。括号中的英文来自《牛津高阶英语词典》第8版对Principle一词的解释。所以本文所讨论的“原则(Principles)”和“价值观(Values, beliefs about what is right and wrong and what is important in life)”这两个概念在内涵上是一致的,都是主观的。

在本文发布前的ThoughtWorks内部审阅期间,笔者的同事顾宇就已经提出了同样的问题,“我看到‘高于’就想到敏捷宣言,敏捷宣言是个价值观,就是对价值的取舍。能否把本文改叫DevOps价值观?” 我当时查到了一篇文章《What is the difference between a value and a principle?》,得到的结论是“Principles是客观的,比如重力这样的自然法则;而Values是主观的”。于是就着手开始把文中的“原则(Principle)”改为“价值观(Value)”。但是改到一半时,发现人们也会说“精益的原则”(PRINCIPLES OF LEAN),而一般不说“精益的价值观”(The values of Lean)。于是再查《牛津高阶英语词典》,发现Principle这个词有上述主观和客观的两个含义。于是就决定使用Principle的主观的含义。

注:

[1] The (Short) History of DevOps, https://www.youtube.com/watch?v=o7-IuYS0iSE

[2] #DevOps的前世今生# 1. DevOps编年史, http://www.jianshu.com/p/f40209023006

[3] 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr, https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr, https://www.youtube.com/watch?v=LdOe18KhtT4

[4] Quantifying DevOps Capability: It’s Important To Keep CALMS, https://blog.rackspace.com/quantifying-devops-capability-its-important-to-keep-calms

[5] THE PROBLEM WITH DEFINING DEVOPS, https://www.upguard.com/blog/the-problem-with-defining-devops

[6] The Three Ways: The Principles Underpinning DevOps, http://itrevolution.com/the-three-ways-principles-underpinning-devops/

[7] 【冬吴相对论】144丰田之殇(下), http://blog.sina.com.cn/s/blog_7a25b1b00102ws84.html

[8] 丰田套路,https://read.douban.com/ebook/10138727/


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

Share

DevOps中文名: 开发自运维

谜面

在实践和推广 DevOps 的过程中, 当对着客户吐出 DevOps 这个词之后, 收获的往往不是大腿一拍热泪盈眶, 而是一脸困惑欲言又止想问又没问的场景. 在一番解释后, 到团队中落地的时候, 往往又单独拉几个人出来, 划了个圈说这是一个 DevOps Team. 这类做法背离 DevOps 的初衷. 背后的原因很多, 但一个浅显却影响深远的原因往往被忽略, 就是 DevOps 这个名字本身.

DevOps 目前并没有中文翻译, 对于中国人来讲, 即使直觉的望文生义也无法产生. 当几番了解知道是” Development” 和” Operations” 的拼接之后, 对应的中文是”开发运维”, 依然一头雾水不明所以. 而由于” 开发”和”运维”目前是常见的两种角色, 两个团队, 而 DevOps 需要新的技能和工具, 因此把 DevOps 作为一种新的角色, 成立一个新的团队, 就自然而然了.

开发自运维

语言的边界就是思想的边界. 一个精确表达概念的词汇将阻止误解的产生. TDD 也好, Pair Programming也好, 虽然实践本身争议不断, 但其含义却少有误解. DevOps 对于英语母语的人来说或许精确表达了它的意思, 但对于中国的开发团队来说, 带来的只有困惑.

开发自运维” 是我推荐的 DevOps 中文翻译. 它依然没有反映全部的含义, 甚至暗示着不再需要运维团队, 但它至少从字面上就阻止一件事: 成立专门的 DevOps 团队. 想想吧, 把几个人弄出来, 说你们是”开发自运维”团队, 这从语义上就说不通啊. “开发自运维”从字面上就意味着运维是开发团队内置的责任, 这也符合 DevOps 运动的初衷.

历史即未来

在高度不确定性的产品创新中, 对市场的响应速度越来越快, 开发自运维是一个趋势, 可以缩短交付时间和对反馈的修复时间. 这种趋势的前一波浪潮, 则是”开发自测试”/“开发自设计“, 而下一波运动则极有可能是”设计自开发”.

”开发自测试”已经接近成功而即将成为过去式, 可最初也曾经面对”开发”和”测试”天然是两个团队这种概念而阻力重重. 并没有一个像 DevTest 这样的运动来指导开发和测试的融合, 而是敏捷推行的”全功能团队”帮了忙. 而最终的结果是并不会取消测试这种活动, 甚至依然有专职的测试人员, 但相当一部分测试活动被”开发人员自测”涵盖了. 对照历史, 我们有理由相信, “开发自运维”并不会取消运维这种活动, 甚至依然会有专门的运维人员, 但相当一部分运维工作, 将被”开发自运维”涵盖.

“开发自设计”几乎从未引起过困惑和质疑. 事实上无论是 PC 时代还是 Mobile 时代, 大量软件都是个人能力的结晶. 这里面的制约因素是开发能力而非设计能力. 即使对企业应用开发, 架构师, 交互设计师等也都算作开发团队成员.

而”设计自开发”则已初露端倪. “心声”是一款帮助听障患者与他人沟通的 iOS App, 由 ThoughtWorks 设计师朱晨独自设计并开发. 随着对市场响应速度的追求, 对不确定性快速验证的追求, 设计师们发起了”Lean UX” 等工作方式, 而对开发工具的掌握, 将极大提高其产品设计和验证效率. 开发工具及平台朝着简单易用的方向发展, 也会助设计师们一臂之力.

Share