美文网首页
切忌一步到位,谈谈DevOps实施落地

切忌一步到位,谈谈DevOps实施落地

作者: 博云BoCloud | 来源:发表于2020-07-07 09:55 被阅读0次

    2020年6月19日,由云计算开源产业联盟指导,高效运维社区和 DevOps 时代社区联合举办的GNSEC 2020线上峰会圆满举办。BoCloud博云参加了本次峰会并分享了博云帮助客户实施DevOps的真实案例,以及博云内部推行DevOps落地的实践经验。

    01

    DevOps范围、愿景和目标

    过去我们谈到DevOps的时候有很多不同的认知。早先说DevOps可以是CICD,持续交付,后来有人把敏捷开发管理放进来,之后有客户跟我们聊DevOps是指运维SRE。得利于中国信息通信研究院主导的研发运营一体化的标准,终于把DevOps包含哪些内容给说清楚了,如下图所示:

    DevOps标准中主要包含5大块内容:研发运营一体化、应用设计、安全积极风险管理、组织架构、系统工具。核心的模块在第一部分“研发运营一体化过程”里,而且标准中把最佳实践是什么样、不同等级实践对应有哪些具体细节都说的很清楚。

    基于如上这个框架,实际上可以看到DevOps的目标是很多的,涉及开发、测试、运维三个模块。

    因为目标很多,所以DevOps到底要怎样落地?是不是照着蓝图做就能很好的实现DevOps落地?因为有蓝图有最佳实践、有标准,按理说DevOps落地应该是非常轻松的。我们回答也很明确:不是这样的。这里我举2个例子,管中窥豹的看看DevOps实践过程中的一些弯路。

    02

    照着蓝图做,是否就能轻松DevOps落地?

    第一个是大型央企DevOps推广案例:内部云团队想规划建设PaaS平台,包括DevOps平台,因为PaaS包含DevOps,所以云团队想将PaaS平台中的DevOps能力推到研发部门。

    整体建设范围是敏捷开发管理、持续交付管理、运营一体化,这个事情花了很多精力,也做了很多内部团队的沟通,整体来讲在业务团队推广效果不是特别好,后来就逐渐搁置了。这个事情不是说做失败了,至少效果没有显现出来。总结来说的话:DevOps平台应该是谁使用谁建设可能在起步阶段会更容易一些。

    第二个是我们某个中型金融机构案例。这个案例建设目标起的比较高,并找了咨询公司做了咨询。咨询公司做的东西确实比较好,比较完整也比较细致。整个的建设目标包括开发管理、持续集成、测试部署、持续监控的,规划的很完整。

    到了落地阶段,这个项目整个落地周期10个月,上线7套系统。整个落地模块包含项目协同,流水线制品库等等,落地了项目协同、CICD流水线、度量仪表盘、管理驾驶舱。客观说实际推广效果还是可以的,尤其开发团队感受还可以。但是整个项目后来总结时运维团队提出了很多意见,说前期运维团队也参与了,领导也提了目标要求,但最后做了10个月,运维团队没有感受到这个平台带来价值。

    这个实际应该算是比较成功DevOps项目,但是后来评估的时候运维团队却提出了明确的负面意见,影响了项目评价。总结来说:项目前面调起的太高,范围过大,各个团队落地的期望比较高,但是实际上落地的时候可能有些团队没有得到想要的效果,效果评价受到了影响。DevOps落地初始目标设计,要更合理一些。

    如上两个小案例,以点带面说明下DevOps落地的典型问题。

    基于前面的案例,我想回答一下为什么DevOps蓝图很难一步到位。第一是因为组织架构, DevOps项目希望同时在开发部门、测试部门和运维部门都得到很好效果很难,最好分步来做,先解决单部门问题是比较合理。

    第二个DevOps自动部署的工具仅仅是一部分,其实还涉及DevOps文化和共同认识的建立过程,这需要一个较长的过程。DevOps整体蓝图要解决的问题,涉及的底层工具非常多,很难短时间在没有很好的基础前提下快速落地,良好的DevOps落地需要一系列标准规范的推广落地。但一般来说,因为历史包袱原因,标准规范的推广需要一个逐步甩包袱的过程。这些规范非常需要,但是因为历史包袱问题推广是很麻烦,遇到业务部门业务需求是很大的,所以说标准规范推广是比较难,但必须要做,但是推广需要过程。整体来说,这几个原因是DevOps有了蓝图和最佳实践还是很难一步到位原因。

    03

    DevOps落地实施路径建议

    DevOps具体实施有哪些好的实施路径,我们也想尝试回答一下。理论上从DevOps每个领域都可以发起DevOps,然后去落地,而且根据不同公司情况、业务基础设施情况,实施路径可能不同。根据我们的落地案例,我们尝试性的找几个比较通用合适的实施路径,举几个例子跟大家分享一下。

    第一个国内某股份制银行,他的推广路径首先是在研发过程管理中,敏捷开发管理、配置流水线、度量;然后在运维视角发布自动化、变更管理自动化;后来紧随着整个前期的研发推广,同时在底层专业平台、专业数据库管理中建立容器化。

    从开发测试角度:他们的流水线已经大规模应用,所有开发团队在开发第一步就可以把流水线建立好,开发人员只基于流水线就可以做整个CI和CD上线,是非常有价值的事情。另外,敏捷开发管理也已经落地到了整个研发流程管控里(这个行业经验很多,但是对开发测试来说,也是最重要的)。

    从底层能力方面:容器化大规模应用,对于CICD非常有帮助的。

    目前呢,他们正在推进DevOps能力整合优化,实现更大价值。这个案例应该说是非常好的DevOps实践路径。尤其是已经大规模推广起来了,是非常厉害的。

    第二个是安信证劵。第一步做了敏捷开发和自动化测试和度量,主要在开发侧;在运维视角做了容器化,也已落地。然后安信证券比较好的一点是除了推广和落地,在于很好选择了试点团队。

    试点团队选择了技术能力比较强,希望能够快速发布,根据这几个点选了几个团队进行试点,进行项目实践,整个试点达到比较好的效果。第一,已通过DevOps三级认证。第二,流水线真正标准化落地,度量指标及指标指导下研发改进效果明显。第三,目前已经启动了大规模推广。是DevOps比较好的落地,并能够达到设计效果的一个项目。

    第三个是我们自己博云。其实我们做DevOps时间挺长,我们内部2018年开始推行DevOps,当时也是通过工具链来做。后来我们做了自己的DevOps平台,目前已经全部切换到自己的平台来用了。推广路径如上图,自研DevOps平台推广周期相对比较短,基本上4个月就全部切换过来了,主要是因为内部在工具链使用方面已经有比较多的经验。

    我们是软件公司,没有所谓线上发布这个过程,所以说DevOps落地更多集中在研发测试环节。我们的需求本身是比较明显,有两个核心需求,第一个实现快速迭代发布,第二个实现能够更好去把研发进度效率实现自动化,把度量的事情搞定。路径上来说,我们首先DevOps团队自己先去试点推广,DevOps产品现在整体来说1个月一次正式的版本发布,进度质量效率数字化,实时可见。第二个通过公司管理层的直接推进快速扩展到全公司研发团队。

    实施路径选择建议

    尝试性的总结下DevOps实施路径选择原则。

    第一个要制定合理目标。核心原因是每个团队最为关注目标是不太一样的,像刚刚讲到我们作为做软件的公司,更多偏向于快速迭代发布和度量这两块的内容,但作为一个线上系统可能更重要是别的一些指标,所以说基于自己现状从核心痛点出发,制定合理项目目标比较重要,同时在运维发布和CICD流水线都有需求。

    第二个是管理好内外部期望。其实我们一开始要提出自己的目标,一个方面要有很好价值,另外也不要好高骛远,不要把期望搞的很高,推广是没有那么容易,要有合理期望值,包括领导,期望太大容易失望,失望了之后推广就失败了。

    第三个是系统设计取决于组织架构。最好不要一上来做组织架构的事情,这个肯定可以做,但是比较麻烦。在DevOps实践里面组织内部做的事情很多,可以从本身组织开始,然后逐步实现整合跨部门,这个很合理。除了平台之外还有人的文化认知,所以分步实施、逐步演进,也不需要规划一步到位,一个月就把DevOps做到位,这个其实不太现实。一步到位非常难,而且效果不好。那么试点团队是先试点,配合比较好、意愿比较强再去推广,这个是几乎所有DevOps做得比较成功企业的工程实践。

    另外一个周期上要有持续的推进机制,可能刚开始大家推进挺好,那么过了半年推广是不是忘了,必须要有持续的推进机制,要有打持久战的准备,逐步把DevOps这事落地优化到最好。

    最后一个是:规范。越规范越有用,规范价值是非常大的。在可能情况下可以先推行规范,有了规范,很多事情会变得非常容易,而且对于使用者,落地之后的使用体验也会很好。所以规范越早推越好。

    整体上这个就是DevOps落地实施路径的规划原则,大家可以作为参考。 

    相关文章

      网友评论

          本文标题:切忌一步到位,谈谈DevOps实施落地

          本文链接:https://www.haomeiwen.com/subject/aiesxktx.html