专栏首页ThoughtWorksDevOps实践——打造自服务持续交付(上)|洞见

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团队和交付团队的触点,又怎样让遗留系统团队和微服务团队的交付速度成倍增加。敬请期待!


本文分享自微信公众号 - 思特沃克(ThoughtWorks),作者:钟健鑫

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-08-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 变中求生—频繁变化的团队如何打造团队文化 | TW洞见

    今日洞见 文章作者/图片来自ThoughtWorks:师洁&范文博。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒...

    ThoughtWorks
  • 从领导力的角度谈ThoughtWorks的团队间协作

    最近在看一本书——《Team of Teams: New Rules of Engagement for a Complex World 》。作者之一是2003...

    ThoughtWorks
  • DevOps团队之殇|洞见

    “你在团队里是做什么的?” “DevOps。” “DevOps是什么呢?” “DevOps是一种文化、一种实践,目标是加快软件迭代速度,让团队更快交付价值...

    ThoughtWorks
  • DevOps实践-VMware的DevOps转型之旅

    如今,大多数公司都在进行DevOps转型,以采用更快的发布,提供更好的质量,提高团队的灵活性,敏捷性并获得更快的反馈。VMware的移动产品也不例外。我们两年前...

    泽阳
  • 手机淘宝:多团队开发一个产品如何保持敏捷

    Scrum等敏捷开发框架,最初都是为5到9人的小团队设计的。通过保持专注和合理利用新技术,在相当长的时间里小团队仍然可以支撑业务发展。

    DevOps时代
  • 给大型机插上翅膀,IBM Z/os 研发团队 DevOps 转型实践

    但见新人笑,哪闻旧人哭,杜甫的诗句很好的诠释了现在 IT 和互联网行业对待技术的态度,区块链、AI、大数据、AR/VR 等新技术层出不穷,每个人都在追逐 The...

    CODING研发管理系统
  • 2018年 DevOps 最新现状研究报告解读

    2018年度的 DevOps 最新研究现状姗姗来迟,但最终还是来了,让我们来看一下这份报告今年会给我们带来那些启示。

    DevOps时代
  • ​DevOps VS 职责分离

    在国内不少的研发组织依然通过职责分离的方式来管理研发团队,这种情况下就会造成团队之间合作效率低下、责任互相推诿等问题。我们翻译了以下这篇文章来与读者们一起探讨 ...

    CODING研发管理系统
  • 《Java从入门到放弃》JavaSE入门篇:面向对象概念(入门版)

    要知道什么是面向对象,你首先要有个对象吧,所以······没有对象的可以回家洗洗睡了·好吧,前面是开玩笑,要说明什么是面向对象,我们还是先

    墨鬓
  • DevOps团队之殇|洞见

    “你在团队里是做什么的?” “DevOps。” “DevOps是什么呢?” “DevOps是一种文化、一种实践,目标是加快软件迭代速度,让团队更快交付价值...

    ThoughtWorks

扫码关注云+社区

领取腾讯云代金券