e-works数字化企业网  »  文章频道  »  基础信息化  »  运维管理

DevOps实施落地的2大法宝:粒度&解耦

2017/10/9    来源:运维派    作者:佚名      
关键字:DevOps  软件开发  
一句话概括我所做的事情就是:帮助研发团队改进研发流程,包括使用工具、使用方法、借鉴他人经验等方式,让大家的软件开发效率变得更高。
    一句话概括我所做的事情就是:帮助研发团队改进研发流程,包括使用工具、使用方法、借鉴他人经验等方式,让大家的软件开发效率变得更高。
 
    我的DevOps之路
 
    DevOps这个词从一出现就受到很多关注,尤其是近一两年来变得非常热,以致大家对DevOps有很多的误解,这种热度确实有一定的炒作的成分,但个人觉得任何事情的出现和流行都有其内在的原因,DevOps也不例外。
 
    本篇简单总结过去十年我所做的相关的事情,通过我的经历来看过去十年DevOps在国内的发展历程。希望这个过程可以帮助大家了解:DevOps到底是什么、是做什么的、能帮到我们什么。由于是结合我个人经验来谈DevOps,所以很多说法会带有个人的主观判断,分享给大家,旨在一起探讨。
 
    DevOps
 
    第一个时间点:2005年
 
    之所以把第一个时间点放在2005年,是因为这一年我从澳洲回到北京,组建了一家外企研发中心。在这之前我就是一个纯粹的开发人员,写code、做项目、做产品、做发布,从2005年起我的角色开始转变,开始要去带一个团队,并从团队的角度考虑问题。
 
    当我在国内找到了几名开发人员和我一起做一些项目的时候,我发现了第一个问题:当时我们的源代码管理服务器处于澳大利亚悉尼,在北京如果想要把代码提交过去非常痛苦。这种痛苦到什么程度呢?我们切入一个文件大概需要十分钟的时间,这是非常让人无法容忍的事情,会严重造成工作效率的低下。
 
    我们找各种办法希望能解决这个问题,包括提高网络连接,但遗憾的是没有找到更好的办法。老板和微软的关系特别好,他看到了微软一个还没有发布的产品——TFS(当时还处于beta版本),我们注意到这个产品是因为它的source control是基于HTTP的,所以我们决定把现在基于VSS的source control迁移到基于HTTP的TFS的source control上。从2005年开始大概持续了两年的时间,我把公司所有的项目从VSS迁移到了HTTP。
 
    其实VSS也是一个很不错的source control,但当出现这种跨地域访问的时候它的性能就会有很大的问题。这是我接触专业的软件工程工具或开始去想如何提高团队效率的一个起点。
 
    第二个时间点:2008年
 
    第二个关键时间节点是2008年,当时我和微软组织了一个叫VSTS Real World的活动,这场活动实际上就是:我们找到了很多国内有影响力的独立软件开发商,把其中比较资深的软件开发人员集中到一起,让他们去体验如何在一个完整的软件工程管理平台上,完成一个软件从需求到分析到开发到测试到打包到发布的过程。
 
    从微软的角度来说,是希望推广他们的工具;从我的角度来说,是第一次完整地把自己之前在软件交付整个端到端的流程方面的经验分享到自己团队之外去。
 
    活动开发的项目是以汶川地震这个背景为假设场景,要求开发一个叫“孤儿领养”的系统。
 
    这个项目对我个人来说非常重要,它是我作为软件工程顾问所完成的第一个完整的项目。虽然是一种培训的交付形式,但其实在制作这场活动的相应的资料时,我是把自己和团队的经验通过文档、PPT、示例代码的方式,整理成一整套的资料分享给其他开发团队,并且在这5天的时间内,和大家一起完成一个真实的项目开发。在这个过程中,我们也采用了一定程度上的敏捷开发的概念,比如迭代、用户故事等。
 
    第三个时间点:2008-2009年
 
    上图中有一个关键时间点,标注着DevOpsDays,DevOps这个词的出现大概是在2008-2009年这个时间段内,这期间开始有越来越多的人关注到底怎样提升软件研发的效率,DevOpsDays的活动是Patrick Debois 在这个时间点第一次帮助社区开始组织这样的活动时发起的。在那个时间我对DevOps完全没有任何理解,对于我来说,我的理解就是软件工程,就是帮助团队提高效率,把工具用好。
 
    第四个时间点:2008年-2012年
 
    在2008年-2012年这段时间里,我所带领的外企研发团队在业务上有一个非常大的转型:2008年以前基本上是对外做外包,为澳洲总部做软件外包;2008年以后开始接触一些国内的软件工程项目,以及研发平台解决方案的工具落地项目,(现在我们叫做DevOps咨询项目)。之所以从2008年开始转型,有非常重要的外因和内因,这也是我希望通过这个过程和大家分享的。
 
    从一个企业来说,为什么会转变自己的业务模式,为什么会改变自己的研发模式,其实很大程度上是因为有非常强的外因逼迫你不得不这样做,另外还有非常强的内因,让你自己也意识到“我可以这样做”或者说“我这样做会比以前做得更好”。
 
    从2008年起,我就开始在国内承接一些软件工程类似的项目,比如研发过程改进、效率提升。我们所接触的第一家比较大型的客户是京东商城。之所以重点提起这个客户,是因为对于我个人来说,这个客户让我对软件工程有比较深的了解。
 
    首先,京东为什么要做这个事情?我们在2012年开始和京东做这个项目的时候,京东整个研发团队的规模是大概1500人,在2013年项目结束我们离开京东这个团队的时候,它的研发规模基本翻了一倍。
 
    以此可以看到为什么它会在这个时间点去做这样一个项目,因为这时候如果还没有人通过专业的角度去帮助他们梳理研发流程、考虑在这么大的规模下怎么保持研发交付的效率,可能他们在业务上会受到非常大的挑战。
 
    当时我们做了什么呢?我们只做了一件事情:帮助它重新梳理软件需求上线的过程,并且通过一个工具把它相关的系统和信息收集起来,让他们的开发团队、项目经理、业务人员能很快做出决策,并且将一部分功能自动化。
 
    这里一个大的背景是:我相信现在很多互联网公司的需求上线可能仍然是采取这种模式——上线窗口,典型的是,当时京东的上线窗口是每周二和周四,它会在每周二上线一些大版本或一些比较大的改动。
 
    为什么选择在周二呢?周一刚进入公司可能还没进入状态,周二开始比较快速地工作,把精力放到工作上,这个时间点对于一个在线商城来说流量比较低,所以这时候上一些大版本是相对安全的;而另一个时间点——周四很容易理解,过了周五就是周末了,这个时间大家会考虑是不是要买点东西周末拿回家。
 
    在京东内部,他们在每个上线时间点之前都会开一个上线协调会,这个协调会上就会出现:一个团队说“我作为一个产品线,我想要去发布我的需求”,而另外一个产品线的团队会站起来说“你不能发,因为我还没有准备好”,这时候就会出现这种有意见分歧的问题,这样的问题只有到马上要到上线时间点的时候才会暴露出来,所以造成很多需求延迟,没办法按照希望的状态被发布出去。
 
    我们所做的系统是把这个信息尽早地收集起来,比如三周以后要上这样一个需求,在三周之前提到系统里,系统会链接到需求规划、测试、自动化打包、上线系统,这个过程中还会有一些审批的流程,把相关的一些关联方依赖方聚合起来,帮助判断这个需求是否能上。
 
    其实从现在DevOps或者敏捷的角度去看这件事情,会叫测试提前,或者运维规划提前等这种概念。在那个时候京东做的就是这么一件事情,它就是把风险尽量早地暴露出来,让团队能够有更多的时间去解决这些问题,这样的话,在真正需要上线的时候可以非常顺利地完成上线操作。
 
    通过这个项目我开始意识到:软件开发,几个人做的时候是比较简单的,当团队发展到一定规模的时候,做起来会越来越困难。这个困难的来源在于软件开发本身是件个人英雄主义的事情,它必须要依赖于每一个开发人员的智慧,去探索创造性地解决问题,这是造成所有软件项目管理问题的根源,也是其本质。对于软件开发来说,没有办法认清其本质就没有办法很好地去管理它,就没有办法让你的管理思路选择适应软件开发过程的思路而去管理这个过程,这样效率肯定上不去。
 
    第五个时间点:2016年
 
    到2016年,我以咨询顾问的身份参与到中国农业银行的互联网金融这个项目,去支撑和帮助他们解决在项目开发中遇到的一些问题。到现在为止,我的客户群体在向金融行业倾斜。
 
    过去10年间,中国大陆的微软DevOps工具相关的所有大型实施项目都与我有关,通过服务过的企业和十年的实践我总结出:现在最需要软件工程过程改进,或者说需要DevOps的团队定位是:严重依赖IT的非IT行业的团队。
 
    什么是严重依赖IT的非IT行业的团队?
 
    比如金融行业是一个非常典型的例子。首先任何一个金融企业如果没有IT的支撑,它是根本就转不起来的,但它自己本身的业务又是和IT完全不相关的。这就造成这些企业的客户以及这些企业真正的业务从业人员对于IT的理解有非常大的误差,IT人员想要在这些企业里发挥作用,就需要和完全不理解IT的人进行沟通,同时要能够对他们进行交付,导致两方面的沟通存在很大问题,IT人员还需要对业务进行了解,沟通成本的增加对软件交付效率造成非常大的影响。
 
    银行有非常典型的沟通问题,还有一些历史遗留问题,涉及到粒度和解耦,为什么说这两个是DevOps实施的两大法宝,这是我在给客户建议或帮助他们进行过程改进的时候所摸索出来的心得。本文将重点分享这两大法宝。
 
    DevOps实施落地的2大法宝
 
    DevOps
 
    不管是敏捷、精益、持续集成、持续交付或DevOps等概念,目的都是提高效率,即提高单位资源的产出。其关键原因在于,中国的经济发展迅速,很多企业已经度过了那个靠增加投资来增加产出的阶段,现在IT从业人员薪资在增长,所使用的各种工具和环境,包括市场都非常成熟,很难找到一种短时间内获得爆发性收益的方式,企业之间到了拼内在实力的阶段,在这个阶段效率非常重要。
 
    管理粒度。有两层含义:1动词,管理这个粒度,2名词,管理的粒度。在进行研发效率优化的时候,我们要关注的就是各种粒度,需求大小、团队大小、交付的代码量的多少,原则是越小越好。因为软件研发本身是一个复杂的过程,对于复杂过程的管理永远没办法适应其复杂度,最有效的方式是将复杂问题简单化,然后去管理简单问题。所以,从管理的角度如果想优化效率就要尽量减小管理单元。
 
    工程解耦。软件工程涉及两个领域:管理领域——怎么去管理过程和团队;工程领域——实现要实现的内容,从软件角度来说就是怎么编码,怎么把大家脑子里的东西变成可运行的应用和服务,这个过程就是工程领域。在工程领域上想提升效率要做的就是解耦,不停地解耦,让你的程序、服务、所有部分都可以相对独立地被开发、测试、部署、运行,这样整体效率才能提升上去。
 

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐