工行软件开发中心devops典型实践案例经验总结-2024德国欧洲杯官网

根据“熵增定律”，在一个孤立系统里，如果没有外力做功，总混乱度（熵）会不断增大。如今，软件越做越大、越做越复杂，但研发效能的绝对值却随着一些因素的增长有逐渐变差的趋势：一是软件架构本身的复杂度提升（微服务，服务网格等）；二是软件规模的不断增长（集群规模，数据规模等）；三是研发团队人员规模不断扩大引发沟通协作难度增加。在降本增效的大背景下，研发效能的提升已成为科技公司的核心竞争力。

一、转型之痛

银企团队作为工商银行软件开发中心首批试点devops团队，在实施devops之前已完成架构转型，与业务组成敏捷团队，采用敏捷迭代的方式交付业务价值，但目前仍然面临着很多挑战。

在产品迭代方面，研发团队日益增大，研发人数两年内增加1倍，依旧难以应付频繁插队的需求。发版频率增加，但业务感知不强。在持续交付方面，已实现持续交付流水线，发布时间长且断点多，同时技术债未收敛，系统的包袱越来越重。在高可用方面，使用场景多样化，尚未建立基于业务场景和单客户维度的精细化监控体系，生产支持人工介入比重较大。

二、devops实践的提升之道

结合业界实践案例调研和产品线自身特色，devops实践之路是由道和术两部分组成，“道”是目标、价值观，对价值的定位，“术”是战术、技术，最佳实践的层次。通过“道”的传导和落地来驱动“术”的实施。通过“术”的不断改进巩固“道”，通过道术相成来最终实现目标。根据团队自身的特点，建立以下四个价值观：

①反内卷，重实效；

②价值交付高于一切；

③文化理念驱动团队行动；

④共享，共识，共建。

在“道”的指导下，在“术”的方面也逐渐形成了一套相对完整的改进措施和实践方案，主要集中在人、流程、数据和技术四个方面。

三、devops实践提升之术

1）高效协同（人）

thoughtworks studios的首席顾问jez humble提到，devops不仅仅是个工具，更是一种理念。devops是一种使持续交付成为可能的理念，关注于所有人共同协作以改进开发效率方面的衡量（比如生产力）。为了成功地实施devops，要关注人、协作和理念，把devops融入团队中需要一种理念，主要在体现在以下三个方面。

一是组织结构要动，内部组织结构要变。以小团队为基石，以业务领域将团队成员进行划分，独立完成端到端价值的交付，其次在内部小团队的基础上，将业务人员和运维人员都包含进来，成立一个面向价值交付的跨职能虚拟团队。团队间需求柔性调整，在依据需求内容与团队匹配度进行适配的基础上，针对部分团队因饱和度无法承接的需求项进行二次分配，避免团队间负荷不均。

二是协作模式要变。业务参与研发关键环节，例如定期版本规划会，需求澄清会，迭代回顾会等。同时，产品经理和研发团队前伸，深入开展市场调研，与客户共同探索相关的业务流程，与业务交易银行中心协同分工，共同建设数据运营分工体系，根据运营结果的反馈持续改进优化，形成一个闭环。生产运维人员从sre角度提交研发需求，并按照版本参加方案评审会，参与性能容量设计评估，不断促进运维架构的提升。

三是人的能力要提升。建立人员转型所需的能力现状与成长意愿“t”型图谱。按照初，中，高三个成熟度等级、银企涉及八大板块、18个技术方向梳理人员技术能力，并结合员工发展意愿，进行定向分工，不断扩展员工知识广度，充分激发员工活力和动力，提升数字化综合能力。同时使用培训 实践双轮驱动提升团队成熟度。建立持续学习的文化机制，有规划地学习、分享。通过培训积分奖励机制，固定频率每周安排1-2名人员做分享，做到人人能分享，人人愿分享。

2）精益实践（流程）

为了最大化敏捷和devops的价值，在精益实践方面参考scrum的框架，导入需求实例化进行需求澄清，迭代计划会，迭代评审，站会、迭代验收、开卡验卡、回顾会等实践，从了解、熟悉到精通，逐版本持续优化改进，形成团队自适应的规范化运作。在研发过程中增加开卡和验卡环节，在方案评审后安排开卡环节，有效检验开发和测试人员是否理解需求。在准入测试之前增加验卡环节，开发人员针对接口功能做写主流程接口测试演示，提升测试准入质量。

在需求价值研判上，统一价值判断视角，基于rfm模型（近期是否有交易，交易频度，交易金额）等运营看板进行需求价值评估。产品经理运营指标和运营看板为数据支撑，结合“用户是谁、想要什么、如何解决、价值有哪些、什么时间做”这套需求价值灵魂五问的方法论，进行需求价值的研判和需求优先级排序。

3）度量改进（数据）

在数据度量方面，主要依赖研发过程中的指标数据，业务运营中的业务数据驱动整个过程的改进。免责的复盘回顾会是有必要的，回顾会上产品经理、架构师、开发测试全员参加，针对这个版本遇到的问题进行分析。回顾会的目的不能止步于发现问题，而是要共同讨论出解决问题或者改进效率的办法，可执行的、有衡量标准的、可跟踪的具体措施，不能是泛泛的下次注意，才能在下次迭代发布的时候进行有效的改进。以避免生产环境的bug为例，测试要多进行发版后的测试验证就是无效的措施，执行四眼审核或者是check-list清单审核制度则是有效的措施。

不同的团队关注度量点也是不同的。敏态团队注重业务价值、研发效能，平台团队关注能力共享复用、共性问题突破等，并以度量数据为基础，将局部改进扩大到全局改进，建立数据度量及洞察—>揭示问题—>优化改进的团队自演进闭环。

4）工具支撑（技术）

devops和敏捷软件开发是相辅相成的，因为它拓展和完善了持续集成和发布流程，可以确保代码在生产上可用，并且确实能给客户带来价值。在工具方面，持续集成工具链的应用已经深入人心，主要关注三个关键点：轻发布，重恢复，强卡点。轻发布即依托工商银行devops工具ci/cd标准化流水线，一键式发布，轻量级部署。重恢复即关注续集成修复时间，把故障修复时间作为团队研发的重要任务，遇到问题能一键恢复。强卡点即在关键环节设置一些“卡点”，比如双四级门禁，单元测试覆盖率90%等。根据应用特性配置自定义的代码扫描规则集，保证所有开发人员步调统一，交付高质量的产品。通过持续集成改进，提交构建流水线时长从6-10分钟缩短至2-3分钟，持续部署流水线从25分钟缩短至11分钟，部署时长缩短至10分钟以内。

devops提倡开发和it运维之间的高度协同，在完成高频率部署的同时，提高生产环境的可靠性、稳定性、弹性和安全性。高性能it运维能顺利实现“从优秀到卓越”的转变，关键点之一是如何控制和减少计划外的工作。为此，主要从灰度策略、流量管控、监控预警、根因分析四个方面入手，全面提升应用1-5-10运维能力，减少生产人工投入成本。

四、结语

通过devops3.0的实践，团队在版本部署、环境问题解决时效、业务需求交付周期等方面均得到显著提升，业务满意度，员工获得感上有明显改善，环境修复时间由3小时下降至2小时内，持续部署流水线从25分钟缩短到11分钟，技术债消除率达到80%，夯实常规故障场景从30%自愈能力提升到50%，核心交易异常报警从半小时提升到10分钟。在实践的过程中，也遇到不少困难和挑战，研发效能的提升不是“一朝一夕”的事情，目前的研发水平与同业头部科技企业相比仍然存在一定的差距，需要进一步思考、探索，并且不断实践提升，向“更快、更高质量、更可靠、可持续地交付更优的业务价值”目标持续进步。