GB/T 28827.6-2019 信息技术服务 运行维护 第6部分：应用系统服务要求

　　ICS 35 . 080 L 77

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 28827 . 6—2019

　　信息技术服务 运行维护

　　第 6 部分：应用系统服务要求

　　Informationtechnologyservice—operationsandmaintenance—

　　part6：Applicationsystem servicerequirements

　　2019-08-30 发布 2020-03-01 实施

　　国家市场监督管理总局中国国家标准化管理委员会

　　发

　　布

　　GB/T 28827 . 6—2019

　　GB/T 28827 . 6—2019

　　前 言

　　GB/T 28827《信息技术服务 运行维护》分为 6 个部分：

　　— 第 1 部分：通用要求;

　　— 第 2 部分：交付规范;

　　— 第 3 部分：应急响应规范;

　　— 第 4 部分：数据中心服务要求;

　　— 第 5 部分：桌面及外围设备服务要求;

　　— 第 6 部分：应用系统服务要求。

　　本部分为 GB/T 28827 的第 6 部分。

　　本部分按照 GB/T 1 . 1—2009 给出的规则起草。

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

　　本部分由全国信息技术标准化技术委员会(SAC/TC 28)提出并归口 。

　　本部分起草单位： 四川久远银海软件股份有限公司、成都市人力资源社会保障信息中心、中国电子技术标准化研究院、厦门盈趣科技股份有限公司、中平信息技术有限责任公司、北京中科金财科技股份有限公司、北京华胜天成科技股份有限公司、大连华信计算机技术股份有限公司、北京信城通数码科技有限公司、浪潮软件集团有限公司、北京蓝海讯通科技股份有限公司、北京华宇信息技术有限公司、昆明东电科技有限公司、新疆惠文网络信息技术有限公司、北京华创方舟科技股份有限公司、神州数码系统集成服务有限公司、四川三海世纪信息技术有限公司、广东电网有限责任公司佛山供电局、河南省国土资源电子政务中心、北京神州泰岳软件股份有限公司、广州南天电脑系统有限公司、北京银信长远科技股份有限公司、四川易诚智讯科技有限公司、北京易服务信息技术有限公司、金税信息技术服务股份有限公司、上海翰纬信息科技有限公司、云南电网有限责任公司信息中心、北京京天威科技发展有限公司、新开普电子股份有限公司。

　　本部分主要起草人：孙佩、张树玲、岳彩云、周平、刘宏、许晓荣、秦佩君、张旭、张宏伟、唐百惠、盛红胜、詹开明、乔登俭、赵世宁、叶林松、黄桂波、何大斌、蒋毅、李刚、胡艳、沈磊、崔勇、潘飞、邱健、汤维、陈平、梁坚、宋莹、王庆磊、白璐、吴磊、王晶、马洪杰、范勇、刘曜、叶娟娟、赵亮、胡静、张军、王铮、熊健淞、陈宏峰、吴玮、钏涛、袁胜兵、刘瑞慧、赵玉霞。

　　GB/T 28827 . 6—2019

　　信息技术服务 运行维护

　　第 6 部分：应用系统服务要求

　　1 范围

　　GB/T 28827 的本部分提出了应用系统运行维护服务模型，规定了运行维护对应用系统设计、交付、运行、终止和评价的要求。

　　本部分适用于应用系统运行维护相关方。

　　2 规范性引用文件

　　下列文件对于本文件的应用是必不可少的，凡是注 日期的引用文件，仅注 日期的版本适用于本文件 。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

　　GB/T

　　GB/T

　　GB/T

　　28827 .1—2012 28827 .2—2012

　　28827 .3—2012

　　信息技术服务

　　信息技术服务

　　信息技术服务

　　运行维护 第 1 部分：通用要求

　　运行维护 第 2 部分：交付规范

　　运行维护 第 3 部分：应急响应规范

　　3 术语和定义

　　GB/T 28827 . 1—2012、GB/T 28827 . 2—2012、GB/T 28827 . 3—2012 界定的以及下列术语和定义适用于本文件。

　　3.1

　　应用系统 applicationsystem

　　在约定的业务环境下，用于实现用户特定需求的应用软件及其运行的软环境和承载业务直接关联的数据。

　　注：应用软件运行的软环境，包括中间件、数据库、操作系统等。

　　3.2

　　应用软件 applicationsoftware

　　设计用于实现用户的特定需要而非计算机本身问题的软件。

　　注 1 ：例如，人力资源管理软件、客户关系管理软件等。

　　注 2：改写 GB/T 11457—2006,定义 2 . 71 。

　　3.3

　　安全性 security

　　对应用系统进行的保护，以防止其受到意外的或蓄意的存取、使用、修改、毁坏或泄密。

　　[GB/T 11457—2006,定义 2 . 1420]

　　3.4

　　易用性 usability

　　应用系统在指定的使用环境中，为指定的目标，在有效性、效率和满意度特性方面可为指定用户使用的程度。

　　注：改写 GB/T 25000 . 10—2016 ,4 . 3 . 2 . 4 。

　　GB/T 28827 . 6—2019

　　3.5

　　可维护性 maintainability

　　应用系统能修改以排除故障、改进性能或其他属性或适应变更了的环境的容易程度。

　　[GB/T 11457—2006,定义 2 . 903]

　　3.6

　　用户满意 customersatisfaction

　　用户对其期望已被满足程度的感受。

　　注：改写 GB/T 19000—2016 , 3 . 9 . 2 。

　　4 应用系统运行维护服务模型

　　4 . 1 概述

　　应用系统的运行维护服务模型包括运行维护对象、运行维护要求和运行维护评价要求，如图 1所示。

　　图 1 应用系统运行维护服务模型

　　应用系统运行维护对象包括应用软件及其运行软环境和数据。 组织应按照运行维护要求，针对运行维护对象实施运行维护活动，运行维护活动涉及应用系统的设计阶段、交付阶段、运行阶段、终止阶段 。组织应按照运行维护评价要求对运行维护进行评价。

　　4 . 2 运行维护活动

　　包括：

　　a) 识别运行维护相关方，建立运行维护服务机制和协同机制，确保应用系统运行维护的权责分明并保持一致。

　　b ) 根据运行维护服务需求，针对应用系统的运行维护进行策划，策划时应：

　　1) 明确运行维护服务级别协议要求;

　　2) 界定运行维护要求的业务环境;

　　3) 适用时，考虑数据维护和可持续交付要求;

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

　　GB/T 28827 . 6—2019

　　c) 组织应依据策划实施运行维护活动，实现应用系统运行维护的目标。 实施中应：

　　1) 进行知识管理，收集、积累、共享、使用与运行维护相关的知识;

　　2) 实施培训，策划并实施应用软件的业务流程培训、功能培训、操作培训等;

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

　　d) 评价应用系统的运行维护，以确保应用系统可用、安全、稳定和可靠，并满足业务的需要。

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

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

　　2) 工具选择应考虑自动化的程度，以便实现运行维护的高效和智能;

　　3) 工具得到维护，以确保持续适合其用途。

　　5 对应用系统设计的要求

　　5 . 1 概述

　　应用系统的设计应满足应用系统的可监控性、易用性、安全性和可维护性，确保应用系统的有效运行维护。 适用时，应用系统的设计应适应需求的快速变更，并支持应用系统变更发布的持续交付。

　　5 . 2 可监控性

　　应用系统应能监控运行的关键信息和运行状态，业务调用过程透明、信息可获取、可输出，并根据监控结果对应用系统运行进行控制。 设计要求应包括但不限于：

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

　　b ) 监控配置管理实时信息，如实例清单、接口清单、功能清单等。

　　c) 监控应用系统运行稳定性，如应用软件的进程、服务、运行日志、关键业务功能等。

　　d) 监控应用系统的业务质量，如登录量、处理量、积压量、错误量、业务处理状态等。

　　e) 适用时 ：

　　1) 提供主动监控，包括主动巡查监控点、主动发现问题、主动告警等;

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

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

　　5 . 3 易用性

　　应用系统设计应提供运行维护的人机界面友好、操作简单、易配置、易部署安装。 设计要求应包括但不限于：

　　a) 运行维护角色划分清晰、职责明确;

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

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

　　d) 运行维护数据便于提取;

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

　　5 . 4 安全性

　　应用系统应具有运行维护中的授权类型和授权级别相一致的访问功能，以保护应用系统的数据安全 。设计要求应包括但不限于：

　　a) 管理运行维护操作人员的角色和权限;

　　b ) 主动防御或抑制运行维护未授权操作;

　　c) 具有确保数据安全及传输过程的安全机制;

　　GB/T 28827 . 6—2019

　　d) 提供多种 日志。

　　5 . 5 可维护性

　　应用系统的可维护性是为了提高应用系统故障排除、功能性改进、性能性改进、适应性改进和预防性改进的效果和效率。 设计要求应包括但不限于：

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

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

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

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

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

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

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

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

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

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

　　6 对应用系统交付的要求

　　对应用系统的交付要求应包括但不限于：

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

　　b ) 应用系统管理权限设置准确性得到验证;

　　c) 应用系统文档规范、齐备，隐私数据已得到保护;

　　d) 应对应用系统运行维护人员进行培训，确保其所需能力得到验证;

　　e) 提供运行维护技术支持的相关方责任明确;

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

　　g) 对应用系统的安全性进行评估，包括识别技术风险、漏洞扫描等，必要时对应用系统实施加固。

　　7 应用系统运行维护的要求

　　7 . 1 概述

　　应用系统运行维护要求包括应用软件及其运行软环境的运行维护、数据维护的要求及应用系统迁移要求。

　　7 . 2 应用软件及其运行软环境的运行维护要求

　　7 . 2 . 1 调研评估

　　调研评估即对应用软件及其运行环境的调查研究和分析评价，提出应用系统的运行报告或建议。调研评估包括应用系统组成要素的构成分解、关联关系分析和应用系统的维护性分析。 应满足下列要求但不限于：

　　a) 应用系统组成要素的构成分解应根据业务流程和应用系统架构设计，层次化分解应用系统，识别关键业务点和核心业务系统;

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

　　GB/T 28827 . 6—2019

　　关系等;

　　c) 应用系统的维护性分析，包括应用系统的可监控性、应用系统的易用性、应用系统的安全性、应用系统的可维护性，明确应用系统运行方式、组成要素及运行维护特点。

　　7 . 2 . 2 例行操作

　　例行操作即对应用软件及其运行环境的预定运行维护，以保障应用系统的正常运行。 例行操作包括应用系统运行的监控指标体系设计、应用系统运行的监控、客户回访、问题分析。 应满足下列要求但不限于：

　　a) 应用系统运行的监控指标体系设计包括识别应用系统运行监控点，建立监控指标，以支撑实施监控和预防性检查;

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

　　c) 客户回访：调查客户对运行维护的满意度及改进建议等;

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

　　7 . 2 . 3 响应支持

　　响应支持即对应用软件及其运行环境的服务请求或故障申报提供即时运行维护，以保障应用系统的正常运行。 响应支持包括服务受理、非故障请求处理、故障诊断定位、解决方案制定、故障处理、新用户和新功能上线、应急响应。 应满足下列要求但不限于：

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

　　b ) 非故障请求处理：按服务级别协议分类处理;

　　c) 故障诊断定位：排查、诊断定位故障;

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

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

　　f) 新用户和新功能上线：在新用户、新系统功能上线前、上线中、上线后的服务工作，内容包括配置用户及用户权限、数据初始化、安全性检查和功能使用培训等;

　　g) 应急响应：针对应用系统故障影响范围大且不能在业务连续性规定要求内解决所采取的措施，内容包括应急组织架构确定、应急预案编制、应急演练、应急处置和应急回顾。 应急响应具体要求见 GB/T 28827 . 3—2012 。

　　7 . 2 . 4 优化改善

　　优化改善即对应用系统的功能和性能进行调优，并满足新的需求。 优化改善包括功能性改进、性能优化改进、适应性改进、预防性改进。 应满足下列要求但不限于：

　　a) 识别优化改善的机会，应考虑：

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

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

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

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

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

　　b ) 功能性改进，包括应用软件的功能缺陷修复、满足业务需求变化(如流程改造、政策适应性改造等)而对应用软件功能的修改、完善和新增开发。

　　c) 性能优化改进，包括因应用软件性能问题而对其功能的修改和完善，包括应用消息队列、共享内存优化，应用服务能力优化等;对应用软件运行软环境(中间件、数据库、操作系统等)实施调优、升级或扩容等。

　　GB/T 28827 . 6—2019

　　d) 适应性改进，包括应用软件因适应变化对其功能的修改和完善;对应用软件运行软环境(中间件、数据库、操作系统等)的适应性实施调整等。

　　e) 预防性改进，包括应用软件可能存在某种威胁或风险而对其件功能的修改和完善;对应用软件运行软环境(中间件、数据库、操作系统等)的脆弱点实施改进等。

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

　　7 . 2 . 5 变更发布

　　管理、控制变更的过程，通过变更有序实施，确保变更的成功导入。 变更发布包括变更请求响应，变更评估，变更开发，制定发布计划、制作发布包、并实施发布，配置信息更新，应用系统性能监控和回顾总结 。应满足下列要求但不限于：

　　a) 变更请求响应来源于响应支持和优化改善，明确变更 目 的、内容和要求，满足需求变化的变更请求已得到用户确认。

　　b ) 变更评估：评估变更的影响范围、成本、风险和合理性，决定是否接受变更请求。

　　c) 变更开发需要获得授权才能执行。

　　d) 制定发布计划、制作发布包并实施发布，对发布结果进行确认。 发布失败时执行回退。

　　e) 配置信息更新：检查整理所有发布信息，更新配置信息。

　　f) 应用系统性能监控：变更发布后监控应用系统性能。

　　g) 回顾总结：回顾和总结变更发布过程，以持续改进。

　　注：变更与发布可考虑持续交付。

　　7 . 3 数据的运行维护要求

　　7 . 3 . 1 例行操作

　　例行操作即预定运行维护，确保数据的可用、准确、完整、安全。 例行操作包括数据监控、预防性检查、常规检查。 应满足下列要求但不限于：

　　a) 数据监控：制定监控策略，依据业务规则设置告警，对应用软件功能模块各项异常操作告警，保证数据的完整性、准确性;

　　b ) 预防性检查：针对与应用软件承载业务直接关联的数据(包括初始数据、基础数据、业务数据、配置数据、报表数据和授权数据等)，建立授权及一致性的标准和规则，依据标准和规则检查数据之间的一致性、符合性和安全性;

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

　　7 . 3 . 2 响应支持

　　响应支持提供即时运行维护，以确保数据的可用性、准确性、完整性。 响应支持包括数据问题处理、服务请求处理和应急响应。 应满足下列要求但不限于：

　　a) 数据问题处理：针对数据问题(包括数据错误、数据丢失、数据冗余和数据截断等)进行处理，检查和测试数据的完整性、准确性，并在测试环境正进行验证;

　　b ) 服务请求处理：确定服务协议，按数据授权规定提供数据服务(包括数据提取、数据加工、数据质量清理、数据查询统计分析、数据挖掘、数据脱敏、特殊数据维护、回退数据维护、数据迁移、数据备份等);

　　c) 应急响应要求，见 7 . 2 . 3 g) 。

　　7 . 3 . 3 优化改善

　　优化改善即改善数据质量，满足业务需求。 优化改善包括诊断分析、解决和改进。 应满足下列要求

　　GB/T 28827 . 6—2019

　　但不限于：

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

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

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

　　7 . 3 . 4 评估分析

　　评估分析是评估和分析业务数据，给出业务数据质量报告或数据运行维护改进建议，保证数据对业务的有效支持。 评估分析包括数据质量评估、数据修改影响评估、数据规范评估、业务数据分析和应用软件变更对数据影响的评估。 应满足下列要求但不限于：

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

　　b ) 数据修改影响评估，包括业务参数修改的影响评估、数据字典修改的影响评估、基础数据修改的影响评估和业务数据修改的影响评估;

　　c) 数据规范评估，包括基础数据共同遵守规则和命名的评估、业务场景对应业务类型数据的规则评估和业务关键数据应遵循的规则评估;

　　d) 业务数据分析，包括面向业务重点支撑运营和战略需求的数据分析和面向预测重点支撑业态发展趋势的数据分析;

　　e) 应用软件变更对数据影响的评估，包括业务扩展、功能扩展等应用软件变更引起对数据完整性、一致性的评估，以及应用系统升级、变更、迁移等对数据完整性、一致性的评估。

　　7 . 4 应用系统迁移要求

　　应用系统迁移应确保过程有效、应用系统迁移稳定。 迁移要求应包括但不限于：

　　a) 应对迁移执行策划，制定迁移计划，并将其形成文档并实施。 该策划活动应让用户参与。 该计划应包括：

　　1) 迁移的需求分析和定义;

　　2) 迁移工具的开发;

　　3) 应用系统和数据的变化;

　　4) 迁移的执行;

　　5) 未来对原环境的支持。

　　b ) 应将迁移计划和活动通知用户，通知应包括：

　　1) 不再支持原环境的理由说明;

　　2) 对新环境及其可用 日期的描述;

　　3) 一旦原环境的支持取消，应描述其他可用的支持方案。

　　c) 原环境和新环境可以并行运行，以便平稳转移到新环境。 在此期间，应按照服务级别协议的规定提供必要的培训。

　　d) 当预定的迁移到来时，应通知所有相关方。 所有相关原环境的文档、日志等应归档。

　　e) 迁移后应进行运行评审，以评估迁移对新环境的影响。

　　f) 根据服务级别协议关于数据保护和审核要求，原环境使用的或与原环境相关的数据应是可访问的。

　　8 应用系统终止要求

　　应用系统终止要求应包括但不限于：

　　a) 制定终止计划，以撤销运行和维护组织的支持，并将其形成文档。 策划活动应让用户参与。 该

　　GB/T 28827 . 6—2019

　　计划应涉及下述各项：

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

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

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

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

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

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

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

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

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

　　c) 终止应用系统和新应用系统应并行运行，以便平稳过渡到新系统。 在此期间，应按照服务级别协议的规定为用户提供培训;

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

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

　　9 运行维护评价要求

　　基于业务绩效目标的要求，应获得适当的运行维护数据和信息，以持续改进运行维护。 应用系统运行维护的评价要求应包括但不限于：

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

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

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

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

　　e) 支撑发现改进的机会，指标如潜在的问题与优化改进的机会、业务数据风险与创新机会、应用系统运行维护能力提升的要求。

　　GB/T 28827 . 6—2019

　　参 考 文 献

　　[1] GB/T 11457—2006 信息技术 软件工程术语

　　[2] GB/T 19000—2016 质量管理体系 基础和术语

　　[3] GB/T 25000.10—2016 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第 10部分：系统与软件质量模型

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

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