opsbet娱乐官网

没有不适合DevOps的企业只有不适合DevOps的人

来源:大发 | 时间:2018-08-31 人气:5912
  •   没有不适合DevOps的企业,只有不适合DevOps的人。企业都要盈利,没有一家企业会认为效率提升对它没有价值,所以都适合做DevOps,而且都应该做。

      徐磊,英捷创软LEANSOFT创始人兼首席架构师,专注于软件工程、DevOps方面解决方案咨询。有超过10年的软件研发项目管理经验,曾任SSW中国研发中心总经理。是资深ALM顾问和解决方案专家,微软最有价值专家和大中华区域社区技术总监,认证ScrumMaster和敏捷教练。

      StuQ工作坊:您拥有多年DevOps实战经验,曾担任京东商城、华为、中国农业银行、百威英博等多个项目的高级ALM/DevOps顾问。您怎么理解DevOps?在您看来, DevOps的核心竞争力是什么?

      IT行业非常擅长发明新名词,其实过去的10年中我一直都在做软件工程相关的工作,一路走来撞上了很多这样的名词:SDLC(软件开发生命周期),ALM(应用生命周期管理),敏捷,精益等等,到了2012年第一次听说DevOps。开始的时候也很迷惑,到后来发现这10多年都只做了一件事情,就是提高效率。DevOps不能帮你直接解决业务问题,它只能帮你更快更好的交付业务需求,这就是效率。

      这么多年,其实软件工程行业的关注点经历了一个从微观到宏观,再回归微观的过程。比如一开始的SDLC就是一个关注软件开发过程本身的方法论,后来发现这不够,只关注开发本身解决不了问题,就开始向更大的范围延展,也就是出现了ALM。其实ALM和DevOps所关注的问题领域很接近,只是前者更关注管理,而后者又开始向技术回归,更加关注具体的实践和落地的方案。而敏捷和精益在整个过程中则起到了价值观引导和方向性指导的作用。

      说的更直白一点,软件工程行业做的就是效率的工作,我们虽然不能帮你写代码,做测试,但是我们会让你写的代码体现出更多的价值,让你的交付过程更加顺畅,让管理人员更有信心,让技术人员在单位时间创造更多价值。

      徐磊:案例很多,都可以和DevOps扯上关系,DevOps其实就是一顶帽子,只要你做的是软件工程领域改进效率的工作其实都可以说自己在做DevOps。所以,不应该说DevOps这顶帽子给开发团队带来那些改变,而是DevOps下面的实践给开发团队带来哪些改变。

      我做的案例中金融行业比较多,比如:农行,兴业银行,博时基金等等。这个行业有一个普遍的特点,就是监管很严,造成的结果就是企业内部流程繁琐,审批多,部门墙很严重。我个人比较看重的改变其实是团队士气上的改变,比如之前给其中一家引入了用户故事地图和影响地图实践,协助他们完成了需求梳理过程。参与的成员普遍的反应是业务人员和技术人员可以开始对话了,而且效率很高,以往可能需要几个月才能完成的需求梳理和设计,这次仅仅用了2周时间,项目就可以启动了。而这种对话所带来的默契在后续的开发过程中让沟通更加顺畅。另外一家,我为他们的iOS开发项目定制了一套在TFS上面的集中自动化构建系统,这个事情让他们的开发人员不再需要每个月抱着电脑到构建管理员那里拷贝代码才能发布版本。这里解决的其实是AppStore证书的问题,因为企业证书是不能拷贝给开发人员的,而发布正式版本又需要这个证书,所以以前是靠人来管理,现在可以靠自动化系统。这个事情其实做的就是持续集成,但是解决的却是流程问题。

      StuQ工作坊:您觉得哪一类企业适合DevOps?如何评估一个企业适不适合,以及什么时候适合实施DevOps?

      徐磊:我觉得没有不适合DevOps的企业,只有不适合DevOps的人。企业都要盈利,没有一家企业会认为效率提升对它没有价值,所以都适合做DevOps,而且都应该做。但是具体到人的个体,就不一定了。这里还是个案例,我的一家银行客户,一直希望能够做到全生命周期的软件工程管理,就是用需求把整个过程串起来,一直不能落实。2016整个行里把互联网金融作为战略级决策,由副行长出面协调组织了一个跨部门跨职能的虚拟团队来做这个事情,这个项目里终于做到了全生命周期管理。我在这里不想探讨为什么要做全生命周期管理,我只想说为什么之前的10年都做不到,这次做到了。我参与了这个项目整个过程,我觉得最大的区别就是这个组织架构的调整。以前的人员都属于各个部门,各自的KPI都是对部门的,没有人会觉得全生命周期管理对自己有任何的好处,因为自己做的都是其中一段,做多了也没有人会说你好。这次采用这种虚拟团队的组织架构,让这些人的思想一下子从做好自己这一段转变成了做好这个项目。这个事情就成了,就是这么简单。

      DevOps从来都不能把它当成一个项目来说,虽然时机很重要(比如上面这个案例),但是DevOps的实践可以随时开始。没有前期的铺垫和探索,上面这家银行业也不可能在这个项目中顺利实施DevOps实践。所以我们要做的是:持续改进,时刻准备着。

      StuQ工作坊:很多企业都有“想实施DevOps又不知道从何入手”的困境,您认为在实施 DevOps过程中需要注意什么问题?有哪些关键点设计?

      其实以上的案例已经印证了这3点,没有企业领导者对DevOps价值的认知,下面的人再怎么努力也没有用,企业的方向性战略还是靠几个人的思路决定的,没有他们脑子里面的转变,下面人做再多也是跑偏。这部分的改变需要敏捷和精益思想的导入。但无论领导们如何认知这个问题,软件研发的效率问题都是客观存在的,所以务实的各种实践都还是要做的。这部分的实践要靠Scrum,Kanban,持续集成,持续交付等等方法和实践的支撑。而企业需要的只是一个时机,所有的努力都会被聚集在一个点上爆发。上下的思路碰撞会带给企业量变到质变的机会。而贯穿这整个过程的是软件工程系统和工具的落地,系统和工具中所承载的是企业的制度和流程,这些是保证企业在铁打营盘流水兵的现实下确保持久发展的核心竞争力的基础。

      StuQ工作坊:您是怎样一步步成为DevOps大牛的?这个过程中有过什么瓶颈么?又是怎么克服的?

      徐磊:一个事情做的够久了,自然有些心得。我常和客户说的一句话就是:我不比你们高明多少,但是我掉的坑肯定比你们多,从坑里爬出来的次数多了,就知道哪些坑能爬得出来,哪些坑爬不出来。别把人往坑里面带,这就够了。

      瓶颈还是有的,放在5年前其实没有什么人关心软件工程,DevOps也远远没有今天那么火,很多人甚至都不觉得这是个正经行业,就连应聘来的人都要解释半天我们是做什么的。所以有一段时间这个事情其实做起来很苦逼,也一度想转行做其他的。这应该算是瓶颈吧,估计很多做这个行业的人在中间都撤了,最后坚持下来的就算是大牛了吧。

      徐磊:DevOps的现状用方兴未艾来形容是最形象不过的,2008年这个词出现到2012年被行业认可,到2013年docker出现再一次推波助澜。现在的状况是从管理方法论和工程方案上都已经很完整,但是企业中的实施成功案例还比较少,特别是传统IT企业。现况是,新兴行业(互联网企业)凭借着轻装上阵,无历史包袱和相对简单的业务模型,天生就具备DevOps的优势,而且他们作出了很多非常漂亮的实践,分享到社区;但是传统企业IT的复杂度其实比新兴行业要高的多,这些实践确实具备借鉴意义,但是如何真正引入到传统企业的IT并产生价值这就是最近几年的主要趋势了。

      作为IT行业从业者,其实很容易被满天飞的各种公众号文章,博客,宣传所误导;好像互联网的玩法才是好的。其实我们真的要认清形势,互联网在整个IT业里面的体量恐怕连10%都不到,绝大多数软件开发从业人员是在为各种企业的IT部门工作的,真正解决他们的痛点才是DevOps应该关注的问题。

      徐磊:DevOps的范畴很大,从工具角度来说可以分成这样几类,这些工具都是我在工作中常用的,所以不全,只是我比较了解的。

      这类工具的重点是在企业研发中形成端到端的管理能力,建立整个研发流水线(这里的流水线包括需求,开发,测试,交付整个过程,不仅仅是自动化流水线)。

      微软Visual Studio Team Service / Team Foundation Server 平台:这是微软支撑自己产品研发和为企业提供的研发管理平台,提供了包括需求管理,项目管理,配置管理,测试管理,自动化构建/发布和数据分析的完整研发管理平台,也是我最熟悉的平台。

      Atlassian的系列产品,包括:Jira(需求,项目,过程管理),BitBucket(代码和配置管理),Confluence(知识库和文档管理),Bamboo(自动化/持续集成和发布)。Atlassian是一家专注于软件工程管理平台多年的公司,产品线随着这么多年的发展也日趋完善和完整。我的客户中有很多在使用这个平台。

      这类工具主要解决DevOps中的自动化过程的管理和执行。自动化工具一般都是提供一个引擎+各种插件。

      Jenkins:这应该算是最常见也是最受欢迎的自动化引擎了,引擎简单可靠,可扩展性好,具备大量好用的插件,社区支持完善。

      TeamCity:非常好用的企业级自动化平台,是老牌软件工具厂商JetBrians旗下的自动化引擎。我曾经非常喜欢TeamCity对单元测试的支持,因为它是第一个做到将测试信息聚合显示并做时间线跟踪的工具。

      这类工具一般被独立使用或者集成在以上的自动化引擎中,为团队提供持续的代码质量度量信息,帮助团队持续得到反馈。这类工具又可以可以分成静态检查工具和运行时检查工具。

      Coverity:特别擅长 C/C++/C#等语言的静态代码检查工具,当然对其他主流语言也有很好的支持,内置的代码相似度检查非常有用。主打安全性检查。

      Parasoft dottest:主流语言支持都很棒,包括:包括代码覆盖率和单元测试支持等运行时检查工具。

      NET Compiler Platform (Roslyn):内置于.net编译器中的动态代码分析引擎,可以在编程的同时对代码进行动态分析并给出建议。而且此工具也是开源的

      单元测试框架:Junit, Nunit, Google Test,Xunit,Mocha,Jasmine等。这类工具其实是编程框架,是开发人员用来快速创建单元测试代码的基础。

      自动化功能测试:Selenium和类似的Appium等工具。这类工具从GUI界面入手,模拟用户的行为并通过验证界面元素的状态来完成测试。

      性能测试:Jmeter,LoadRunner,VisualStudio Load Test等。这类工具一般通过对后端服务的api模拟用户行为,并配合一定pattern的压力模拟来完成对应用性能的测试。

      其实这是两类解决不同层面问题的工具,一个是解决基础设施编排的,一类是解决应用编排的,但是从DevOps的角度来说,它们都一样,因为我真正需要的是应用,而不是基础设施。

      Docker:这个不用解释了,DevOps的兴起其实很大程度上是被Docker的热度带起来的。最近Docker发布了LinuxKit工具,其实已定程度上进入基础设施编排领域了,再加上DockerSwarm的成熟,其实已经是一个从集群管理,操作系统和应用的全面解决方案了。

      Kubernetes(k8s),ApacheMesos(dc/os)和Service Fabric:这几个加上Docker Swarm就构成了最近几年非常火热的编排平台阵营。从云平台的兴起到应用编排平台的火热,其实代表了IT界回归应用本身的过程。这些平台给企业带来了集群环境的统一化管理方案,对现代应用运维有非常巨大的推动作用,是每一个IT从业者都应该了解和熟悉的工具。

      Chef/Puppet/PowerShell DSC:这些工具应该说和Docker解决了同样的问题,但是采用了不同的思路。类似的工具在2010年左右开始出现,极大的推动了DevOps实践中“环境获取能力”的提升,可以说是DevOps领域中第一批非常有价值的工具。

      这类工具无需解释了,云平台是过去几年火热的话题。但是今天各大公有/私有云都已经成熟的环境下,企业怎样最大化云平台的价值才是重点。

      最后想说的是,这里工具繁多,但没有任何一个工具可以说自己是DevOps的工具,就算是全生命周期管理平台也无法涵盖企业和团队的所有DevOps诉求。所以DevOps的工具选型永远是要搭建最适合自己的工具链,而这些工具的开放性就是最应该关心的问题。

      StuQ工作坊:我看到您是一位活跃的分享者,在InfoQ上发表过多篇备受欢迎的文章,6月份也将和StuQ合作推出经典课程《DevOps实战》,您通过这门课程想解决学员面临的哪些问题?这个课程的与众不同之处在哪里?

      徐磊:很高兴我的分享能够被很多社区的朋友认可。这次和StuQ合作推出的《DevOps实战》是延续了之前已经运作多年的《LEANSOFT领航员》课程,这个课程从2008年开始运作到现在已经积累了非常丰富和成熟的内容,而且我们一直坚持理论+案例+实践的方式来进行授课。

      如果说与众不同之处就是我们会提供真实的环境给学员,学员需要直接动手操作,实际体验DevOps实践的落地效果。这种授课方式对我们的老师来说是非常大的挑战,普通的培训课程有PPT就行了,但是我们会提供全套在线的环境,代码和操作手册;老师不仅仅要会讲,还要会操作,现场解决学员的问题甚至直接debug代码,对授课的老师有极高的实战要求。

      所以,我们其实是把每期培训都当成一个真实项目来对待的。可以说我们的课堂就是一个真实的研发中心,学员获得的不仅仅有理论和实践分享,还可以通过动手实验建立起对DevOps的感性认识,加强后续实施DevOps的信心。

相关opsbet娱乐官网信息

    无相关信息
Baidu