运维问数

证券行业交易系统的稳定性是生命线。监管机构对交易系统有明确的SLA要求（如故障恢复时间不超过4小时），但实际的故障记录分散在监控系统、工单系统、巡检记录等多个地方，数据口径不一致、统计周期不统一，导致每次向监管报送SLA数据时，IT部门都要花大量时间反复核对。

智能问数平台将所有故障相关数据整合到统一本体语义层：系统本体记录各交易系统的名称、负责人、SLA等级；故障本体记录故障发生时间、发现时间、恢复时间、影响范围；工单本体记录对应的故障工单编号、处理过程。运维负责人可以随时提问"本季度各系统故障平均恢复时间"，系统自动查询所有系统故障记录，按照统一的"恢复时间=实际恢复时间-故障开始时间"口径计算均值，并附上故障明细供追溯。数据透明、可追溯，监管报送时不再有争议。

技术团队首先构建运维域核心本体。系统本体记录交易系统（包括集中交易系统、融资融券系统、个股期权系统等）的编号、名称、所属机房、SLA等级、责任人；故障本体记录故障事件ID、系统、类型、发现时间、开始处理时间、恢复时间、影响范围，其中恢复时间定义为运维人员在工单中标记的"故障恢复确认时间"；本体层还定义了"恢复时长"语义：恢复时长=恢复时间-故障开始时间。恢复时长的聚合支持多种方式：均值、最大值、求和，可通过问数语义自动识别。

"各交易系统本季度故障平均恢复时间对比"这句话，系统解析出：聚合方式（均值）、指标（故障恢复时间）、对象（各交易系统）、时间范围（本季度）。语义映射层将"本季度"映射为日历季度（Q1/Q2/Q3/Q4）的精确日期范围，"各交易系统"映射为系统本体中的所有交易系统集合（排除办公系统、测试系统），"平均恢复时间"映射为故障本体的恢复时长字段的均值计算。系统还支持追问："哪些系统的恢复时间超过了SLA阈值？"——通过在聚合后加条件过滤实现。

查询执行需要对接多个监控系统（Zabbix、SolarWinds等）和工单系统（ServiceNow、自研工单平台）。不同系统的故障工单编号格式不同，系统需要做统一编码转换。查询结果按系统维度聚合，每个系统返回：故障次数、平均恢复时长、最大恢复时长、超过SLA阈值的次数。结果还附带明细列表，用户可点击查看某次故障的详细处理过程，确保数据可追溯。

不同监控系统对"故障开始时间"的认定逻辑不同：有的以监控告警触发时间为准，有的以业务影响发生时间为准，有的以用户报障时间为准。例如交易系统某日上午10:00出现卡顿，监控在10:05触发告警，用户在10:08反馈问题，运维人员在10:10确认故障。这三个时间点都是合理的"故障开始时间"候选，但计算出的恢复时长差异很大。技术团队与业务部门协商，制定了统一的故障时间认定规则："故障开始时间=业务影响发生时间，若无法确定，则使用监控告警触发时间"，并在本体层明确标注。查询结果旁附注时间认定方式，方便用户理解数据来源。

一个实际故障可能产生多个工单（用户报障工单、问题管理工单、变更工单），一个工单也可能对应多个故障（如批量故障场景）。系统无法自动将工单与故障一一对应，需要人工建立关联关系。技术团队引入了"故障事件ID"机制：每次故障在监控系统标记为一个事件，给定唯一ID，运维人员在处理工单时需要关联对应的事件ID。系统通过事件ID作为关联键，将工单数据和监控数据打通。对于历史数据（事件ID缺失的旧工单），采用模糊匹配策略（故障时间±10分钟内 + 系统相同 + 关键字匹配）进行关联，并在结果中标注"疑似关联，建议人工核对"。

故障详情中可能包含敏感信息（如安全漏洞被利用、配置错误导致数据泄露等），这些信息不适合向所有人员公开。系统基于本体层的权限语义实现分级访问：运维负责人可查看全部故障明细，部门经理可查看汇总数据和重大故障摘要，普通技术人员只能查看自己处理过的工单相关故障。同时，故障明细中的敏感字段（如根因分析中的安全相关内容）设置访问权限，只有安全运维角色可见。