T/CICC 08006-2026 固定式指挥中心建设通用标准 系统运行维护管理要求

　　ICS 35.240.01 CCS L 70

　　T/CICC

　　中 国 指 挥 与 控 制 学 会 团 体 标 准

　　T/CICC 08006-2026

　　固定式指挥中心建设通用标准系统运行维护管理要求

　　General standards for the construction of fixed command centers reauirements for system operation and maintenance management

　　2026-02-06 发布 2026-02-06 实施

　　中 国指挥 与控制 学会 发 布

　　T/CICC 08006-2026

　　T/CICC 08006-2026

　　前 言

　　本文件按照GB/T 1.1—2020《标准化工作导则 第1部分：标准化文件的结构和起草规则》的规定编写。

　　请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。

　　本文件由中国指挥与控制学会提出。

　　本文件由中国指挥与控制学会归口。

　　本文件起草单位：北京中兵数字科技集团有限公司、北京可信华泰科技有限公司、南京熊猫汉达科技有限公司、北京市维纳智能指挥调度技术研究院、北京鲲鹏数航标准技术有限公司。

　　本文件主要起草人：刘斌、王嘉、许岚宇、王海森、张倩、信长安、金灿灿、马文学、王峰。

　　T/CICC 08006-2026固定式指挥中心建设通用标准

　　系统运行维护管理要求

　　1 范围

　　本标准规定了指挥中心运维管理系统的系统组成、接口要求、功能要求及用户使用规范，适用于指挥中心运维管理系统的规划、建设、运行和维护。

　　2 规范性引用文件

　　GB/T 22239 信息安全技术 网络安全等级保护基本要求;

　　GB/T 33653 信息安全技术 云计算服务安全能力要求;

　　GB/T 33240 信息技术 服务管理 第 1 部分：规范;

　　GJB 7391 指挥信息系统安全防护要求。

　　3 术语和定义

　　3. 1

　　运维管理系统 System Operation and Maintenance Management

　　用于监控、维护、管理指挥中心基础设施和业务系统的集成化平台。

　　3.2

　　分系统 Subsystem

　　指挥中心内能够独立运行的显示系统、通信系统、供电系统等业务子系统。

　　3.3

　　告警分级 Alarm Grading

　　根据故障影响程度划分的告警级别，可分为紧急、严重、一般。

　　4 系统组成要求

　　4. 1 系统运维模型

　　指挥中心运维管理系统应遵循统一的运维模型进行设计及构建，该模型规范了实施运维管理应具备的对象要素和功能架构。在该模型中，运维管理系统部署在指挥中心内部，并与业务系统伴随运行，实现对指挥中心内基础设施、网络、业务系统的运行数据的集中汇聚、展现和处理，支持服务运维人员开展日常运维操作。相应的基础设施、网络、业务系统为实际的运维对象，包括网络层、资源层、平台层和应用层等对象实体。

　　4.2 系统使用对象

　　指挥中心运维管理系统的使用对象包括服务开发人员和运维管理人员。服务开发人员除完成业务功能开发外，应按本标准开发服务运行数据输出能力，输出包括服务状态数据、日志数据以及自身健康状态等。运维管理人员是运维管理系统的直接使用人员，其开展的活动包括：实时监控基础设施、网络、

　　T/CICC 08006-2026

　　业务系统的运行状态，设定告警规则与告警处置，执行运行调整操作，实施软件巡检，通过报表统计系统运行概况等。

　　4.3 运行数据采集

　　运行数据指 IT 系统和应用在运行过程中产生的反映其状态、性能、可用性和行为的数据，在指挥中心运维管理范围内运行数据包括指标、 日志、请求调用链数据三种。

　　运行数据采集的基本原则包括：

　　a) 无侵入性，即采集过程不应影响被监控系统的正常运行;

　　b) 可扩展性，即采集应支持动态添加/删除监控对象和指标;

　　c) 可靠性，即保证数据采集的完整性和连续性。

　　运维管理活动中运行数据采集的维度范围应包括：

　　a) 网络层运维对象所采集的运行数据应包括网络利用率、网络丢包数量、整体网络流量、异常事件等;

　　b) 资源层运维对象所采集的运行数据应包括物理机/虚拟机/容器资源使用情况、虚拟机云/容器云整体运行状态、异常事件等;

　　c) 平台层运维对象所采集的运行数据应包括平台共性支撑服务的运行状态、异常事件、请求调用链数据等;

　　d) 应用层运维对象所采集的运行数据应包括服务状态数据、 日志数据以及健康状态等。

　　4.4 服务运行数据输出

　　服务应主动输出运行数据并由运维管理系统进行采集，以便运维管理系统对数据进行处理分析后展现服务运行状态。服务运行数据的输出类型可分为实时状态数据、日志数据和请求调用链数据三种，实时状态数据又可分为指标数据和实时告警信息。不同类型的服务运行数据对应不同的数据输出方式，本标准中对于服务实时状态数据和日志数据的输出进行了规范性说明。

　　4.4. 1 服务实时状态数据要求

　　指挥中心内各个服务应输出包括指标数据和实时告警信息在内的实时状态数据。

　　指标数据输出可采用 HTTP 接口方式、消息服务方式以及网络 Socket 方式。

　　通过 HTTP 接口输出指标数据，服务应对外暴露形如“http://IP 地址:端口号/metrics/指标名称”的 URL 地址，运维管理系统向该地址发送 GET 方法，获取指标数据。HTTP 接口方式仅支持“拉” (Pull)模型，即只能由运维管理系统查询指标值，不支持服务向运维管理系统推送数据。

　　通过消息服务方式输出指标数据的方式应引入消息传输中间件，该方式仅支持“推 ”(Push)模型，即服务通过消息服务主动向运维管理系统推送指标样本。

　　通过网络 Socket 输出状态数据，服务开发人员应按照运维管理系统提供的 Socket 服务通信规范进行数据输出。

　　服务可以向运维管理系统推送实时告警信息，表征指定的运维对象发生了重要异常，且需要服务运维人员立即进行处理。服务通过调用运维管理系统所提供的 HTTP 接口，向运维管理系统按需推送实时告警消息。服务开发人员需严格控制向运维管理系统推送实时告警的数量和频率，所推送的告警信息必须是需要运维管理人员立即进行处理的重要异常事件。对于不需要实时进行处理的异常事件应记录到服

　　T/CICC 08006-2026务日志中。

　　4.4.2 服务日志数据要求

　　指挥中心内各个服务输出的日志类型应包括运行日志和操作日志。

　　运行日志用于记录服务运行过程中自身产生的重要事件，应包含日志时间、线程名称、类全名、函数名、代码行号、操作主体、操作主体类型、日志级别、日志内容、异常信息等信息。各个级别的日志内容信息应有实际的意义，不应使用无任何意义的内容信息。

　　运行日志输出要求包括：

　　a) 当没有错误或异常时，应简要地描述清楚具体的现状。

　　b) 当有错误或异常时，除了要描述清楚现状外，应尽可能携带异常的堆栈信息。

　　操作日志用于记录服务运行过程中用户操作产生的重要事件，除运行日志所包含的内容外，还应包含操作用户、业务对象、业务对象类型、关键程度、操作类型、 目标主体、 目标主体地址、操作结果等信息。

　　操作日志输出要求包括：

　　a) 操作日志内容应参照“某某人对某某业务对象执行某某操作” 或者“某某人怎样操作某某业务对象” 的模式来描述，并在其中说明操作的结果情况;

　　b) 当有错误或异常时，除了要描述清楚现状外，还应简要描述错误的原因，并尽可能输出错误的上下文数据;

　　c) 操作日志一般用于用户参与业务的统计分析。对于重复性无用日志(包括异常日志) 以及软件间或组件间参数传递类日志，不应输出为操作日志。

　　日志级别应包括调试、信息、警告、错误、致命五种。各级别日志输出内容应符合以下要求：

　　a) 调试类型主要用于输出软件开发调试时输出的比较详细的过程、变量、状态等信息，便于软件调试;

　　b) 信息类型用于输出软件正常运行时的重要过程和状态信息;

　　c) 警告类型输出软件运行或业务运转时出现的可控的异常信息，应输出相应的错误编号，有异常时应输出堆栈数据;

　　d) 错误类型输出软件运行或业务运转时出现的错误信息， 内容中应包含出错的场景参数、数据、相应的错误编号以及异常时的堆栈数据;

　　e) 致命类型输出软件运行或业务运转时出现的致命问题信息， 内容中应包含出错的场景参数、数据、相应的错误编号以及异常时的堆栈数据。

　　日志输出路径应按照约定的目录、格式等将日志写入到本地日志文件中，或者由运维管理系统提供统一的日志输出 SDK 进行规范化定义。

　　4.5 数据统一访问要求

　　运维管理系统应提供基于 HTTP 的访问接口，并兼容支持 HTTPS 的访问方式允许运维二次开发应用访问服务运行数据，访问过程应满足以下权限管控要求：

　　a) 只有认证通过才具备接口访问能力;

　　b) 调用方仅可根据角色限定数据访问范畴，访问该角色所能访问的服务运行数据。

　　4.6 系统核心能力

　　T/CICC 08006-2026

　　运维管理系统应包含以下核心模块：

　　a) 监控中心：实时监控基础设施、网络、业务系统的运行状态;

　　b) 告警管理： 自动识别故障并分级告警;

　　c) 工单系统：记录、分派和跟踪运维任务;

　　d) 资产管理：管理硬件、软件、网络设备的全生命周期;

　　e) 用户管理：用户角色管理、权限分配;

　　f) 日志与审计：记录操作日志、系统日志和安全审计信息;

　　g) 报表与分析：生成运维报告和趋势分析。

　　4.7 国产化要求

　　运维管理系统的核心功能模块应使用国产化软件及硬件。

　　5 接口要求

　　5. 1 与分系统的接口

　　5. 1. 1 通信系统接口

　　支持 SNMP 、RESTful API 等协议，实时获取路由器、交换机等设备状态。告警信息需包含设备 IP 、故障代码、时间戳。

　　5. 1.2 显控系统接口

　　通过 SDK 或中间件获取显示大屏的分辨率、亮度、信号源状态。

　　支持远程开关机和亮度调节。

　　5. 1.3 动力环境系统接口

　　通过 Modbus 、OPC UA 等协议采集 UPS 、空调、温湿度传感器数据。故障告警需包含电压、温度、湿度阈值超限信息。

　　5. 1.4 国产化终端接口

　　支持国产化终端的健康状态上报(CPU/内存占用率、系统日志)。

　　5.2 系统间接口规范

　　5.2. 1 数据格式

　　采用JSON/XML 格式，遵循统一数据字典(如设备 ID 、告警代码规范)。

　　5.2.2 协议兼容性

　　支持国产化协议。

　　6 功能要求

　　6. 1 实时监控功能

　　6. 1. 1 拓扑可视化

　　展示指挥中心网络拓扑、设备状态，给出红/黄/绿灯标识。

　　6. 1.2 资源监控

　　监控服务器 CPU 、内存、存储占用率，阈值≥80%时触发告警。

　　T/CICC 08006-2026网络链路带宽利用率，阈值≥90%时告警。

　　6.2 告警与应急响应

　　6.2. 1 告警分级

　　运维管理系统应具备自定义异常事件的告警级别功能，告警应依据影响程度区分为四个级别。

　　一级告警(致命)：使用红色标识，如不立即进行处置，服务将出现停机、失效等现象，需 10 分钟内响应。

　　二级告警(严重)：使用橙色标识，如不立即进行处置，可能会影响用户体验，或在未来产生致命错误，需 30 分钟内响应。

　　三级告警(一般)：使用黄色标识，如单个组件异常，性能指标超标，需 2 小时内响应。

　　三级告警(提示)：使用蓝色标识，无直接影响，需关注潜在风险。

　　6.2.2 告警处置

　　运维管理系统应具备简单故障自动处置功能和复杂故障手动管理手段。

　　自动处置功能支持通过预设策略实现故障服务自动重启。

　　手动管理手段应包括进程管理、脚本执行、服务管理、数据库操作、文件管理、通联拨测等常见运维操作功能。

　　告警处置过程中应支持查阅相应处置案例。

　　6.3 资产与配置管理

　　6.3. 1 资产台账

　　记录设备型号、序列号、保修期、位置信息。

　　6.3.2 配置版本控制

　　重要配置变更需记录变更人、时间及回退方案。

　　6.4 安全与审计

　　6.4. 1 权限管理

　　分角色权限(管理员、操作员、审计员)，支持 RBAC 模型。

　　6.4.2 日志审计

　　记录所有操作日志(含用户 IP 、时间、操作内容)，保存期限≥180 天。

　　7 用户层级要求

　　7. 1 管理员权限

　　职责：系统配置、权限分配、告警规则设置、数据备份。

　　操作限制：需双人复核关键操作(如系统重启、配置修改)。

　　7.2 运维操作员权限

　　职责：故障处理、工单派发、常规监控。

　　权限范围：仅限于告警确认、基础配置查询。

　　7.3 普通用户权限

　　职责：查看系统状态、提交运维请求。

　　权限范围：仅限于预设的监控看板和工单提交界面。

　　T/CICC 08006-2026

　　8 验收与运维规范

　　8. 1 验收要求

　　系统需通过以下测试方可通过验收：

　　a) 功能测试：验证所有模块功能达标;

　　b) 压力测试：模拟 1000 个并发设备监控，系统无崩溃或卡顿;

　　c) 国产化兼容性测试：与国产芯片、操作系统、数据库的兼容性验证。

　　8.2 运维管理要求

　　8.2. 1 定期巡检

　　每月至少 1 次全系统健康检查，生成巡检报告。

　　8.2.2 应急预案

　　制定网络中断、供电故障等场景的应急预案，并每年至少演练 1 次。