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

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

DevOps范围、愿景和目标

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

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

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

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

照着蓝图做，是否就能轻松DevOps落地？

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

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

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

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

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

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

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

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

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实施落地

最新文章

热门文章