《国家综合交通运输信息平台应用系统运维管理规范》

JT/TXXXX—XXXX

国家综合交通运输信息平台应用系统运维管理规范

1范围

本文件提出了国家综合交通运输信息平台应用系统运维管理模型和运维服务需求，规定了国家综

合交通运输信息平台应用系统运维服务要求、保障机制以及效果评估。

本文件适用于国家综合交通运输信息平台上运行的应用系统运维的管理。

2规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，

仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本

文件。

GB/T28827.3信息技术服务运行维护第3部分：应急响应规范

GB/T37376交通运输数字证书格式

JT/T1534国家综合交通运输信息平台视频资源接入技术要求

3术语和定义、缩略语

术语和定义

JT/T1534界定的以及下列术语和定义适用于本文件。

3.1.1

应用系统applicationsystem

国家综合交通运输信息平台环境中运行的调度指挥、运行监测、行政办公、政务服务、信用监

管、综合执法、运输管理等7类应用软件，还包含其运行所需的数据。

3.1.2

应用系统管理者applicationsystemmanager

国家综合交通运输信息平台环境中运行的应用系统的管理者。

缩略语

下列缩略语适用于本文件。

EOP：应急操作流程(EmergencyOperationProcedure)

NTIP：国家综合交通运输信息平台（NationalTransportationInformationPlatform）

SLA：服务级别协议(ServiceLevelAgreement)

4应用系统运维管理模型

NTIP应用系统的运维管理模型包括运维服务需求、运维服务要求、运维保障机制、运维服务效果评

估，见图1：

1

JT/TXXXX—XXXX

a)运维服务需求是NTIP依据运维服务方针和目标，识别应用系统管理者对服务的需求或期望，

定义符合NTIP环境，策划并制定运维服务方案，直接或间接地为服务需求方和利益相关者实

现服务价值；

b)运维服务要求是在NTIP环境下运行的系统按照运维服务需求，针对应用系统运维工作进行策

划、实施、检查、改进的运维活动，运维活动涉及应用系统的设计阶段、交付阶段、运行阶段、

终止阶段；

c)运维保障机制是通过管理应用系统相关人员、过程、技术、资源等，实现应用系统运维服务要

求，满足应用系统运维服务全生命周期保障；

d)运维服务效果评估是应用系统按照运维评价要求对运维进行监督、测量、分析和评审，以实现

运维服务能力的持续提升。

运维保障机制：人员、过程、技术、资源

运维服务要求（技术、管理）

策划实施

应用系统服务运维服务需求

设计阶段交付阶段运维服务效果评估

运运维对设计运维对交付

维

服的要求的要求

务对象

需终止阶段内容运行阶段

求

终止要求运维的要求

改进检查

图1国家综合交通运输信息平台应用系统运维管理模型

5运维服务需求

运维服务对象

应用系统的运维应至少包括以下服务对象。

a)应用系统包括：

1)实现业务功能的各种软件；

2)应用于自身管理的工具软件。

b)应用系统运行的数据包括：

2

JT/TXXXX—XXXX

1)业务数据：业务系统采集、分析并存储的各种信息；

2)运维数据：运维过程中产生的各类运维信息、运行状态日志、故障处理文档等数据；

3)安全数据：在业务运行和运维过程中与安全相关的数据。

运维服务内容

应用系统的运维应至少包括以下服务内容。

a)调研评估：对运维对象的运行状况进行分析和评估，并提出方案建议。

b)例行操作：

1)监控：对运维对象的动态指标、静态指标、运行状况和发展趋势等进行记录、分析和告警；

2)预防性检查：对监控记录、运行条件和运行状况进行检查和趋势分析；

3)常规作业：对运维对象进行的日常维护，包括定期维护、配置备份、数据备份、数据恢复、

定期重启等活动。

c)响应支持：

1)事件驱动响应：由外部事件、系统事件或安全事件，导致运维对象整体或部分性能下降、

功能丧失，而触发的将运维对象恢复到正常状态的活动；

2)服务请求响应：由需方提出各类服务请求，引发的需要针对运维对象、服务级别做出调整

或修改的响应型服务，可能涉及服务级别、服务范围、技术资源、服务提供方式等的变更；

3)应急响应：依据GB/T28827.3规定的应急响应服务，执行运维服务EOP。

d)优化改善：

1)适应性改进：为保持运维对象在新环境中可持续运行而实施的优化改进；

2)增强性改进：采取改进措施，增强数据中心的安全性、可用性和可靠性；

3)预防性改进：检测和纠正维护对象运行过程中潜在的问题或缺陷。

注：运维服务内容(交付内容)要求见GB/T28827.2。

运维活动

5.3.1应用系统的运维活动满足以下要求。

a)应识别NTIP和应用系统运维相关方，建立运维服务机制和协同机制，应用系统运维的权责分

明并保持一致。

b)分析运维服务需求，策划应用系统的运维活动时满足以下要求：

1)应明确运维SLA要求；

2)运维应符合NTIP和应用系统的业务环境；

3)宜考虑数据维护和可持续改进要求；

4)应评估在NTIP环境下，影响应用系统运行的变化，确定需应对的风险和机遇的运维要求。

c)应用系统管理者应依据策划实施运维活动，实施运维活动应满足以下要求：

1)进行运维知识全生命周期管理；

2)实施培训，策划并实施NTIP和应用系统的业务流程培训、功能培训、操作培训等；

3)运维结果形成规范化的文档，并满足安全保密要求。

d)应评价应用系统的运维活动的可用性、安全性、稳定性和可靠性，并符合业务的需要。

e)适用时，可利用工具进行应用系统的运维，工具选择和使用应满足以下要求：

1)工具适合所开展的运维活动及应用系统的特定类型和要求；

2)工具具备自动化的能力；

3)工具定期维护，具备持续可用性。

5.3.2策划应用系统的运维活动时宜满足以下管理要求：

3

JT/TXXXX—XXXX

a)应用系统管理者建立满足NTIP和应用系统要求的运维管理体系和制度体系，规范系统运维职

责，对运维活动的人员、过程、技术、资源等提出管理要求；

b)依据应用系统管理者的业务发展需要，确定运维服务方针和目标。

运维能力

5.4.1策划应至少包括以下内容：

a)建立服务目录，结合使用大模型、云技术等新技术策划运维服务对象的服务内容与要求。

b)识别影响运维服务能力的外包服务，对外包提供方的服务能力进行策划和管理。

c)对人员、过程、技术和资源进行策划并保留记录，包括：

1)针对应用系统相关人员，策划适宜的岗位结构和管理职责，策划人员能力规划、人员储备、

人员培训、绩效管理、能力评价等；

2)识别并建立过程，设计过程框架，确定过程之间的关系，策划各过程的目标、应达到的能

力要求、过程的执行保障等；

3)识别现有技术与服务需求间的差距，确定技术管理目标，规划技术研发与成果应用等方面

的技术实现方案；

4)综合评估资源的现状与趋势，确定资源管理目标，提出运维工具、最终软件库、服务数据、

服务知识等资源的配备方案。

d)建立系统功能的能力指标体系，包括指标、度量方法、数据来源及评价方法等。

e)确定质量目标，策划如何管理、审核并改进服务质量，形成服务质量管理计划。

f)对策划结果适宜性、合规性等方面进行评审，必要时进行修订。

5.4.2实施应至少包括以下内容：

a)制定与运维服务能力管理要求相适应的实施计划，并按计划实施；

b)建立应用系统管理者内外部的沟通协调机制；

c)建立应用系统管理者与NTIP的沟通协调机制；

d)对实施活动进行管理，确定实施计划的执行可追溯，服务结果可计量或可评价并对其进行管理；

e)提交满足质量要求的交付物；

f)形成必要的记录，并对记录进行管理。

5.4.3检查应至少包括以下内容：

a)对服务绩效及能力水平进行评价，包含服务能力实施情况、各项指标达成情况、SLA达成情况、

需方满意度等；

b)评价适用的法律法规要求的符合性；

c)应用系统管理者进行内部审核，评价运维服务能力要求的符合性和有效性，识别薄弱环节和潜

在的改进机会；

d)应用系统管理者进行管理评审，评价运维服务能力体系的适宜性、充分性和有效性，找出与预

期目标的差距和改进的机会。

5.4.4改进应至少包括以下内容：

a)建立服务能力管理的持续改进机制；

b)对不符合策划要求的行为进行总结分析；

c)对未达成的指标进行调查分析；

d)对需方不满意的情况进行分析与改进；

e)根据分析结果确定改进措施，制定服务能力改进计划，并跟踪、评价改进活动的实施效果。

6运维服务要求

4

JT/TXXXX—XXXX

设计要求

6.1.1应用系统的设计应满足应用系统的可监控性、易用性、安全性和可维护性，宜适应需求的快速

变更，支持应用系统变更发布的持续交付。

6.1.2可监控性设计要求应至少包括以下内容：

a)支持监控范围、监控对象的种类及数量变化；

b)监控配置管理实时信息；

c)监控应用系统运行稳定性；

d)监控应用系统的业务质量；

e)适用时满足以下要求：

1)提供主动巡查监控点、主动发现问题、主动告警等监控措施；

2)提供验证监控点输出的有效性，保留监控点输出的关键信息；

3)监控功能与业务功能相对独立，不影响业务功能和性能。

6.1.3易用性设计应满足以下要求：

a)设计界面的人机界面友好、操作简单、易配置、易部署安装；

b)方便配置即能满足应用系统基础维护要求；

c)提供高风险操作的确认提示或异步验证，如不可恢复操作；

d)运维数据便于提取；

e)提供接口，并满足协议要求。

6.1.4安全性设计应满足以下要求：

a)管理运维操作人员的角色和权限的划分；

b)运维角色划分清晰、职责明确；

c)运维操作人员采用GB/T37376中规定的交通运输数字证书进行身份认证；

d)主动防御或抑制运维未授权操作；

e)采用符合交通运输行业要求的加密算法进行数据传输和存储保护；

f)完整记录审计日志，并确保日志记录不少于6个月。

6.1.5可维护性设计应满足以下要求：

a)软件架构层次分明，功能和接口清晰，设计模块化，代码复用性高和代码规范；

b)易诊断和分析应用系统运行状况；

c)功能和接口易修改，可扩展；

d)具备适应需求变更的可配置性；

e)具备对运行软环境的适应性；

f)适用时，为适应业务需求的快速变更，应用系统变更发布能持续交付。设计要求包括但不限于：

1)基于业务闭环的软件架构设计；

2)支持快速变更的自动化质量控制；

3)支持应用系统在运行状态中的自动化发布；

4)支持发布异常的回退。

交付要求

应用系统应至少满足以下交付要求：

a)应用系统稳定运行所需的相关配置信息，完整且可编辑和可编译的应用软件源代码；

b)应用系统管理权限设置准确性的验证记录；

c)应用系统文档规范、齐备；

5

JT/TXXXX—XXXX

d)应用系统运维人员进行培训或能力验证的记录；

e)明确应用系统运维相关方责任的清单；

f)交付内容，包括应用系统的文档、备份、基线、模拟环境、培训资料、知识库等；

g)对应用系统的安全性进行评估，包括风险识别、漏洞扫描、代码审计等，必要时对应用系统实

施加固。

运维要求

6.3.1运行环境的运维

6.3.1.1调研评估应至少满足以下要求：

a)对应用系统组成要素的构成分解、关联关系分析和应用系统的维护性分析，提出应用系统的运

行报告或建议；

b)应用系统组成要素的构成分解应根据业务流程和应用系统架构设计，层次化分解应用系统，识

别关键业务点和核心业务系统；

c)应用系统构成的关联关系分析，包括与NTIP关联的非核心业务系统、接口连接、依存关系等；

d)应用系统的维护性分析，包括应用系统的可监控性、应用系统的易用性、应用系统的安全性、

应用系统的可维护性，明确应用系统运行方式、组成要素及运维特点。

6.3.1.2例行操作应至少满足以下要求：

a)应用系统运行的监控指标体系设计包括识别应用系统运行监控点，建立监控指标；

b)应用系统运行的监控用于监控应用系统的运行及状态；

c)调查客户对运维的满意度及改进建议等；

d)分析维护事件，识别问题和风险。

6.3.1.3响应支持应至少满足以下要求：

a)受理服务请求，包括故障请求和非故障请求；

b)按服务级别协议分类处理；

c)排查、诊断定位故障；

d)基于应用系统重要性制定解决方案制定应基于应用系统重要性，确定解决方案；

e)执行故障解决方案，检测、监控、跟踪故障处理效果，将处理经验和建议纳入知识库；

f)新用户、新系统功能上线前、上线中、上线后的服务，包括配置用户及用户权限、数据初始化、

安全性检查和功能使用培训等；

g)针对应用系统故障影响范围大且不能在业务连续性规定要求内解决所采取的措施，包括应急

应用系统管理者架构确定、应急预案编制、应急演练、应急处置和应急回顾。

6.3.1.4优化改善满足以下要求。

a)识别优化改善的机会时宜满足以下要求：

1)应用系统的监控指标接近或超出阈值；

2)例行操作中未解决根本原因的问题；

3)响应支持中重复出现事件、用户不满意等；

4)例行操作和响应支持中识别出的风险；

5)应用系统支持的业务需求变化。

b)功能性改进，应包括应用软件的功能缺陷修复、满足业务需求变化(如流程改造、政策适应性

改造等)而对应用软件功能的修改、完善和新增开发。

c)性能优化改进，应包括：

6

JT/TXXXX—XXXX

1)因应用软件性能问题而对其功能的修改和完善，应用消息队列、共享内存优化，应用服务

能力优化等；

2)对应用软件运行软环境(中间件、数据库、操作系统等)实施调优、升级或扩容等。

d)适应性改进，应包括：

1)应用软件因适应变化对其功能的修改和完善；

2)对应用软件运行软环境(中间件、数据库、操作系统等)的适应性实施调整等。

e)预防性改进，应包括：

1)应用软件可能存在某种威胁或风险而对其件功能的修改和完善；

2)对应用软件运行软环境(中间件、数据库、操作系统等)的脆弱点实施改进等。

注：优化改善可考虑持续集成和持续交付。

6.3.2数据维护的要求

6.3.2.1例行操作应至少满足以下要求。

a)数据监控：制定监控策略，依据业务规则设置告警，对应用软件功能模块各项异常操作告警，

保证数据的完整性、准确性。

b)预防性检查：针对与应用系统关联的数据(包括初始数据、基础数据、业务数据、配置数据、

报表数据和授权数据等),建立授权及一致性的标准和规则，依据标准和规则检查数据之间的

一致性、符合性和安全性。

c)常规检查：抽样检查业务数据的真实性、有效性，防止数据错误，影响业务的正常开展。

6.3.2.2优化改善应至少满足以下要求。

a)诊断分析：围绕例行操作和响应支持中出现频率多、影响范围、重要程度的数据问题诊断分析。

b)解决：针对诊断分析结果，制定解决方案并实施。

c)改进：根据调研评估请求，改进数据例行操作和数据响应支持，提出优化方案并实施改进。

6.3.2.3评估分析应至少满足以下要求：

a)数据质量评估，包括基础数据质量评估、辅助数据质量评估和业务数据的影响分析；

b)数据修改影响评估，包括应用系统参数修改的影响评估、数据字典修改的影响评估、基础数据

修改的影响评估和业务数据修改的影响评估；

c)数据规范评估，包括基础数据共同遵守规则和命名的评估、NTIP内的应用系统类型数据的规

则评估和业务关键数据应遵循的规则评估；

d)业务数据分析，包括面向应用系统重点支撑运营和战略需求的数据分析和面向预测重点支撑

业态发展趋势的数据分析；

e)应用软件变更对数据影响的评估，包括业务扩展、功能扩展等应用系统变更引起对数据完整性、

一致性的评估，以及应用系统升级、变更等对数据完整性、一致性的评估。

终止要求

应用系统终止应至少满足以下要求。

a)制定终止计划，撤销运行和维护应用系统管理者的支持，并将其形成文档。策划活动让用户参

与。该计划涉及包括以下内容：

1)一定时期之后，终止全部或部分支持；

2)应用系统及其相关文档的归档；

3)任何未来后续支持事项的职责；

4)适用时，转换为新的应用系统；

5)归档数据副本的可访问性。

7

JT/TXXXX—XXXX

b)用户得到终止计划和活动的通知。通知包括以下内容：

1)替代或升级的应用系统及其生效日期的说明；

2)该应用系统不再得到支持的理由说明；

3)一旦失去支持时，其他可用支持方案的说明。

c)终止应用系统和新应用系统并行运行，确定平稳过渡到新系统。在此期间，按照服务级别协议

的规定为用户提供培训。

d)当预定的终止到来时，通知所有相关方。适用时，所有相关文档、日志归档保存。

e)根据服务级别协议关于数据的保护和审核要求，终止应用系统使用的或与终止应用系统相关

的数据是可访问的。

7运维保障机制

人员

7.1.1应用系统管理者应依据运维服务能力策划要求，进行人员能力策划、岗位结构、人员储备、人

员培训、绩效管理和能力评价等管理活动。

7.1.2运维人员应满足以下要求：

a)与信息技术相关的基础知识，从事运维服务所需的专业知识、交通运输行业和应用系统管理者

等相关知识；

b)从事运维服务的基本技能、专业技能、软技能；

c)从事运维服务所需的经验；

d)特殊环境运维人员具有相关资格。

注1：人员管理的范围包括内部人员和外包人员。

注2：相关资质包括但不限于IT服务工程师、信息系统运维管理工程师等。

7.1.3人员能力策划应至少满足以下要求：

a)根据当前和未来运维服务业务需求，识别具备的运维服务能力要求，同时考虑新技术、新模式

以及信息技术应用创新方面所需要的运维服务能力要求；

b)对应用系统管理者当前运维服务能力现状进行差距分析，识别人员能力改进方向；

c)从投入成本、预期收益等方面考虑，确定人员需求、人员能力提升目标，制定未来一段时间内

的人员能力计划。

7.1.4人员储备应至少满足以下要求：

a)建立与运维服务相关的人员储备机制；

b)根据NTIP环境下的业务需求，在人员储备实施计划中考虑对应的人员储备；

c)根据人员储备实施计划进行人员储备。

7.1.5人员培训应至少满足以下要求：

a)建立运维服务人员培训机制；

b)根据NTIP环境下的业务需求，在人员培训实施计划中考虑对应的培训内容、频次、受众等；

c)实施人员培训，并对培训效果进行评价。

7.1.6绩效管理应至少满足以下要求：

a)建立运维服务人员绩效管理机制；

b)根据绩效管理机制和人员能力计划，实施人员绩效管理。

7.1.7能力评价应至少满足以下要求：

a)建立运维服务对应岗位的等级评价标准；

8

JT/TXXXX—XXXX

b)建立运维服务团队和人员能力评价机制；

c)实施团队和人员能力评价；

d)依据评价结果对人员能力进行持续改进，需要时调整人员能力计划。

过程

7.2.1应用系统管理者应结合NTIP与运维服务能力策划要求，设计过程框架，明确各过程之间的关系

和接口，制定服务级别、服务报告、事件、问题、变更、发布、配置、可用性和连续性、系统容量、信

息安全等管理过程的目标、活动和考核指标，支撑服务过程的规范化管理和服务价值实现，定期对过程

运行结果进行评估，并依据评估结果对过程框架设计进行持续改进和跟踪。

7.2.2过程框架设计应至少满足以下要求：

a)建立与过程规划相一致的活动，包括需求识别、过程框架设计、评价与改进等活动。

b)应用系统管理者在服务过程实施前，对服务需求涉及范围、目标、关键绩效指标等进行协商并

达成一致，形成服务需求结果。

c)依据服务需求识别的结果进行分析，明确过程框架设计涵盖范围，并与相关方达成一致后输出

服务需求说明。

d)依据已达成一致的需求说明指定过程框架设计所有者，由其主导过程框架设计活动。

e)过程框架设计可依据服务需求进行过程组合或增加，包括但不限于以下过程：

1)服务级别管理；

2)服务报告；

3)事件管理；

4)问题管理；

5)变更管理；

6)发布管理；

7)配置管理；

8)服务可用性和连续性管理；

9)系统容量管理；

10)信息安全管理。

f)过程框架设计明确列出的过程之间关系及接口，至少包括过程间输入、输出的定义。

g)各过程设置过程衡量指标，并定期进行回顾。

h)过程框架设计形成文件化的产出物，作为过程运行指导。

7.2.3服务级别管理应至少满足以下要求：

a)建立服务级别管理过程，包括识别、约定、监控、评估等活动；

b)定期对服务目录进行评审和修订；

c)与需方约定SLA；

d)明确第三方人员服务级别；

e)对成本投入要进行平衡；

f)根据应用系统管理者的考核评估要求，建立SLA考核自评估机制，包括SLA完成情况、达成率

等；

g)定期识别服务级别需求并实施调整。

7.2.4服务报告应至少满足以下要求：

a)建立与服务报告过程相一致的活动，包括计划、编制、审批、提交、归档等；

b)建立服务报告模板，包括格式、提纲等；

c)编制服务报告计划，包括需方接收对象、内容要求、提交方式、时间频次和报告形式等；

9

JT/TXXXX—XXXX

d)服务报告内容包括服务级别协议达成情况；

e)服务报告编制完成并经过审批后按照服务报告计划进行提交。

7.2.5事件管理应至少满足以下要求：

a)建立与事件管理流程相一致的活动，包括事件识别、报告、受理、调查和诊断、解决、进展监

控与跟踪、关闭等；

b)建立事件分级、分类及升级机制；

c)针对事件的处理过程和结果进行回访；

d)定期统计分析事件数据与执行情况，建立事件评估及改进机制；

e)将未知、无法解决和共性的事件，与问题管理建立必要的关联。

7.2.6问题管理应至少满足以下要求：

a)建立与问题管理流程相一致的活动，包括问题识别、分类、调查和诊断、解决、关闭等；

b)建立问题分类、分级机制，包括问题的影响范围、重要程度、紧急程度并确定优先级；

c)识别已知错误，在没有彻底解决前，应用系统管理者采取措施以减轻或消除问题对服务的影响；

d)建立问题导入知识库的机制；

e)建立问题解决评估机制。

7.2.7变更管理应至少满足以下要求：

a)建立与变更管理过程一致的活动，包括请求、评估、审核、实施、确认和回顾等；

b)明确变更范围，建立变更分类分级机制及相关的管理要求；

c)准确记录变更过程及内容信息；

d)评审变更活动的有效性，并与相关方协商达成一致；

e)对变更流程的实施情况进行统计分析，包括未经批准变更数量及占比、不同类型的变更数量及

占比、不成功的变更数量及占比、取消的变更数量及占比、变更关联的配置数。

7.2.8发布管理应至少满足以下要求：

a)建立与发布管理过程一致的活动，包括规划、测试、部署和验证等；

b)建立发布类型、范围及相配套的管理机制；

c)制定合适的发布方案，应包括发布计划、测试方案、回退方案等；

d)记录部署活动中的主要动作、结果和相关信息；

e)对发布完成情况进行统计分析，包括发布成功率、发布及时率、是否更新配置管理数据库等。

7.2.9配置管理应至少满足以下要求：

a)建立与配置管理过程相一致的活动，包括对配置项的识别、收集、记录、更新和审核等；

b)建立满足服务交付要求的统一的配置管理数据库；

c)及时更新维护配置管理数据库；

d)建立配置管理数据库审核机制，至少包括审核范围、周期、方式等。

7.2.10服务可用性和连续性应至少满足以下要求：

a)建立与服务可用性和连续性管理过程相一致的活动，包括识别关键服务与业务应用、确定服务

可用性和连续性需求和目标、定义可用性指标及目标值、对可用性进行监控、分析、评估、检

查、记录并制定优化改进机制，建立和实施服务连续性计划、定期对服务连续性进行演练等；

b)基于业务需求、服务级别协议和已识别的风险，明确与需方协商一致的服务可用性和连续性要

求，制订保障及提高服务可用性的具体措施和计划，根据连续性要求，建立、实施并维护服务

连续性计划，同时明确定义出激活连续性计划的条件、程序、职责分工和恢复要求；

c)针对连续性计划至少每年演练一次，并根据测试结果完善连续性计划；

d)当已经激活了连续性计划，报告原因、影响、恢复活动及改进措施；

e)当业务环境发生重大变更时，重新演练连续性计划的有效性。

10

JT/TXXXX—XXXX

7.2.11系统容量管理应至少满足以下要求：

a)建立与业务需求相一致的容量管理活动，包括识别、分析和调整等；

b)识别出系统容量管理中宜考虑的核心要素，如计算/存储/网络等；

c)分析容量现状与业务需求的匹配程度；

d)依据业务需求变化的趋势判断，有针对性地对资产容量进行调整。

7.2.12信息安全管理应至少满足以下要求：

a)建立符合相关法律法规的信息安全管理制度，满足运维服务过程的信息安全需求，包括信息安

全方针、目标和安全策略；

b)建立与信息安全管理过程一致的活动，包括计划、识别、评估、处置和改进等，并保留相关记

录。

注：具体信息安全管理内容见GB/T22239和GB/T22080。

技术

7.3.1应用系统管理者应根据运维服务能力策划要求，实施技术管理、技术研发和技术成果应用等活

动，保证技术能力满足NTIP的服务要求，实现其服务价值。

7.3.2技术管理应至少满足以下要求：

a)根据NTIP的要求，确定技术研发范围；

b)选择技术研发方式，方式包括自研、外采及合作研发等；

c)分配和管理资金及预算，配备必要的技术研发环境和研发队伍；

d)识别和评估技术研发风险，采取有效控制措施；

e)管理技术研发活动，监控和报告技术研发活动的执行情况；

f)评价和验收技术研发成果。

7.3.3技术研发应至少满足以下要求：

a)分析技术需求，选择技术研发实现路径。

b)识别满足需求的新技术机会，将成熟技术、储备技术和新技术进行融合，满足需要。

注：新技术包括存储技术、虚拟技术、数据库技术、分布式计算技术、云计算技术、大数据技术、人工智能技术、

开发运维一体化(DevOps)技术、物联网技术等。

c)确定技术转化为服务能力的方法，包括但不限于：

1)发现和解决问题的技术手段、方案或手册，以及验证标准和方法；

2)对潜在风险诊断、分析、处置的方法和手段；

3)业务系统或运行环境的二次开发，包括处理BUG、优化系统性能、系统的持续改进等；

4)引入技术达到优化业务问题或为业务带来价值的技术或手段。

d)验证、确认和发布技术研发结果。

7.3.4技术应用应至少满足以下要求：

a)识别技术成果应用机会，制定技术成果在人员、过程或资源等能力要素中的应用方案；

b)按应用方案实施，确保技术成果得到有效应用；

c)评价应用方案和技术成果的效果和价值。

资源

7.4.1应用系统管理者应根据运维服务能力策划要求和NTIP的需求，按需建立和管理运维工具、最终

软件库、服务数据和服务知识等，实现与人员、过程和技术结合。

7.4.2运维工具应至少满足以下要求：

11

JT/TXXXX—XXXX

a)依据服务需求，选择运维工具；

b)制定运维工具的部署、应用方案，并实施；

c)必要时，通过技术研发实现工具间的集成；

d)制定运维工具的管理制度；

e)定期评估运维工具的应用效果并改进。

7.4.3最终软件库应至少满足以下要求：

a)规划最终软件库的应用范围、管理工具、控制手段等；

a)制定最终软件库管理策略、权责及制度，包括计划、出入库、检测、退出等活动；

b)选择适宜的空间和媒介存放各类软件；

c)制定软件版本、配置项、配置基线等的管理制度，确保只有经过授权或评估后的软件才能进入

最终软件库；

d)制定最终软件库的访问控制策略并执行；

e)定期对最终软件库中的软件版本进行可用性检查，保持与运维服务需求的一致性；

f)定期对软件库进行备份；

g)定期对软件库的使用和管理情况进行评估，持续改进。

7.4.4服务数据应至少满足以下要求：

a)针对NTIP的特点定义服务数据的类型、内容、格式等；

b)制定服务数据的采集、存储、分析、处理、展示和利用等活动的管理要求；

c)确保服务数据管理活动的合规性；

d)利用工具对服务数据进行管理；

e)制定服务数据质量管理和数据安全等方面的要求；

f)对服务数据进行统计分析，并运用服务数据分析结果，支持运维服务管理决策，改进运维服务

的效率和质量。

7.4.5服务知识至少满足以下要求：

a)应明确定义服务知识范围和类型；

b)应确定提炼并形成服务知识的管理要求；

c)应建立服务知识管理制度，管理知识的获取、评审、保存、分享等活动；

d)应使用适宜的技术手段实现知识的全生命周期管理；

e)应建立知识有效性及利用率的评价机制，以促进知识更新；

f)宜通过应用知识建模、算法实现和特征工程等手段实现知识的深度学习和进化。

8运维服务效果评估

基于业务绩效目标的要求，应获得适当的运维数据和信息，以持续改进运维。应用系统运维的效果

评估应至少包括：

a)运维保障应用系统对业务的支撑能力；

b)运维能力，指标如系统运行的监控能力、问题诊断能力、解决问题能力、新用户和新功能上线

能力、变更发布能力；

c)运维的质量和安全状况，指标如运维交付能力、系统可用性；

d)用户对运维的感受程度，指标如满意度、投诉比例；

e)支撑发现改进的机会，指标如潜在的问题与优化改进的机会、业务数据风险与创新机会、应用

系统运维能力提升的要求。

12

JT/TXXXX—XXXX

参考文献

[1]GB/T11457信息技术软件工程术语

[2]GB/T19000质量管理体系基础和术语

[3]GB/T22080网络安全技术信息安全管理体系要求

[4]GB/T22239信息安全技术网络安全等级保护基本要求

[5]GB/T24405.2信息技术服务管理第2部分：实践规则

[6]GB/T25000.10系统与软件工程系统与软件质量要求和评价(SQuaRE)第10部分：系统与软

件质量模型

[7]GB/T28827.1信息技术服务运行维护第1部分：通用要求

[8]GB/T28827.2信息技术服务运行维护第2部分：交付规范

[9]GB/T28827.6信息技术服务运行维护第6部分：应用系统服务要求

[10]GB/T33770.1信息技术服务外包第1部分：服务提供方通用要求

[11]GB/T33770.6信息技术服务外包第6部分：服务需求方通用要求

[12]GB/T34960.1信息技术服务治理第1部分：通用要求

[13]GB/T36074.2信息技术服务服务管理第2部分：实施指南

[14]GB/T36074.3信息技术服务服务管理第3部分：技术要求

[15]GB/T37696信息技术服务从业人员能力评价要求

[16]SJ/T11564.4信息技术服务运行维护第4部分：数据中心规范

[17]SJ/T11564.5信息技术服务运行维护第5部分：桌面及外围设备规范

[18]SJ/T11693.1信息技术服务服务管理第1部分：通用要求

[19]ISO/IECDIS20000-1ITServiceManagementandITGovernance

13

交通运输行业标准

国家综合交通运输信息平台

应用系统运维管理规范

（征求意见稿）

编制说明

标准起草组

2025年11月

一、工作简况

(一)任务来源

按照《交通运输部关于下达2025年交通运输标准化计划（第一批）的通知》

（交科技函〔2025〕239号）要求，制定《国家综合交通运输信息平台应用系

统运维管理规范》（计划号：JT2025-30）执行计划，由交通运输信息通信及

导航标准化技术委员会（以下简称“标委会”）提出并归口管理，交通运输部

路网监测与应急处置中心承担主要编制工作。

(二)编制背景

《交通强国建设纲要》和《国家综合立体交通网规划纲要》明确，要加快

构建综合交通大数据中心体系，完善国家综合交通运输信息平台（以下简称国

家信息平台），深化交通公共服务和电子政务发展。《“十四五”推进国家政

务信息化规划》要求，要坚持“大平台、大数据、大系统”一张蓝图绘到底，

深度开发利用政务大数据，发展壮大融合创新大平台，统筹建设协同治理大系

统。2021年交通运输部发布的《数字交通“十四五”发展规划》提出，要坚持

“一个平台”视角，打造综合交通运输“数字大脑”，建设国家信息平台，构

建全国一体化协同综合交通运输信息平台。2022年交通运输部印发了《国家综

合交通运输信息平台实施方案（2022-2025年）》，进一步明确了国家信息平

台的定位、总体框架、主要任务、组织实施方式等内容，为国家信息平台的建

设提供了重要指导。

国家信息平台定位于综合交通运输“大脑”，是交通运输部履行行业监管

和服务职能的统一平台，是实现跨部门、跨层级、跨地区、跨领域互联互通的

中枢，是综合交通运输信息化应用的系统集成，是集中体现行业数字化转型成

效和服务人民群众便捷出行的数字载体。《国家综合交通运输信息平台实施方

案（2022—2025年）》确定了国家信息平台的“1157+N”总体框架，即“一中

心、一基座、五领域、七系统、N节点”。“一中心”：即部级综合交通大数

据中心。有效汇聚综合交通运输各领域数据资源，加强数据资源互联互通水平。

“一基座”：即国家信息平台统一的基础支撑条件。统一建设基础环境、应用

支撑、地图服务、网络安全、标准规范等技术条件，为国家信息平台集成高效

1

运行提供一体化保障能力。“五领域”：即具有纵向联动共建需求的专业应用

领域，主要包括铁路、公路、水路、民航、邮政等五个领域。“七系统”：即

具有横向业务协同需求和统筹建设基础的综合性应用系统。主要包括：调度指

挥、运行监测、行政办公、政务服务、信用监管、综合执法、运输管理等七个

系统。“N节点”：即各地方综合交通运输信息平台和骨干交通运输企业信息

平台。各单位平台在部指导下建设完善，实现与国家信息平台的互联互通，共

同构建全国一体化综合交通大数据中心体系。

随着国家信息平台的一体化建设，系统的更新迭代和新技术的运用也给应

用系统运维保障工作带来了新的变化与发展，待解决的运维保障问题也愈发的

复杂和多变，对应用系统运维技术技能、管理水平和服务意识提出了更高的要

求，因此对国家综合交通运输信息平台的应用系统运维保障工作进行规范管理

迫在眉睫。针对国家综合交通运输信息平台应用系统运维中存在的技术技能、

管理水平和服务意识的规范化，亟需相关标准的支撑。

(三)主要工作过程

1.研究立项阶段

2024年11月～2024年12月，开展标准研究立项工作。在前期需求调研的

基础上，参考相关标准材料，初步编制标准草案，形成申报材料并提交标委会

申报标准立项。

2025年1月，准备标准立项答辩材料，参加标准化主管部门组织的标准立

项评审。

2.起草阶段

2025年5月～2025年9月，标准制修订计划下达后，成立标准起草组；结

合前期工作基础，起草组成员按照任务分工分头开展标准编制工作。与此同时，

起草组向行业内有关单位和相关专家进行咨询，并多次内部讨论，根据收到的

意见及研讨结论形成了标准征求意见稿初稿。

2025年10月，将标准征求意见稿初稿提交标委会秘书处，经标委会秘书

处审核、校对，对相关问题再次修改完善，形成《国家综合交通运输信息平台

应用系统运维管理规范（征求意见稿）》。

2

(四)标准起草单位、主要起草人及其工作内容

本标准起草单位为：交通运输部路网监测与应急处置中心、云南公路联网

收费管理有限公司、云南省交通投资建设集团有限公司、交通运输部科学研究

院、中国交通通信信息中心、北京交科公路勘察设计研究院有限公司、北京安

信天行科技有限公司、山东高速信息集团有限公司、四川智能交通系统管理有

限责任公司等。

本标准的主要起草人及承担的主要工作见表1。

表1主要起草人及任务分工

序号姓名单位主要工作

交通运输部路网监测与应急处负责确定标准编写的总体思路、框架、

1郭晓禹

置中心内容；负责标准第4章编写

交通运输部路网监测与应急处

2陈洁负责标准第5章编写

置中心

交通运输部路网监测与应急处

3杨峰负责标准第6章编写

置中心

交通运输部路网监测与应急处

4高薪负责标准第7章编写

置中心

交通运输部路网监测与应急处

5宋惠娟拟定标准工作计划，参与5.1编写

置中心

交通运输部路网监测与应急处

6赵云芳参与调研和访谈，参与5.2编写

置中心

交通运输部路网监测与应急处

7邓雯参与调研和访谈，参与5.3编写

置中心

云南公路联网收费管理有限公参与调研和访谈，负责标准第8章编

8肖强

司写

云南省交通投资建设集团有限

9段明磊参与调研和访谈，参与5.2的编写

公司

云南公路联网收费管理有限公

10李涛参与调研和访谈，参与5.3的编写

司

11黄莉莉交通运输部科学研究院参与调研和访谈，参与6.1的编写

12李晋中国交通通信信息中心参与调研和访谈，参与6.2的编写

13范维克中国交通通信信息中心参与调研和访谈，参与6.3的编写

北京交科公路勘察设计研究院参与调研和访谈，专家意见收集与修

14何培舟

有限公司改及6.4的编写

3

序号姓名单位主要工作

参与调研和访谈，专家意见收集与修

15彭海龙北京安信天行科技有限公司

改及6.2的编写

参与调研和访谈，专家意见收集与修

16王弘远北京安信天行科技有限公司

改及6.3的编写

参与调研和访谈，专家意见收集与修

17王金亮山东高速信息集团有限公司

改及7.1的编写

参与调研和访谈，专家意见收集与修

18徐明礼山东高速信息集团有限公司

改及7.2的编写

四川智能交通系统管理有限责参与调研和访谈，专家意见收集与修

19何炜

任公司改及7.3的编写

四川智能交通系统管理有限责参与调研和访谈，专家意见收集与修

20黄兴中

任公司改及7.4的编写

二、标准编制原则和确定标准主要内容的依据

(一)标准编制原则

本标准的编制符合以下原则：

1.协调性原则

本标准的编写严格遵循与国家及行业相关标准协调一致性原则，所确定的

技术指标，所提出的概念、准则、性能要求与我国现行的法律、法规、政策及

相关标准相协调；如无国际、国家和行业标准参考的，则调研收集用户需求，

通过验证分析后作为标准内容。

2.适用性原则

研究符合《国家综合交通运输信息平台实施方案（2022—2025年）》及相

关制度规范的国家综合交通运输信息平台应用系统运维管理要求，提出应用系

统运维所需遵守的原则、指标、技术要求等，为开展国家信息平台后续建设工

作提供指导，为保障国家信息平台显示效果提供支撑。制定交通运输行业标准

《国家综合交通运输信息平台应用系统运维管理规范》，在交通运输行业内推

广使用，并为各交通运输行业标准和团体标准提供参考和依据。

3.实用性原则

4

本标准在对行业现状进行充分调研的基础上，坚持实用性为主的原则。调

研国家综合交通运输信息平台及系统开发相关单位的运维情况和运维需求。包

括信息系统基本情况、系统管理软件/平台情况、业务应用软件情况、运行环境

情况、管理制度类文档情况、运维服务情况、应用系统软件处理流程情况、业

务数据流程、云系统运维等内容。根据调研结果进行初步总结，形成运维服务

需求、运维服务要求、运维保障机制、运维服务效果评估等。

(二)确定标准主要内容的依据

1.范围

提出了国家综合交通运输信息平台应用系统运维管理模型和运维服务需求，

规定了国家综合交通运输信息平台应用系统运维服务要求、保障机制以及效果

评估。适用于国家综合交通运输信息平台上运行的应用系统运维的管理。

2.规范性引用文件

规范性引用文件与本标准中的规范性技术要素具有同等效力。在使用本文

件时，除了应遵守本标准的规定外，还应满足“规范性引用文件”中引用的文

件或其条款要求。本标准规范性引用了多项国家和行业标准：

GB/T28827.3信息技术服务运行维护第3部分：应急响应规范

GB/T37376交通运输数字证书格式

JT/T1534国家综合交通运输信息平台视频资源接入技术要求。

3.术语和定义、缩略语

（1）术语和定义

本标准依据《国家综合交通运输信息平台实施方案（2022—2025年）》规

定了应用系统、应用系统管理者的术语定义。

（2）缩略语

为方便应用和理解，下列缩略语适用本标准：

EOP：应急操作流程(EmergencyOperationProcedure)

NTIP：国家综合交通运输信息平台（NationalTransportationInformation

Platform）

SLA：服务级别协议(ServiceLevelAgreement)

5

4.应用系统运维管理模型

参考ISO9001《质量管理体系》系列标准和GB/T22080《网络安全技术信

息安全管理体系要求》，结合GB/T28827《信息技术服务运行维护》系列

标准，规定了NTIP应用系统的运维管理模型包括运维服务需求、运维服务要

求、运维保障机制、运维服务效果评估，见图1。

运维保障机制：人员、过程、技术、资源

运维服务要求（技术、管理）

策划实施

设计阶段交付阶段运

运运维对设计运维对交付维

维服

服的要求的要求务

务对象效

需终止阶段内容运行阶段果

求评

终止要求运维的要求估

改进检查

图1国家综合交通运输信息平台应用系统运维管理模型

5.运维服务需求

5.1运维服务对象，参考GB/T28827.6《信息技术服务运行维护第6

部分：应用系统服务要求》的4.1，规定了服务对象至少应包括：应用和业务数

据、运维数据、安全数据。

5.2运维服务内容，参考GB/T28827.6的7.2，规定了运维服务内容至少应

包括：调研评估、例行操作、响应支持、优化改善。

5.3运维活动，参考GB/T28827.6的4.2，规定了5.3.1运维活动的技术要

6

求和5.3.2运维活动的管理要求。

5.4运维能力，参考GB/T28827.2《信息技术服务运行维护第2部分：

交付规范》的5.3，规定了5.4.1策划、5.4.2实施、5.4.3检查和5.4.4改进。

6.运维服务要求

6.1设计要求，参考GB/T28827.6的第5章，规定了6.1.1设计原则、6.1.2

可监控性设计要求、6.1.3易用性设计要求、6.1.4安全性设计要求和6.1.5可维

护性设计要求。监控运行的关键信息和运行状态，业务调用过程透明、信息可

获取、可输出，并根据监控结果对应用系统运行进行控制。易用性应提供运行

维护的人机界面友好、操作简单、易配置、易部署安装。安全性是应用系统具

有运行维护中的授权类型和授权级别相一致的访问功能，以保护应用系统的数

据。可维护性是为了提高应用系统故障排除、功能性改进、性能性改进、适应

性改进和预防性改进的效果和效率。

6.2交付要求，参考GB/T28827.6的第6章，规定了应用系统的交付要求

包括的所需的相关配置信息，应用软件源代码、应用系统管理权限、文档、维

护人员和相关方责任以及交付内容。

6.3运行维护的要求，参考GB/T28827.6的第7章，规定了6.3.1运行环境

的运行维护和6.3.2数据维护的要求。其中，运行环境主要包括调研评估、例行

操作、响应支持和优化改善。调研评估即对应用软件及其运行环境的调查研究

和分析评价，提出应用系统的运行报告或建议。例行操作即对应用软件及其运

行环境的预定运行维护，以保障应用系统的正常运行。响应支持即对应用软件

及其运行环境的服务请求或故障申报提供即时运行维护，以保障应用系的正常

运行。优化改善即对应用系统的功能和性能进行调优，并满足新的需求。数据

维护的要求包含例行操作、优化改善和评估分析。例行操作即预定运行维护，

确保数据的可用、准确、完整、安全。例行操作包括数据监控、预防性检查、

常