JR T 0079—2013 保险业信息系统运行维护工作规范.pdf

《JR T 0079—2013 保险业信息系统运行维护工作规范.pdf》由会员分享，可在线阅读，更多相关《JR T 0079—2013 保险业信息系统运行维护工作规范.pdf（207页珍藏版）》请在麦多课文档分享上搜索。

1、ICS 03.060 A11 JR 中华人民共和国金融行业标准 JR/T 0079 2013 保险业 信息系统 运行维护 工作规范 Information system operation and maintenance work specification for insurance industry 2013-12 发布 2012-12 实施 中国保险监督管理委员会 发布 JR/T 00792013 I 目 次 前言 . III 引言 . IV 1 范围 . 1 2 规范性引 用文件 . 1 3 术语和定 义 . 1 4 解决流程 . 3 4.1 背景 . 3 4.1.1 总则 . 3 4

2、.1.2 设置 优先级 . 3 4.1.3 替代 方案 . 4 4.2 事件管 理 . 4 4.2.1 总则 . 4 4.2.2 重大 事件 . 4 4.3 问题管 理 . 5 4.3.1 总则 . 5 4.3.2 问题 管理的范围 . 5 4.3.3 启动 问题管理 . 5 4.3.4 已知 错误 . 5 4.3.5 问题 的解决 . 5 4.3.6 沟通 . 5 4.3.7 跟踪 和升级 . 5 4.3.8 事件 和问题记录关闭 . 5 4.3.9 问题 评审 . 6 4.3.10 评 审事项 . 6 4.3.11 问 题预防 . 6 5 控制流程 . 6 5.1 配置管 理 . 6 5.

3、1.1 总则 . 6 5.1.2 配置 管理计划和实施 . 7 5.1.3 配置 识别 . 7 5.1.4 配置 控制 . 8 5.1.5 配置 状态说明和报告 . 8 5.1.6 配置 验证和审计 . 8 5.2 变更管 理 . 9 5.2.1 总则 . 9 JR/T 00792013 II 5.2.2 计划 和实施 . 9 5.2.3 关闭 和评审变更请求 . 9 5.2.4 紧急 变更 . 9 5.2.5 变更 管理报告、分析和措施 . 10 6 发布流程 . 10 6.1 发布管 理过程 . 10 6.1.1 总则 . 10 6.1.2 发布 策略 . 10 6.1.3 发布 和撤销计

4、划 . 10 6.1.4 软件 的开发和获取 . 11 6.1.5 设计 、建立和配置的发布 . 11 6.1.6 发布 验证和接受 . 11 6.1.7 文件 . 11 6.1.8 回滚 、分配和安装 . 12 6.1.9 发布 后处理和回 退 . 12 附录 A （资料 性附录） 保险业信息系统运行维护工作规范参考作业指导书 . 13 A.1 总则 . 13 A.2 作业指 导书 . 13 附录 B （资料 性附录） 保险业信息系统运行维护工作规范参考记录表格文件 . 76 B.1 总则 . 76 B.2 表格文 件 . 76 附录 C （资料 性附录） 保险业信息系统运行维护工作规范参考

5、岗位设置 . 176 C.1 总则 . 176 C.2 岗位属 性 . 176 附录 D （资料 性附录） 保险业信息系统运行维护工作规范参考流程图 . 193 D.1 总则 . 193 D.2 流程图 . 193 附录 E （资料 性附录） 运行维护服务对象和内容 . 199 E.1 总则 . 199 E.2 运行维 护服务对象 . 199 E.3 运行维 护服务内容 . 200 参考文献 . 201 JR/T 00792013 III 前 言 本标准按照GB/T 1.1-2009给出的规则 起草。 本标准由全国金融标准化技术委员会保险分技术委员会提出并归口。 本标准起草单位：中国人民财产保

6、险有限公司、中国太平保险集团公司。 本标准主要起草人：张化群，张立庭，潘多磊，曾光，李晔 ，王新伟，丁先明。 本标准为首次制定。 JR/T 00792013 IV 引 言 信息技术是保险业快速发展的重要支撑。 能否提供优良的信息技术服务， 是影响保险业内外部客户 满意度的重要组成部分， 也是保险机构核心竞争力的重要组成部分。 运行维护服务对于保障保险机构信 息系统的安全稳定运行有至关重要的作用，是信息技术服务的核心部分。 保险业信息系统运行维护工作规范的制订旨在规范保险机构的信息技术运行维护服务的实施。 在保险机构建立了运行维护规范后，通过有效的运行维护服务实施手段，提高运行维护服务实施水平，

7、 保障信息系统的安全稳定运行，从而提高内 外部客户的满意度，提高保险机构的核心竞争力。 本标准定义了保险机构运行维护工作 规范，包括以下主要内容： a) 解决流程： 包括密切相关的事件管理和问题管理两个单独的流程。 事件管理流程主要关注用户 服务的恢复，而问题管理流程则主要关注与识别并消除事件发生的原因； b) 控制流程：主要描述了配置管理和变更管理两个相关方面； c) 发布流程：是确保每一个新发布的所有技术和非技术问题都得到协调解决。 JR/T 00792013 1 保 险 业 信 息 系 统 运 行 维 护 工 作 规范 1 范围 本标准规定了保险业信息系统运行维护工作的要求， 是IT服

8、务管理的一部分， 包括三个与信息系统 运行维护 紧密相关的服务过程，如图1 灰色背 景部分所示： 图1 服务管理流程 本标准适用于在国内从事保险业务的保险机构。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。 凡是注日期的引用文件， 仅所注日期的版本适用于本文 件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 ISO/IEC 20000-1:2005 信 息技术服务管理之规范 （Information technology Service management Part 1: Specification ） ISO/IEC 20000-2:2005 信 息

9、技 术 服 务 管 理 之 实 施 指 南 （Information technology Service management Part 2: Code of practice ） 3 术语和定义 JR/T 00792013 2 下列术语和定义适用于本文件。 3.1 信 息 技 术服务 管 理 information technology service management ，ITSM 信息技术服务提供方通过协调一致的整合实施人员、 流程和信息技术的管理活动， 有效交付信息技 术服务，满足客 户和业务需求的管理活动。 3.2 运行维护 operation and maintenance 采

10、用相关的 技术和方法 ，依据需方 提出的服务 级别要求， 对其所使用 的信息系统 运行环境( 如 基础 环境、软硬件环境等) 、 业务系统等提供的综合服务，服务对象和内容参见 附 录 E 。 3.3 流程 process 用于实现特定目标的一系列有组织的活动。 流程获得一个或多个定义的输入， 然后将它们变成定义 的输出。 流程可以包括角色、 责任、 工具和提供输出所需的管理控制。 流程定义可包括 政策、 标准、 指 南、活动和工作指令。一个流程的输出常常成为另一个流程的输入。 3.4 事件 incident 不属于一项服务的标准操作的任一事态，可导致或会导致服务的中断或服务质量的降低。 注：

11、事件可能包括请求的问题。 ISO/IEC 20000-1:2005，定义2.7 3.5 问题 problem 一个或多个事件的未知的潜在原因。 ISO/IEC 20000-1:2005，定义2.8 3.6 记录 record 阐明所取得的结果或提供所完成活动的证据的文件。 注1：本部分认为文件不同于记录，因为记录的作用是 作为活动的证据而非意图的证据。 注2：记录的例子可包括审核报告、变更请求、事件报告、个人培训记录和传递给客户的清单。 ISO/IEC 20000-1:2005，定义2.9 3.7 变更记录 change record 记录包括受影响配置项的详情及其如何被授权变更所影响。 IS

12、O/IEC 20000-1:2005，定义2.3 3.8 配置项 configuration item ，CI JR/T 00792013 3 处于或将处于配置管理之下的基础设施部件或项。 注：配置项在复杂性、 规模和类型方面变化可能很大， 配置项可以是整个系统， 包括所有的硬 件、 软件和文档， 也 可以是单个模块或很小的硬件部件。 ISO/IEC 20000-1:2005，定义2.4 3.9 配 置 管 理数据 库 configuration management database ，CMDB 数据库包括每个配置项的有关详情和配置项之间重要关系的详情。 ISO/IEC 20000-1:20

13、05，定义2.5 3.10 配置基线 baseline 服务状况或单个配置项在某一时间点的定时点详值。 3.11 发布 release 通过测试且被同时引入现实环境的新配置项和（或）变更的配置项的集合 。 ISO/IEC 20000-1:2005，定义2.10 3.12 变更请求 request for change 在一项服务或基础设施内，用于记录请求变更任一配置项的详情的表单。 ISO/IEC 20000-1:2005，定义2.11 3.13 服务台 service desk 面对客户的完成总量中一大部分支持工作的支持组，是服务提供者与用户直接的单一联系点。 ISO/IEC 20000-1

14、:2005，定义2.12 4 解决流程 4.1 背景 4.1.1 总则 解决流程包括事件管理和问题管理两个子流程。事件和问 题管理是独立流程，虽然它们紧密相关。 事件管理关注的是为用户服务恢复，而问题管理考虑的是识别并消除事件的原因。 4.1.2 设置优先级 运行维护的实施者应该根据优先级确定解决的目标。 优先级的确定应该根据影响和紧急程度。 影响 应该根据对客户业务的实际或潜在损害程度。 紧急程度应该根据问题或事件被发现到业务受损害的时间 间隔。事件或问题解决的时间安排至少应该考虑以下因素： a) 优先级； b) 可用的技能； JR/T 00792013 4 c) 争夺资源的要求； d) 解

15、决方案的效益/ 成本； e) 实施解决方案所需时间。 优先级贯穿于这个服务管理，是事件管理和问题管理的核心。 4.1.3 替代方案 适当时， 问题管理应该建立并维护替代方案， 使得事件管理可以帮助用户工作人员恢复服务。 只有 当成功实施纠正性的变更， 或错误不再存在 （如不再使用该服务） 时， 已知错误才应该被关闭。 问题管 理应该有权访问问题所涉及的业务领域信息。 存放在知识库中的替代方案的信息， 其适用性和有效性应 该予以维护。 4.2 事件管理 4.2.1 总则 目标：尽可能快的恢复商定的提供给业务的服务或响应服务请求。 注1：事件管理过程可能由负责日常与用户联系的服务台提供。 注2：事

16、件管理过程可在尽快恢复生产的前提下适当增加现场保护措施，以便于排除隐患。 事件管理应该是： a) 影响服务或可能影响服务的事件的主动或被动响应过程； b) 关注客户服务的恢复，而不是判断事件原因。 c) 事件管理流程应该包括： d) 接受报修并记录、分配优先级和分类； e) 事件的一线解决或转发； f) 安全问题的考虑； g) 事件跟踪和生命周期管理； h) 事件的验证和关闭； i) 客户的一线联系； j) 事件的升级。 用户可以通过电话、 语音邮件、 来访、 书信、 传真或者电子邮件报告事件， 也可以直接访问事件记 录系统进行事件记录，或者采用自动监控软件报告事件。 服务提供方应该以可检索和

17、分析的方式，记录所有事件。 服务提供方应该与实际受影响或潜在影响的相关人员沟通事件解决进展（或没有进展）。 所有相关活动都应该记录在事件记录中。 事件管理人员可按所授权限访问最新的知识库。 知识库中包括技术专家、 以前的事件、 相关问题和 已知错误、替代方案、检查表等有助于恢复服务的各种信息。 只要可能， 服务提供方应该向客户提供让业务得以持续的方法， 即使只是一个被降级的服务， 例如 禁止已出错的功能。 其目的就是最大限度降低对客户业务活动的影响。 当未找出的原因， 但已有替代方 法的，应该记录详细信息以用于进行中的问题分析或类似事件再次发生。 只有当事件报告用户证实事件已经解决并且服务已经

18、恢复的时候，事件才能正式关闭。 事 件 管 理 作 业 指 导 书 见 附 录 A 中 相 关 作 业 指 导 书 ， 参 考 表 格 见 附 录 B ， 参 考 岗 位 设 置 见 附 录 C ，流程 图见 附 录 D - 图D.1 。 4.2.2 重大事件 JR/T 00792013 5 应该清晰定义什么构成一个重大 事件，以及谁被授权可以对事件或问题处理过程进行变更。 在任何时候所有重大事件都应有一个明确的管理者负责。 任命为重大事件经理的人员应该具有协调和控制事件解决的所有方面的相关授权。 其中包括事件升 级，以及与参与解决的相关各方和受重大事件影响的客户进行沟通。 重大事件处理流程应

19、包括评审，评审将作为服务改进计划的输入。 4.3 问题管理 4.3.1 总则 目标：通过对事件起因的主动识别和分析，以及管理问题的关闭，以最大限度降低对业务的损害。 问 题 管 理 作 业 指 导 书 见 附 录 A 中 相 关 作 业 指 导 书 ， 参 考 表 格 见 附 录 B ， 参 考 岗 位 设 置 见 附 录 C ，流程 图见 附 录 D - 图D.2 。 4.3.2 问题管理的范围 问题管理过程应该调查事件的根本原因。 问题管理应该根据业务要求预防事件或已知错误重复发生或再现。 4.3.3 启动问题管理 应该对事件进行分类，以帮助确定问题原因。 分类参考现有问题和变更。 4.3

20、.4 已知错误 当问题管理调查已经明确事件的根本原因和解决事件方法时，该问题应该被归类为已知错误。 除了在故障时被怀疑的配置项， 所有已知错误还有应该对照受影响的服务或潜在影响的服务加以记 录。 在已导入运行环境的服务中的已知错误信息应该传递给服务管理方， 并连同替代方案记录在知识库 中。已知错误在成功解决后才应该被关闭。 4.3.5 问题的解决 当根本原因得以识别，并对解决方案做出了决策，解决方案应通过变更管理过程来实施。 4.3.6 沟通 替代方法、永久性方案或问题的进展，应该与受影响或要求提供支持的 相关各方沟通。 4.3.7 跟踪和升级 应该跟踪所有问题的进展。所有议题应该升级给合适的

21、相关方。 跟踪 和升级过程应该包括： a) 记录问题生命周期内问题解决责任人的变更； b) 识别违背服务级别目标的事件； c) 让客户和同事了解相关信息，以便他们采取相关合适行动将问题影响降到最低； d) 定义问题的升级点； e) 记录采用的资源和所采取的行动。 4.3.8 事件和问题记录关闭 记录关闭程序应该包括检查以确保： JR/T 00792013 6 a) 解决的信息被准确记录； b) 对原因进行了分类以便分析； c) 适当时，让客户和员工了解解决客户同意的解决方案已经被实施； d) 如果解决方案没有成功或者无法实现，应告知客户； 4.3.9 问题评审 在调查尚未解决的问题、 非常见问

22、题或者影响重大的问题时， 应该进行问题评审。 其目的是寻找过 程的改进计划，防止事件或错误的再次发生。 问题评审通常： a) 依据服务等级评审每个事件的等级和问题的状态； b) 管理评审以强调需要立即采取行动的问题； c) 管理评审以确定并进行趋势分析，以作为其他过程的输入，如用户教育和培训。 4.3.10 评审事项 评审应该包括识别： a) 趋势，例如重复发生的问题和事件、已知错误等； b) 某一特定类型的组件和位置，重复发生问题； c) 由于资源、培训和文档导致的缺陷 ； d) 不符合；如违背标准、方针和法规； e) 计划版本中的已知错误； f) 在解决事件或问题中承诺的人员资源； g)

23、已解决问题或事件的重复发生； 应该记录对服务或问题管理过程的改进，并作为服务改进计划的输入。 相关信息应加入问题管理知识库。 应该对相关文件进行更新，如用户指南和系统文件。 4.3.11 问题预防 主动的问题管理可以促进事件和问题的减少。其中包括提供辅助分析的信息，例如： a) 资产和配置； b) 变更管理； c) 已发布的已知错误，从供应商获得的替代方法； d) 相似问题的历史信息。 问题预防包括对个别事件的预防 （例如某系统 的一个特性反复出现的问题） 到战略决策。 后者要求 较大投入，例如筹建更好的网络，此时问题管理可以合并为可用性管理。 问题预防还包括向客户提供信息， 以便他们将来不再

24、寻求帮助， 例如预防一些由于用户缺乏知识和 培训导致的事件。 5 控制流程 5.1 配置管理 5.1.1 总则 目标：定义并控制服务和基础设施的组件，并维护准确的配置信息。 JR/T 00792013 7 配 置 管 理 作 业 指 导 书 见 附 录 A 中 相 关 作 业 指 导 书 ， 参 考 表 格 见 附 录 B ， 参 考 岗 位 设 置 见 附 录 C ，流程 图见 附 录 D - 图D.5 。 5.1.2 配置管理计划和实施 配 置 管 理 应 结 合 变 更 和 发 布 管 理 进 行 计 划 和 实 施 ， 以 确 保 服 务 提 供 方 可 以 有 效 管 理 其IT 资

25、 产 和 配 置。 准确的配置信息应该为新服务或变更的服务以及系统版本的发布和分发计划和变更控制提供支持。 目的是形成一个综合服务提供方的配置信息过程并包括客户和供应商（必要时）的有效体系。 应该考虑所有重要资产和配置， 并指派管理责任人， 以确保维护合适的保护和控制， 例如在实施前 对变更授权。 控制措施实施的职责可以委托给其他人员， 但管理责任人仍然负有责任。 应该向管理责任人提供履 行职责的必要信息， 如， 进行变更授权时， 可能需要变更的成本、 风险和影响， 以及和实施所需资源等 信息。 基础设施和 （或） 服务应该有更新的配置管理计划， 该计划可能是一个单独文件， 也可能是作为其 它

26、计划文件的一部分。该计划应该包括或描述： a) 范围、目标、方针、标准的角色和责任； b) 定义服务和基础设施的配置项、 控制配置变更、 记录和报告配置项状态以及验 证配置项的完整 性和准确性的配置管理过程； c) 对于可问责、可追溯、可审计的要求，如来自安全、法律、法规或业务目的的要求； d) 配置控制（访问、保护、版本、 开 发、版本控制）； e) 识别、 记录和管理两个或多个组织的公共边界的配置项及信息的接口控制过程， 如系统接口和 版本； f) 资源的计划和确定，以便将资产和配置置于控制之下，并维持配置管理系统，如培训； g) 对进行配置管理的供应商和分包商的管理； 注：可采取一定的自

27、动化手段，以确保流程不会无效、错误百出、甚至失效。 5.1.3 配置识别 所有配置项应该被唯一标识， 并定义 描述其功 能和 物理特性的属性。 信息应是相关， 并可审计的。 应该采用合适的标记或其它识别方法，并将其记录在配置管理数据库中。应该 利用已建立的选择准则来管理配置项，并应该包括： a) 信息系统、 软件 （包括第三方软件） 和相关系统文件的所有议题和版本， 如， 要 求、 规范、 设 计、测试报告、版本文件； b) 为适用的环境、标准硬件架构和版本建立配置基准或架构的描述； c) 主拷贝和电子资料库，如最终软件库； d) 使用的配置管理包或工具； e) 许可证； f) 安全组件，如防

28、火墙； g) 出于财务管理和业务原因需要跟踪的物理资产，如安全磁盘介质、设备； h) 服务相关文件，如 SLA 、 程序； i) 服务支持设施，例如机房电源； j) 配置项之间的关系和依赖性； 注：其它可视为配置项的包括： a) 其它文档； JR/T 00792013 8 b) 其它资产； c) 其它设施，例如站点； d) 业务单元； e) 人员。 应该识别配置项之间适当的关系和依赖性，以便提供必要的控制级别。 如果需要跟踪配置项，那么应该确保从需求文档到版本发布记录的整个生命周期内都是可追踪的， 如实施可追溯矩阵。 5.1.4 配置控制 配置过程应该确保只有经过授权且可识别的配置项才被接受，

29、并记录从接受到销毁的全过程。 没有适当的 控制文件（ 如经过批准 的变更请 求 、更新的版 本信息）， 不能添加、 修改、替换/ 删除 配置项。 为保护系统、服务和基础设施的完整性，配置项应该保存在一个合适的安全环境： a) 保护其不受未经授权的访问、变更或破坏，例如病毒； b) 提供灾难后的恢复方法； c) 允许对受控备份的受控恢复，如软件。 5.1.5 配置状态说明和报告 应该维护当前准确的配置记录，以反映配置项状态、位置和版本的变更。 状态清单应该提供配置项在整个生命周期中的当前和历史数据。 应该利用多种状态来描述， 使得配 置项可以被跟踪，如订购、接收、验收测试、上线、变更中、撤回、销

30、毁等。 配置项信息应该持续更新，并可以被已定义配置项的计划、决策和变更管理所用。 如果需要， 用户、 客户、 供 应商和合作方应该可以访问配置信息， 以协助其制定计划和决策。 例如， 外部服务提供商可以提供配置信息给客户和其他相关各方，以支持其他服务管理过程的端到端服务。 配置项管理报告应该提供给所有相关各方。报告应该包括配置项的识别和状态、版本和相关文件。 报告应该包括： a) 配置项最新版本； b) 配置项的位置和软件主版本的位置； c) 相互依赖关系； d) 版本历史； e) 配置项状态及构成： 服务配置或系统； 变更、基准、编译或版本； 版本号或变量。 5.1.6 配置验证和审计 应该

31、计划配置验证和审计过程（包括物理的和功能性的），并检查是否有合适的过程和资源： a) 保护物理配置和组织的知识资产； b) 确保服务提供方控制其配置、主拷贝和许可证； c) 确保配置信息是准确、可控和可见的； d) 确保变更、版本、系统或环境符合其合同约定或指定的要求，而且配置记录是准确的。 应该定期进 行配置审计 ，此外还应 该在重大变 更前后、灾 难后和随机 的不定期进 行审计。 缺 陷或 不符之处应该被记录、评估和改进，反馈意见应提供给相关各方和服务改进计划。 JR/T 00792013 9 注：通常存在两种类型的配置审计： a) 功能性配置审计：了解配置项是否达到配置文档事先确定的性能

32、和功能特性的正式检查； b) 物理配置审计：了解配置项的 当前 编译版/ 产品 版 是否与其 产品配置文件相符的正式检查。 5.2 变更管理 5.2.1 总则 目标：确保以受控的方式去评估、批准、实施和评审所有的变更。 变 更 管 理 作 业 指 导 书 见 附 录 A 中 相 关 作 业 指 导 书 ， 参 考 表 格 见 附 录 B ， 参 考 岗 位 设 置 见 附 录 C ，流程 图见 附 录 D - 图D.3 。 5.2.2 计划和实施 变更管理过程和程序应该确保： a) 在文件中清晰定义变更的范围； b) 只有为业务带来利益的变更才能被认可，例如商业的、法律的、规章的、法令的； c

33、) 根据优先级和风险为变更安排进度； d) 配置的变更可以在实施过程中验证； e) 对变更的时间进行监视，如果需要应该进行改进； f) 能够证实，变更是如何： 发起、记录和分类的（参考发起变更的文件）； 评估变更对服务、客户和版本发布计划 的影响、紧急程度、成本、收益和风险； 未成功时的恢复或补救； 归档，如与受影响的配置项相关的变更请求、实施后更新的版本号和版本发布计划； 变更授权人根据变更的类型、规模和风险对变更请求的接受或拒绝； 由所变更组件的责任团队内的指定责任人负责实施； 测试、验证和签署； 关闭和评审； 时间安排、监视和报告； 适当时，与事件、问题、其它变更和配置项记录联系。 变更

34、的状态和计划的实施日期应该作为变更和版本发布日程安排的依据。 日程安排信息应该提供给受变影响的相关人员。 如果可能导致正常服务时间内的服务受损，应该在 变更实施前获得受影响人员的同意。 5.2.3 关闭和评审变更请求 所有变更在变更实施后， 都应该进行进行成功或失败的评审， 并记录所有改进措施。 重大变更实施 后应该进行评审，以检查： a) 变更是否满足目标； b) 客户对结果是否满意； c) 没有预期之外的负面影响； 应该记录所有不符合，并采取相应改进措施。 在评审变更管理过程中，所识别的任何缺陷和弱点，应该作为服务改进计划的输入。 5.2.4 紧急变更 JR/T 00792013 10 有

35、时可能需要紧急变更， 应该尽可能遵循变更流程， 某些细节可以事后记录。 当紧急变更流程跳过 其它变更管理要求时，变更应该尽可能满足适用可行的要 求。 实施人员应该判断紧急变更的必要性，并在变更后评审，以确保是紧急变更。 5.2.5 变更管理报告、分析和措施 应该定期分析变更记录， 以检测不断提高的变更级别、 频繁再现的类型、 呈现的趋势和其它相关信 息。应该记录变更分析的结果和结论，并采取相应行动。 6 发布流程 6.1 发布管理过程 6.1.1 总则 目标：交付、分发和跟踪导入到运作环境中的一个或多个变更。 发布管理应该协调服务提供方、多个供应商和业务方，以计划在分布式的环境中提交版本。 良好的计划和管理是版本打包、 成功分发以及管理其对业务和IT的相关 影响和风险的基础。 应结合 业务，对受影响的信息系统、基础设施、服务和文档的版本发布进行计划。 发布的版本中应该包括文件的所有相关更新，如业务过程、支持文档和服务级别协议。 所有对授权变更造成影响的新的或经过改动的配置项都应该被评估。 服务提供方应该确保已经考虑版本发布的技术或非技术两个方面。 版本项应该可跟踪并防止修改。只有经过适当测试和认可的版本才应该被导入运行环境。 发 布 管 理 作 业 指 导 书 见 附 录 A 中 相 关 作 业 指 导 书 ， 参 考 表 格 见 附 录 B ， 参