🏦 银行 🏢 科技部 🔍 智能问数

开发运维问数：科技管理从人肉统计到数据驱动

科技部门智能问数应用实践

一、案例价值

科技部门此前在制作季度科技管理简报时，需要手工从四个系统中导出数据：IT服务管理系统记录变更工单，发布管理系统记录版本发布记录，监控系统记录生产事件，OA系统记录变更审批流程。科技负责人把这些数据拼凑成一张Excel表格，前后需要三到四个工作日，且数据准确率依赖制作者的经验和细心程度。

最痛苦的是领导突然追问："哪些系统本季度发布变更次数最多且产生了生产问题？"科技负责人需要临时翻遍四个系统，人工关联变更单号和生产事件记录，通常需要两天才能给出一个不完全准确的答案。更重要的是，这种人肉统计无法做到常态化监控，问题往往在领导发现后才暴露。

引入UINO数据智能引擎后，科技负责人直接在问数平台上输入这句话，系统30秒内返回结果：本季度发布变更次数超过10次且产生生产问题的系统有3个，分别是核心系统（变更14次，产障3次）、柜面系统（变更11次，产障2次）、支付系统（变更10次，产障2次）。科技管理从此有数据依据，不再靠人肉统计。问数平台上线后，季度科技简报制作时间从4个工作日缩短到2小时，科技团队的日常工作从"做报表"转变为"用数据管理"。

30秒

问数响应时间

4天→2小时

简报制作时长

100%

变更可追溯性

3个

高风险系统识别

二、技术路径

第一步：四系统数据对接与变更问题关联建模。 UINO引擎对接了IT服务管理系统（ITSM）、发布管理系统（Release Management）、生产监控系统（APM）、OA变更审批系统四个数据源。数据源分散且格式各异：ITSM以工单为主体记录变更内容，发布系统以版本包为主体记录发布记录，监控系统以事件为主体记录生产问题，OA系统以审批流程为主体记录变更授权。这四个系统之间没有天然的关联键，需要通过工单号、发布时间、系统名称等字段进行人工关联。

第二步：系统、变更、问题本体建模与多指标关联语义。 本体建模将"系统—变更—问题"三者建立关联关系。系统本体描述每个系统的基本信息、所属业务域、技术架构；变更本体记录每次变更的内容、变更类型（紧急变更/计划变更）、变更时间、变更人；问题本体记录每个生产事件的级别、发生时间、影响范围、关联变更。关联逻辑是本案例的最大挑战：并非所有生产问题都直接关联到变更（可能是日常运维触发，可能是外部攻击），需要通过时间窗口（如变更后4小时内发生的生产问题）和系统归属（如问题发生在哪个系统）两个维度进行因果关联判定。

第三步：权限过滤与变更问题智能分析。 根据科技负责人的岗位权限，引擎自动过滤出其管辖范围内的系统和变更数据。对于总行科技负责人，可以看到全行所有系统的变更和问题数据；对于分行科技人员，只能看到分行的系统和数据。引擎进一步提供"变更引发问题率"这一复合指标，用于评估各系统的变更风险水平，辅助科技资源分配决策。

四系统联邦数据融合变更问题因果关联时间窗口判定逻辑多指标复合计算系统权限分级过滤

三、过程难点

难点一：变更问题数据源分散，关联逻辑需要人工定义

变更工单和生产问题分属两个独立系统，它们之间没有直接的外键关联。科技团队需要通过"时间窗口"推断因果关系：发生在变更后4小时内的生产问题，视为可能由变更引发。但4小时的窗口是经验值，是否合理需要业务验证；且不同类型的变更（紧急变更、计划变更、数据变更）对应的窗口时长可能不同，无法用同一个窗口值适用所有场景。

解决方案：变更类型感知的时间窗口与机器学习验证

引擎根据变更类型动态调整关联时间窗口：紧急变更窗口为变更后2小时，计划变更窗口为变更后12小时，数据变更窗口为变更后48小时。同时利用历史数据训练一个"变更—问题"关联预测模型，模型会输出每个问题与各变更的关联概率，科技人员可选择概率超过阈值的问题标记为"变更关联"，用于后续分析。

难点二：生产问题记录不规范，部分事件缺失关联变更

生产事件记录主要依赖值班人员手工填报，事件描述字段格式不统一（如"核心系统挂了"、"CBANK服务不可用"等口语化描述），导致系统名称无法自动识别，需要人工进行文本分类标注。同时，约30%的生产事件没有关联变更记录（俗称"孤儿事件"），这些事件的根因分析需要额外的人工介入。

解决方案：NLP事件分类与孤儿事件根因追溯

引擎内置基于BERT的事件文本分类模型，对历史事件记录进行训练后，可以对新的事件描述自动识别系统名称和事件类型。对于孤儿事件，引擎进一步关联同时间窗口内的系统日志、变更记录、监控告警等信息，为人工根因分析提供数据支撑，将孤儿事件的根因定位时间从平均3天缩短到4小时。

难点三：变更类型多样，不同类型的变更对系统的风险程度不同

同样是一次发布变更，对核心系统的影响和对内部办公系统的影响完全不同。但变更类型字段在ITSM系统中仅标记为"一般变更"或"重要变更"两个大类，没有细化到具体的变更内容（如数据库结构变更、应用逻辑变更、配置变更、基础设施变更），导致无法区分高风险变更和低风险变更。

解决方案：变更内容智能识别与风险分级

引擎对接变更描述文本，利用关键词识别技术自动判断变更内容类型（如包含"DROP COLUMN"识别为数据库结构变更、包含"config"识别为配置变更）。结合系统重要性等级和变更类型，输出"变更风险评分"，用于在问数结果中高亮标注高风险系统。

🎯 典型问数示例

哪些系统本季度发布变更次数最多且产生了生产问题？

返回结果：本季度变更次数超过10次且产生生产问题的系统共 3个：① 核心系统（变更14次，产障3次，变更—产障关联率21.4%，风险等级：高）；② 柜面系统（变更11次，产障2次，变更—产障关联率18.2%，风险等级：中高）；③ 支付系统（变更10次，产障2次，变更—产障关联率20%，风险等级：中高）。建议优先对核心系统实施变更前测试强化方案。