打破总分行数据协作壁垒，DataOps在头部股份制银行的实践｜案例研究

从银行开始建设数据仓库至今已近20年，当前各银行机构在数据能力建设中面临诸多困扰：如何保证数据使用时的准确性？如何让数据敏捷响应业务变化？如何让更多的业务人员使用数据？

这些问题极大影响了经营指标的达成与业务的敏捷迭代。银行急需实践DataOps以增强数据能力建设，逐步实现数据驱动业务发展的目标。

当前各银行机构主要面临数据问题如下：

数据需求沟通不畅。业务人员与IT人员很容易陷入“提需求、提数、未达预期、再提需求、再提数…”循环中，而究其原因，主要是业务人员“懂业务不懂数据”，IT人员“懂数据不懂业务”，双方难以互相理解，且信息传递环节越多，信息扭曲风险越大。
数据服务效率低。经过多年的信息化系统建设，一家银行企业往往拥有数百个应用系统、多套数据平台。面对不同来源、格式各异的数据整合时，如何为各种应用提供敏捷一致的数据服务变得具有挑战性，如数据口径难以统一，海量数据查询难以高质高效，统一存储和管理需要大量时间精力等。据统计，银行企业数据开发需求平均相应周期为1.5至2周。
业务人员用数门槛高。一方面，缺乏有效的数据使用工具，导致即使有零碎的工作也需要排期处理。另一方面，当报表逻辑出错时，业务人员不清楚加工链路，无法自主查数溯源。
DataOps 是面向数据全生命周期的数据开发运营一体化理念，通过对数据相关流程制度、工具的重新组织，构建集治理、开发、运营于一体的自动化数据流水线。

DataOps通过优化数据取用链路，破除数据供需壁垒。通过开发过程透视图等工具，使用人员能够清晰的知道数据从哪里来的，是怎么被加工和处理的，确保业务人员能够随时验证数据可用性，及时与技术人员沟通需求。
DataOps通过规范数据标准，规范取用流程，提升数据敏捷响应。DataOps拥有“先设计，后开发，先标准，后建模”的数据开发运营模式，从源头控制数据质量，保证数据准确性。同时，通过搭建全域数据地图、统一开发规范指引、预设数据管理流程如申请数据或发布测试的流程节点步骤等方式，技术人员能够实现便捷找数，快速取数，提升数据敏捷响应。
DataOps通过多样化数据服务方式，满足不同技术水平的业务人员用数需求。通过搭建业务人员自助用数、查数溯源工具，可大幅提升业务人员数据使用效率，降低业务用数的门槛，促进企业内具备数据分析能力的业务人员比率逐年提升。
DataOps：打破总行与分行数据壁垒，为万人月活的大数据平台构建敏捷服务

某头部股份制银行，在全国拥有超过140家分行。该行自2018年开始建设数据中台，将“通过数据驱动经营决策”作为发展策略。发展至今，大数据服务覆盖业务人员比率，从2022年的50%，增长到2023年的60%。使用大数据平台的IT人员，月活数超万人。

随着数据量爆发式增长，数据服务覆盖人员增多，该行在总行与分行之间的数据流程，业务人员与IT人员之间的数据流程两方面，面临以下挑战。

01 总行与分行之间的流程问题：各分行数据自治，总行数据准确性面临挑战

现状：该行数据管理体系中，各个分行都拥有独立的数据仓库，以及独立的数据团队负责数据开发与分析工作，所有数据会都在T+1时段与总行同步。

问题：各分行的数据自治，使得总行需要与分行进行数据同步，但同步后数据准确性面临挑战。由于分行间的信息化水平和所选择的供应商存在较大差异，各个分行在开发平台的选择和开发规范上都存在显著的差异。数据同步至总行后，由于数据标准差异，导致数据难以统一管理，总行需要二次数据治理，以确保数据有效性和准确性。

02 业务与IT的流程问题：传统数据开发模式面临数据准确性、敏捷响应、用数效率等挑战

现状：在传统的数据开发模式中，业务人员提出数据需求，IT人员分析需求，并将需求转化为实际的数据查询和提取任务。

问题：

数据准确性：业务人员与IT人员无法找到共同语言，需求分析不准确，数据口径难以对齐。在最初业务人员与IT人员的沟通中，由于IT人员缺乏业务理解能力，业务人员缺乏技术知识，出现了数据需求在供需两端沟通不畅的问题。导致取数准确性无法保证。
敏捷响应：“数据烟囱模式”明显，IT人员查找相应数据面临找数难，取数慢两个问题。一方面，烟囱式建设使各业务系统间数据关联出现了各种各样的问题，使得IT人员在查找数据时面临找到难，理解难等问题。同时，在不同的部门系统中进行检索时，每个系统的数据结构和访问权限都可能不同，跨行使用数据使用时，申请审批流程会造成取数慢的问题。最终导致数据开发受阻，整个流程效率较低。
用数效率：业务人员取数门槛高，无法自助式取数。即使零碎的数据取用需求，也需要找IT人员排产，业务人员需要等待很长时间才能获得所需的数据。
基于上述痛点，该银行利用DataOps理念，通过对数据相关流程制度、工具的重新组织，打破协作壁垒，构建集治理、开发、运营于一体的自动化数据流水线。

03 总行与分行之间的流程问题：统一数据开发流程规范、统一数据云平台，保证数据准确性

流程制度：该银行制定了统一的数据规范（基础标准、指标标准、模型标准等）以及数据开发流程，并通过将数据质量管控环节前置，以及在开发过程中持续对数据质量进行校验的方式，保证数据准确性。

首先，改变原来“先开发，后治理”的模式，形成“先设计，后开发，先标准，后建模”的新模式。在设计阶段就由业务人员与IT人员共同将数据规范，安全标准等确定下来。即使分行将工作进行外包，也需要按照该流程规范执行，从而大幅度提升数据准确性。其次，在开发过程中嵌入治理活动，通过自动化运维和数据全链路监控等流程，构建数据全链路可观测能力，实现数据质量端到端的运维监控，最终保证数据准确性。

工具：为保证数据质量，总行搭建了一个供分行使用的分行云数据平台，将分行全部数据开发工作转移至统一平台进行，使总行能够统一管理。在云平台未完整建成前，将各分行的非核心数据开发工作统一在该平台上进行，传统的核心数据报表仍然在原有系统中执行。最后达成所有核心，非核心数据开发工作统一全部在该数据平台完成的目标。

04 业务与IT的流程问题：搭建端到端数据管道，保证数据准确性，提高敏捷响应与用数效率

数据准确性：搭建协同平台，提供开发过程透视图，保证需求分析准确性

工具：该行在云平台上提供了涉及所有相关业务人员和数据人员的协同平台，保证数据取用各团队的无障碍沟通，促进团队之间的高效协作。同时，通过搭建开发过程中的透视图，让业务部门能够在开发过程中看到结果，随时完成数据需求的沟通对齐。

敏捷响应：预设数据管理流程，统一数据湖并集成银行内部工具，保证数据迅速取用

流程制度：为解决“取数慢”的问题，该行在统一云平台上预设了明确的数据流程管理规范。通过标准化申请数据或发布测试的流程，方便不同团队之间数据申请的审批，加快数据的查找与取用流程。为了进一步解决“取数慢”的问题，该银行在云平台上集成了工作流，即时通讯等银行内部工具，形成工具间的串联，提升数据取用的审批响应速度。当IT人员需要用其他分行数据时候，可以直接在该平台通过内部工具一站式提起需求申请。

工具：为解决“找数难”的问题，首先，总行使用了统一的数据湖，将分行数据全部汇总在数据湖中，实现数据的集中、标准化和高效管理。同时，该银行重新构建了元数据管理体系，搭建了数据地图。以“能找到，看明白，放心用”为目标，为使用者提供找数看数的门户。使其能够自助找到数据，查询数据详情，确保数据服务的可靠性，提升数据查找的效率。

用数效率：提供自助报表分析工具，赋能业务人员解决零散问题能力。

工具：为了解决业务人员零散的数据问题，减轻IT人员工作负担。该行还在平台上提供自助报表数据分析工具，供业务人员解决简单的数据分析工作。

05 以提高数据质量为“抓手”，逐步落地DataOps治理体系

在项目落地过程中，由于DataOps涉及的范围相对较广，不仅包括了数据的治理、开发、运营等关键环节，还囊括了相应的管理流程体系。所以在实施过程中，选择正确的入手点则显得尤为重要。

06 由于银行对于数据安全与合规要求较高，在项目落地阶段主要会面临以下三个挑战：

数据迁移中保证数据安全：在前期TD数据仓迁移阶段，由于银行数据保密要求较高，该银行选择先将非核心数据迁移至总行数据湖，并将该部分数据治理与开发工作迁移在分行云上完成，核心数据报表仍然保留在分行TD数据仓完成。随着分行云功能的完善，各分行开始迁移核心数据，逐渐在分行云上完成所有数据治理与开发工作。
数据使用脱敏：该行拥有两个网络系统，办公网与生产网物理隔开。为保证数据安全使用，该行在两个网络下各部署了一套分行云系统。办公网设置为开发态，主要做数据加工，工作流编排，数据探索等工作（一个集群一个态），脱敏后导出任务包放入生产网。生产网分为测试态和生产态（一个集群两个态）。数据在生产网继续进行测试等工作。同时，在测试态制作类似数据沙箱的机制，即测试态可以读取生产态的数据，但写入时将写入测试态的库里面，避免数据污染。
内部工具集成要求高：银行行业特征决定了其监管需求较重，需要在考虑生产稳定，开发质量有保证的情况下，提高敏捷度。所以对于内部已有资源的打通，串联要求较高。
至今，经过一系列DataOps改革，该银行数据云平台已经成功推广到一半以上的分行进行使用，分行对IT人员中的数据治理人员需求有了明显下降。平台上拥有上千个数据项目，每天达到近十万次作业数。数据开发周期从原来的一到两周缩短至一到两天。未来，该银行将围绕多元化的数据服务，进行数据探索能力的建设。