实战Practice丨拉动DevOps持续交付的三匹马 —— 快速交付实践总结与思考
2018-11-14
来源：金融电子化
本文节选自《金融电子化》2018年3月刊
作者：中国银行软件中心 付大亮
编 者 按
本文以转型过程中各种实践为基础，结合笔者思考，探讨工艺、工具和技术如何相互配合支撑DevOps持续交付。
背景：中国银行软件中心先后通过ISO9001、CMMI3、CMMI4、ISO27001认证，形成了完整的管理体系，为交付高质量的软件奠定坚实基础。软件中心项目采用瀑布开发模式，按批次投产、批次时间点在每年批次计划中确定。随着互联网金融、利率市场化等环境变化，软件中心引入敏捷，经过两年多努力，全流程试点项目交付速度提高5倍。敏捷试点成功的同时，也遇到进一步提升的困境。
问题：交付周期难以进一步压缩；适用敏捷项目实施方式的产品范围有限，很多传统银行IT系统难以敏捷；随着敏捷后版本数量增加，维护人员压力激增；一些项目采用敏捷，裁剪了很多瀑布模式下的控制点，产品质量风险升高。
实战经验：为进一步提升交付能力，软件中心引入DevOps。
车夫：组织方针、目标
车夫就是组织管理方针、目标，负责统一思想，引领方向，形成企业文化。管理方针为工艺、工具和技术的筛选、引入、整合和优化指明了方向。工艺、工具和技术这三匹马向上支撑组织方针、目标，实现优质高效；向下沉淀企业文化，凝聚员工力量。对于社会各行业，响应总理所号召“大众创新、万众创业”；对于具体一个组织或角色需践行“工匠精神”，立足本职，精益求精，这是创新的辩证统一。DevOps是一种管理和IT技术相结合的创新，在不同组织之间、在一个组织内外有着不同的视角和侧重点，也有着相同之处。不同组织因目标、方针和所处环境的不同， DevOps实践侧重点、开展方式也不完全一样；同一个组织，因角色分工不同，DevOps实践侧重点、开展方式也不完全一样。但DevOps是在IT领域改进；都是为了支持业务发展，提高IT部门交付能力； DevOps的指导思想、改进方法和专业领域又有很多相同之处可以借鉴。这些相同点和不同点都需要在组织方针、目标指导下，有目的、有机会的改进，才能为支持组织目标达成。
第一匹马：开发工艺、管理流程
三匹马中的第一匹马是工艺流程。大型项目开发过程是一个高度协作的过程，必然有流程规范。工艺流程是拉动快速交付的第一匹马。这匹马解决了复杂任务分解的问题，解决了人员协作、职责分工的问题，给出了完成任务的工作路径、交付方式和验收标准。在敏捷引入初期，笔者认为CMMI、ISO太重，应该逐渐被敏捷替换。但经过两年多敏捷转型实践，逐步意识到敏捷宣言和CMMI、ISO并不冲突，敏捷宣言指导开发团队应对需求快速变化，CMMI、ISO指导组织构建开发团队运行环境、构建开发工艺流程以及构建质量保证体系。两者结合才能为组织创造最大价值。敏捷转型初期，我们将敏捷试点项目放在独立于组织规范要求的理想环境中，加速敏捷引入。中期，我们将敏捷思想融于组织管理流程，将敏捷思想在更大范围内应用，以此来优化工艺流程，同时让阻碍交付速度进一步提升的因素更为突出，为下一步优化提供输入。后期，工艺流程设计从批量交付向单一功能快速交付转变，即精益思想中的单件流，每次交付都给用户提供一个完整、可用的功能。工艺流程的优化在一定阶段能够提升交付效率和质量，当规范、要求增加到一定数量时，由于规范、要求本身复杂性增加，落地执行就会变得困难，效率和质量也不会明显提升，甚至因为规则过于繁琐而导致执行不完全到位的情况出现。为避免这种情况，需要技术架构解耦；用工具承载流程、规范要求，进一步提高团队执行力和执行效率。
第二匹马：DevOps工具
第二匹马是工具，它与第一匹马互为表里。在软件开发过程中，软件发布作业流上的工作可以分为三类：第一类是为交付物增加价值的工作；第二类是支持保障性工作；第三类是浪费，如频繁交接、内耗、返工等。第二匹马通过工具和自动化技术提高这三类工作的效率和执行精确度，把员工从繁重的机械劳动中解脱出来，执行创造性、开拓性的工作。如软件开发中，编写代码是增加价值的第一类工作；检查规范落实情况，集成组件、部署、验证属于第二类工作；BUG修复、反复协调属于第三类工作。引入eclipse等IDE开发工具可有效提高第一类工作效率；引入持续集成、自动部署、自动化测试等工具接替手工操作以提高第二类工作效率。第三类工作有技术因素和非技术因素：技术因素可以通过改进工艺和工具来解决；非技术因素需通过企业文化、工艺改进、工具提升综合处理。
软件中心集成了Jenkins、Checkmarx、Findbugs、robot framework、maven等工具实现DevOps发布流水线及相关质量检查，在提高速度的同时，控制质量风险。如图1所示，工具通过调度连接实现自动化，通过汇总运行数据，实现数字化、可视化，构建多重反馈环。工具执行速度往往是人工的几十倍、上百倍，这里主要说明三点。
图1 DevOps开发侧承载持续发布的环境拓扑图
一是工具不仅适合承担重复性工作、传输记录性工作，还适合做检测类工作。可以把管理规定中明确的部分通过工具去执行和落实。以此来提高效率，降低人力成本。长远来说还能不断促进团队提升执行力。
二是软件开发的工具要成体系，集成到一个作业流中——DevOps中叫“发布流水线”，像管道一样，有一个入口、一个唯一正确出口和若干异常出口。“正确出口”指所有检查都通过后发布流水线结束的位置；“异常出口”指未通过检查导致发布流水线终止的位置。发布流水线以“标准化、工具化”为基础，利用自动化方法整合零散的工具，降低工具使用难度、提高效率、严格落实既定工艺流程。“标准化、工具化、自动化、数字化、可视化”就是软件中心DevOps建设的指导思想。
三是因专业分工、信息安全等因素，工具一般是在不同时期，由不同的人员引入。与交付相关的工具，需要具备集成到发布流水线的能力。不能集成到发布流水线的工具会增加使用成本，降低交付速度。
第三匹马：架构技术
引入敏捷、持续集成、DevOps等在互联网公司兴起并取得成效的工程方法，有时还达不到互联网公司的发布速度。原因有多方面，如银行老中青多代技术标准并存，难以自动化；产品产生于C/S架构时代，产品/模块间耦合大，难以独立发布；银行业安全合规要求高……为了支持快速交付，需要向分布式、微服务迁移，还需要灰度升级、自动故障隔离等IT基础架构能力控制快速交付带来的风险。这就是第三匹马——软件开发、运维、质量检测相关的技术。技术是硬实力，是工艺流程设计、工具引入、整合的基础。笔者所在IT部门主要支持传统银行参与互联网金融竞争，这里技术指能够支撑优质、快速交付软件功能的相关技术。这些技术允许大的需求拆成小的“故事”（敏捷术语，一种软件需求形式），实现快速交付；降低自动化检查、自动化验证、自动化部署落地难度。技术栈的特性和工具集差不多，一般有1+1>2的效果。如云技术就是上接用户场景，下接硬件设备、成体系的技术集合，无论是影响力还是实际效果都受到广泛认同。整合后的技术体系为开发团队提供全套服务，而不要开发团队详细了解细节，使开发团队可以专注于业务需求交付。近年软件中心主要研究X86平台上分布式相关技术，整合Dubbo、spring、mybatis、zookeeper等形成“E中银”技术体系，如图2所示。相关研究成果获得了2015年银监会二类课题。
图2 E中银架构示意图
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
