保险业信息系统运行维护工作规范

1、ICS03.060A11JR中华人民共和国金融行业标准JR/T 00792013保险业信息系统运行维护工作规范Information system operation and maintenance work specification for insurance industry2013-12发布 2012-12实施中国保险监督管理委员会发布JR/T 00792013目次前言III引言IV1范围12规范性引用文件13术语和定义14解决流程34.1背景34.1.1总则34.1.2设置优先级34.1.3替代方案44.2事件管理44.2.1总则44.2.2重大事件44.3问题管理54.3.1总则5

2、4.3.2问题管理的范围54.3.3启动问题管理54.3.4已知错误54.3.5问题的解决54.3.6沟通54.3.7跟踪和升级54.3.8事件和问题记录关闭54.3.9问题评审64.3.10评审事项64.3.11问题预防65控制流程65.1配置管理65.1.1总则65.1.2配置管理计划和实施75.1.3配置识别75.1.4配置控制85.1.5配置状态说明和报告85.1.6配置验证和审计85.2变更管理95.2.1总则95.2.2计划和实施95.2.3关闭和评审变更请求95.2.4紧急变更95.2.5变更管理报告、分析和措施106发布流程106.1发布管理过程106.1.1总则106.1.2

3、发布策略106.1.3发布和撤销计划106.1.4软件的开发和获取116.1.5设计、建立和配置的发布116.1.6发布验证和接受116.1.7文件116.1.8回滚、分配和安装126.1.9发布后处理和回退12附录A（资料性附录）保险业信息系统运行维护工作规范参考作业指导书13A.1总则13A.2作业指导书13附录B（资料性附录）保险业信息系统运行维护工作规范参考记录表格文件76B.1总则76B.2表格文件76附录C（资料性附录）保险业信息系统运行维护工作规范参考岗位设置176C.1总则176C.2岗位属性176附录D（资料性附录）保险业信息系统运行维护工作规范参考流程图193D.1总则19

4、3D.2流程图193附录E（资料性附录）运行维护服务对象和内容199E.1总则199E.2运行维护服务对象199E.3运行维护服务内容200参考文献201前言本标准按照GB/T 1.1-2009给出的规则起草。本标准由全国金融标准化技术委员会保险分技术委员会提出并归口。本标准起草单位：中国人民财产保险有限公司、中国太平保险集团公司。本标准主要起草人：张化群，张立庭，潘多磊，曾光，李晔，王新伟，丁先明。本标准为首次制定。引言信息技术是保险业快速发展的重要支撑。能否提供优良的信息技术服务，是影响保险业内外部客户满意度的重要组成部分，也是保险机构核心竞争力的重要组成部分。运行维护服务对于保障保险机构

5、信息系统的安全稳定运行有至关重要的作用，是信息技术服务的核心部分。保险业信息系统运行维护工作规范的制订旨在规范保险机构的信息技术运行维护服务的实施。在保险机构建立了运行维护规范后，通过有效的运行维护服务实施手段，提高运行维护服务实施水平，保障信息系统的安全稳定运行，从而提高内外部客户的满意度，提高保险机构的核心竞争力。本标准定义了保险机构运行维护工作规范，包括以下主要内容：a) 解决流程：包括密切相关的事件管理和问题管理两个单独的流程。事件管理流程主要关注用户服务的恢复，而问题管理流程则主要关注与识别并消除事件发生的原因；b) 控制流程：主要描述了配置管理和变更管理两个相关方面；c) 发布流程

6、：是确保每一个新发布的所有技术和非技术问题都得到协调解决。201保险业信息系统运行维护工作规范1 范围本标准规定了保险业信息系统运行维护工作的要求，是IT服务管理的一部分，包括三个与信息系统运行维护紧密相关的服务过程，如图1灰色背景部分所示：图1 服务管理流程本标准适用于在国内从事保险业务的保险机构。2 规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。ISO/IEC 20000-1:2005 信息技术服务管理之规范（Information technology Servi

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

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

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

10、iguration item，CI处于或将处于配置管理之下的基础设施部件或项。注： 配置项在复杂性、规模和类型方面变化可能很大，配置项可以是整个系统，包括所有的硬件、软件和文档，也可以是单个模块或很小的硬件部件。ISO/IEC 20000-1:2005，定义2.43.9配置管理数据库 configuration management database，CMDB数据库包括每个配置项的有关详情和配置项之间重要关系的详情。ISO/IEC 20000-1:2005，定义2.53.10配置基线 baseline服务状况或单个配置项在某一时间点的定时点详值。3.11发布 release通过测试且被同时引入

11、现实环境的新配置项和（或）变更的配置项的集合。ISO/IEC 20000-1:2005，定义2.103.12变更请求 request for change在一项服务或基础设施内，用于记录请求变更任一配置项的详情的表单。ISO/IEC 20000-1:2005，定义2.113.13服务台 service desk面对客户的完成总量中一大部分支持工作的支持组，是服务提供者与用户直接的单一联系点。ISO/IEC 20000-1:2005，定义2.124 解决流程 4.1 背景 4.1.1 总则解决流程包括事件管理和问题管理两个子流程。事件和问题管理是独立流程，虽然它们紧密相关。事件管理关注的是为用户

12、服务恢复，而问题管理考虑的是识别并消除事件的原因。 4.1.2 设置优先级 运行维护的实施者应该根据优先级确定解决的目标。优先级的确定应该根据影响和紧急程度。影响应该根据对客户业务的实际或潜在损害程度。紧急程度应该根据问题或事件被发现到业务受损害的时间间隔。事件或问题解决的时间安排至少应该考虑以下因素： a) 优先级； b) 可用的技能； c) 争夺资源的要求； d) 解决方案的效益/成本； e) 实施解决方案所需时间。 优先级贯穿于这个服务管理，是事件管理和问题管理的核心。4.1.3 替代方案适当时，问题管理应该建立并维护替代方案，使得事件管理可以帮助用户工作人员恢复服务。只有当成功实施纠正

13、性的变更，或错误不再存在（如不再使用该服务）时，已知错误才应该被关闭。问题管理应该有权访问问题所涉及的业务领域信息。存放在知识库中的替代方案的信息，其适用性和有效性应该予以维护。4.2 事件管理 4.2.1 总则 目标：尽可能快的恢复商定的提供给业务的服务或响应服务请求。 注1： 事件管理过程可能由负责日常与用户联系的服务台提供。 注2： 事件管理过程可在尽快恢复生产的前提下适当增加现场保护措施，以便于排除隐患。 事件管理应该是：a) 影响服务或可能影响服务的事件的主动或被动响应过程； b) 关注客户服务的恢复，而不是判断事件原因。 c) 事件管理流程应该包括： d) 接受报修并记录、分配优先

14、级和分类； e) 事件的一线解决或转发； f) 安全问题的考虑； g) 事件跟踪和生命周期管理；h) 事件的验证和关闭； i) 客户的一线联系； j) 事件的升级。用户可以通过电话、语音邮件、来访、书信、传真或者电子邮件报告事件，也可以直接访问事件记录系统进行事件记录，或者采用自动监控软件报告事件。服务提供方应该以可检索和分析的方式，记录所有事件。服务提供方应该与实际受影响或潜在影响的相关人员沟通事件解决进展（或没有进展）。所有相关活动都应该记录在事件记录中。事件管理人员可按所授权限访问最新的知识库。知识库中包括技术专家、以前的事件、相关问题和已知错误、替代方案、检查表等有助于恢复服务的各种信

15、息。只要可能，服务提供方应该向客户提供让业务得以持续的方法，即使只是一个被降级的服务，例如禁止已出错的功能。其目的就是最大限度降低对客户业务活动的影响。当未找出的原因，但已有替代方法的，应该记录详细信息以用于进行中的问题分析或类似事件再次发生。只有当事件报告用户证实事件已经解决并且服务已经恢复的时候，事件才能正式关闭。 事件管理作业指导书见附录A中相关作业指导书，参考表格见附录B，参考岗位设置见附录C，流程图见附录D -图D.1。4.2.2 重大事件 应该清晰定义什么构成一个重大事件，以及谁被授权可以对事件或问题处理过程进行变更。 在任何时候所有重大事件都应有一个明确的管理者负责。任命为重大事

16、件经理的人员应该具有协调和控制事件解决的所有方面的相关授权。其中包括事件升级，以及与参与解决的相关各方和受重大事件影响的客户进行沟通。 重大事件处理流程应包括评审，评审将作为服务改进计划的输入。 4.3 问题管理 4.3.1 总则目标：通过对事件起因的主动识别和分析，以及管理问题的关闭，以最大限度降低对业务的损害。 问题管理作业指导书见附录A中相关作业指导书，参考表格见附录B，参考岗位设置见附录C，流程图见附录D -图D.2。4.3.2 问题管理的范围 问题管理过程应该调查事件的根本原因。问题管理应该根据业务要求预防事件或已知错误重复发生或再现。 4.3.3 启动问题管理 应该对事件进行分类，

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

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

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

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

21、乏知识和培训导致的事件。5 控制流程 5.1 配置管理 5.1.1 总则目标：定义并控制服务和基础设施的组件，并维护准确的配置信息。配置管理作业指导书见附录A中相关作业指导书，参考表格见附录B，参考岗位设置见附录C，流程图见附录D -图D.5。5.1.2 配置管理计划和实施 配置管理应结合变更和发布管理进行计划和实施，以确保服务提供方可以有效管理其IT资产和配置。准确的配置信息应该为新服务或变更的服务以及系统版本的发布和分发计划和变更控制提供支持。目的是形成一个综合服务提供方的配置信息过程并包括客户和供应商（必要时）的有效体系。应该考虑所有重要资产和配置，并指派管理责任人，以确保维护合适的保护

22、和控制，例如在实施前对变更授权。控制措施实施的职责可以委托给其他人员，但管理责任人仍然负有责任。应该向管理责任人提供履行职责的必要信息，如，进行变更授权时，可能需要变更的成本、风险和影响，以及和实施所需资源等信息。基础设施和（或）服务应该有更新的配置管理计划，该计划可能是一个单独文件，也可能是作为其它计划文件的一部分。该计划应该包括或描述：a) 范围、目标、方针、标准的角色和责任； b) 定义服务和基础设施的配置项、控制配置变更、记录和报告配置项状态以及验证配置项的完整性和准确性的配置管理过程； c) 对于可问责、可追溯、可审计的要求，如来自安全、法律、法规或业务目的的要求； d) 配置控制（

23、访问、保护、版本、 开发、版本控制）； e) 识别、记录和管理两个或多个组织的公共边界的配置项及信息的接口控制过程，如系统接口和版本； f) 资源的计划和确定，以便将资产和配置置于控制之下，并维持配置管理系统，如培训； g) 对进行配置管理的供应商和分包商的管理； 注： 可采取一定的自动化手段，以确保流程不会无效、错误百出、甚至失效。5.1.3 配置识别 所有配置项应该被唯一标识，并定义 描述其功能和物理特性的属性。信息应是相关，并可审计的。应该采用合适的标记或其它识别方法，并将其记录在配置管理数据库中。应该 利用已建立的选择准则来管理配置项，并应该包括： a) 信息系统、软件（包括第三方软件

24、）和相关系统文件的所有议题和版本，如，要求、规范、设计、测试报告、版本文件； b) 为适用的环境、标准硬件架构和版本建立配置基准或架构的描述； c) 主拷贝和电子资料库，如最终软件库； d) 使用的配置管理包或工具； e) 许可证；f) 安全组件，如防火墙； g) 出于财务管理和业务原因需要跟踪的物理资产，如安全磁盘介质、设备； h) 服务相关文件，如SLA、程序； i) 服务支持设施，例如机房电源； j) 配置项之间的关系和依赖性； 注： 其它可视为配置项的包括： a) 其它文档； b) 其它资产； c) 其它设施，例如站点； d) 业务单元； e) 人员。 应该识别配置项之间适当的关系和依

25、赖性，以便提供必要的控制级别。如果需要跟踪配置项，那么应该确保从需求文档到版本发布记录的整个生命周期内都是可追踪的，如实施可追溯矩阵。5.1.4 配置控制 配置过程应该确保只有经过授权且可识别的配置项才被接受，并记录从接受到销毁的全过程。没有适当的控制文件（如经过批准的变更请求、更新的版本信息），不能添加、修改、替换/删除配置项。为保护系统、服务和基础设施的完整性，配置项应该保存在一个合适的安全环境： a) 保护其不受未经授权的访问、变更或破坏，例如病毒； b) 提供灾难后的恢复方法； c) 允许对受控备份的受控恢复，如软件。 5.1.5 配置状态说明和报告 应该维护当前准确的配置记录，以反映

26、配置项状态、位置和版本的变更。状态清单应该提供配置项在整个生命周期中的当前和历史数据。应该利用多种状态来描述，使得配置项可以被跟踪，如订购、接收、验收测试、上线、变更中、撤回、销毁等。 配置项信息应该持续更新，并可以被已定义配置项的计划、决策和变更管理所用。 如果需要，用户、客户、供应商和合作方应该可以访问配置信息，以协助其制定计划和决策。例如，外部服务提供商可以提供配置信息给客户和其他相关各方，以支持其他服务管理过程的端到端服务。 配置项管理报告应该提供给所有相关各方。报告应该包括配置项的识别和状态、版本和相关文件。报告应该包括： a) 配置项最新版本； b) 配置项的位置和软件主版本的位置

27、；c) 相互依赖关系； d) 版本历史； e) 配置项状态及构成：服务配置或系统；变更、基准、编译或版本；版本号或变量。5.1.6 配置验证和审计 应该计划配置验证和审计过程（包括物理的和功能性的），并检查是否有合适的过程和资源： a) 保护物理配置和组织的知识资产； b) 确保服务提供方控制其配置、主拷贝和许可证； c) 确保配置信息是准确、可控和可见的； d) 确保变更、版本、系统或环境符合其合同约定或指定的要求，而且配置记录是准确的。应该定期进行配置审计，此外还应该在重大变更前后、灾难后和随机的不定期进行审计。 缺陷或不符之处应该被记录、评估和改进，反馈意见应提供给相关各方和服务改进计划

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

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

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

31、它变更管理要求时，变更应该尽可能满足适用可行的要求。 实施人员应该判断紧急变更的必要性，并在变更后评审，以确保是紧急变更。 5.2.5 变更管理报告、分析和措施 应该定期分析变更记录，以检测不断提高的变更级别、频繁再现的类型、呈现的趋势和其它相关信息。应该记录变更分析的结果和结论，并采取相应行动。6 发布流程 6.1 发布管理过程 6.1.1 总则目标：交付、分发和跟踪导入到运作环境中的一个或多个变更。 发布管理应该协调服务提供方、多个供应商和业务方，以计划在分布式的环境中提交版本。良好的计划和管理是版本打包、成功分发以及管理其对业务和IT的相关影响和风险的基础。应结合业务，对受影响的信息系统

32、、基础设施、服务和文档的版本发布进行计划。 发布的版本中应该包括文件的所有相关更新，如业务过程、支持文档和服务级别协议。所有对授权变更造成影响的新的或经过改动的配置项都应该被评估。服务提供方应该确保已经考虑版本发布的技术或非技术两个方面。版本项应该可跟踪并防止修改。只有经过适当测试和认可的版本才应该被导入运行环境。 发布管理作业指导书见附录A中相关作业指导书，参考表格见附录B，参考岗位设置见附录C，流程图见附录D -图D.4。6.1.2 发布策略 发布政策应该包括： a) 发布频次和类型； b) 发布管理的角色和责任； c) 版本导入到测试和生产环境的授权； d) 所有版本的唯一标识和描述；

33、e) 将变更组合到版本的方法； f) 为提高效率和可重复性，建立、安装、版本分发过程的自动化方法； g) 版本发布的验证和接受。 6.1.3 发布和撤销计划服务提供方应该在业务环境下工作，以确保将要发布的配置项彼此兼容并与发布环境中配置项相兼容。发布计划应该确保受影响信息系统、基础设施、服务和文件的变更得到认可、授权、计划安排、协调和跟踪。 发布和回退应该分阶段计划，因为回退的细节可能事先并不知道。发布和回退计划一般应该包括： a) 版本发布日期和可交付物的描述； b) 所发布版本的相关变更、关闭或解决的问题和已知错误，以及在版本测试期间所识别的已知错误； c) 实施跨越所有业务和地理单元版本

34、发布的相关流程； d) 如发布失败，用于回退或补救的方式； e) 验证和验收过程；f) 与客户和服务支持人员的沟通，以及相关准备、文件的提供和培训； g) 采购、存储、分发、联系、接受和销毁物品的后勤工作和流程； h) 确保维护服务级别所需的支持资源； i) 可能对将版本导入测试和运行环境造成影响的相关变更和风险的识别； j) 发布结束的签署； k) 如果必要，当进行重大升级时，应该安排对生产环境的审计，确保版本安装时的运行环境与预期状态一致。 6.1.4 软件的开发和获取 应该对内部团队、系统开发商、系统集成商或者其它组织的信息系统和软件的版本进行验收。 整个过程应该文件化到配置管理计划中。

35、 6.1.5 设计、建立和配置的发布应该对发布和分发进行设计和实施，以： a) 与服务提供方的系统架构、服务管理和基础设施标准相吻合； b) 确保编译、安装、处理、打包和交付的完整性； c) 在编译和发布过程中采用软件库和相关资源库来管理和控制组件； d) 清晰识别风险，并根据需要采取补救行动； e) 使得在安装前验证目标平台满足先决条件； f) 使得当发布实现目标时，验证版本的完整性。 本过程的结果包括版本通告、安装指南、基于相关配置基准线的已安装软硬件。发布的结果应该提交给测试小组。可以利用自动化系统编译、安装、发布和分发流程以减少出错，确保流程的可重复性和确保新版本能够快速发布。 6.1

36、.6 发布验证和接受 最终的结果应该是对照要求的、完整的版本包来签署。验证和接受过程包括： a) 验证受控的验收测试环境是否符合目的生产环境的要求； b) 确保版本是基于配置管理下的版本创建的，并采用事先计划好的工作流程安装到验收测试环境； c) 检查测试已经完成，例如功能性测试和非功能性测试，业务许可测试，开发、发布、分发和安装规程的测试； d) 确保版本经过测试，以使客户和服务提供人员满意； e) 确保适当的发布授权人员签署每一阶段的验收测试； f) 在安装前，验证目标平台满足软硬件要求；g) 当发布实现其目标时，验证版本的完整性。 6.1.7 文件 应该依据已发布的配置项，建立和保存合适

37、的文档，并按照配置管理过程管理。文件应该包括： a) 支持性文件，包括服务级别协议； b) 支持性文件，包括系统概述、安装和支持程序、辅助诊断、运行和管理指南； c) 编译、发布、安装和分发过程； d) 连续性和回退计划； e) 服务管理人员、支持人员和客户的培训计划； f) 版本的配置基准线，包括诸如系统文件、测试环境、测试文件、编译版本和开发工具等相关配置项； g) 相关变更、问题和已知错误；h) 关于发布授权、验证、接受的证据； 一个系统或服务不能符合要求时，应该在导入运行系统前，通过配置管理和问题管理被识别并记录。应该与事件管理交互已知错误的信息。 如果发布被拒绝、延迟或取消，应告知变

38、更管理人员。 6.1.8 回滚、分配和安装 应该对导入计划进行评审，并补充必要细节，以确保所有必要活动将被实施。 关键之处在于，发布应该在预期状态下完成。回滚、发布和安装流程应确保： a) 所有硬件和软件存储区是安全的； b) 采用合适的程序管理物品的存储、分发、接收和销毁； c) 计划并完成安装、环境准备、电子和设施的检查；d) 向业务和服务提供方通报新的发布； e) 卸载多余的产品、服务和软件许可。 当通过网络传送软件时，应该检查传送到目的地的软件是否完整和可运行。在成功完成安装之后，应该更新资产和配置管理的记录，包括软硬件的位置和负责人。可以采用客户安装验收和满意度问卷来检查安装是否成功

39、。客户的反馈应该被及时反馈给业务关系管理过程。 6.1.9 发布后处理和回退 在版本导入后一段时间内，应该对与发布相关的事件数量进行测量和分析，以评估对业务、运营和支持人员的影响。 变更管理流程应包括实施后的评审。相关建议应该作为服务改进计划的输入。AA附录A （资料性附录）保险业信息系统运行维护工作规范参考作业指导书A.1 总则本附录是根据本标准的相关原则，结合国内保险企业信息系统的现状，制定的一系列可供实施的信息系统运行维护相关作业指导书。本资料性附录可以作为各保险机构实施运行维护服务的作业参考，并且可以根据保险机构的现实情况，进行相关的修改或扩充，或者以电子化流程平台的方式进行流程实现。

40、A.2 作业指导书A.2.1 系统配置变更管理作业指导书A.2.1.1 目的规范对主机、数据库、存储和中间件系统的变更作业，确保标准的方法和过程可以得到使用，使系统的变更过程更为快捷，并且对服务的影响最小。应确保系统的所有变更都可以追溯。A.2.1.2 适用范围适用于对主机、数据库、存储和中间件系统的变更作业。A.2.1.3 职责操作系统维护岗负责对主机和操作系统的配置变更发起请求，存储系统维护岗负责对存储系统的配置变更发起请求，数据库系统维护岗负责对数据库系统的配置变更发起请求，中间件系统维护岗负责对中间件系统的配置变更发起请求。信息系统安全管理岗负责审批配置变更申请，并对系统的安全负责。操

41、作系统管理岗负责对主机和操作系统的配置变更方案进行分类及审核，存储系统管理岗负责对存储系统的配置变更方案进行分类及审核，数据库系统管理岗负责对数据库系统的配置变更方案进行分类及审核，中间件系统管理岗负责对中间件系统的配置变更方案进行分类及审核。操作系统执行岗负责对主机和操作系统的配置变更方案进行实施，存储系统执行岗负责对存储系统的配置变更方案进行实施，数据库系统执行岗负责对数据库系统的配置变更方案进行实施，中间件系统执行岗负责对中间件系统的配置变更方案进行实施。信息系统管理岗负责对已经实施的系统变更进行评价。A.2.1.4 程序A.2.1.4.1 记录操作系统维护岗|数据库系统维护岗|存储系统

42、维护岗|备份维护岗|中间件系统维护岗对所有的系统变更请求都进行记录。记录包括系统变更请求的组成、系统变更请求的来源和系统变更请求的具体项目记录，填写表B.1-配置变更记录表。A.2.1.4.2 审批A.2.1.4.2.1 信息系统安全管理岗需对系统变更请求进行初步评估，检查系统变更请求是否必要；是否清楚、合理；是否可执行。A.2.1.4.3 分类与批准A.2.1.4.3.1 操作系统管理岗|数据库系统管理岗|存储系统管理岗|备份管理岗|中间件系统管理岗对接受的系统变更请求进行分类并对配置变更方案进行审核批准，指定系统变更相应的影响和优先级。A.2.1.4.4 变更实施实施前应对拟变更的表B.2

43、-系统配置表进行备份,以供变更回撤使用。配置备份按照A.2.3-系统临时备份作业指导书进行操作。操作系统执行岗|数据库系统执行岗|存储系统执行岗|备份执行岗|中间件系统执行岗应在正式实施前对拟变更操作进行变更测试，测试成功后方可进行实施。操作系统执行岗|数据库系统执行岗|存储系统执行岗|备份执行岗|中间件系统执行岗对进行过通过测试的系统配置变更进行实施，并在表B.1-配置变更记录表上进行记录。如实施正常转A.2.1.4.5步骤进行操作，如不正常转A.2.1.4.6步骤进行操作。A.2.1.4.5 变更评价信息系统管理岗对已经实施的系统变更进行评价。A.2.1.4.6 启动回撤或应急计划如系统配

44、置变更实施不成功或实施成功但对已有信息系统服务造成影响的，操作系统执行岗|数据库系统执行岗|存储系统执行岗|备份执行岗|中间件系统执行岗执行系统配置变更回撤，将系统配置恢复至变更前状态。如系统配置变更回撤，按A.2.51-信息系统应急处理作业指导书进行应急操作。A.2.2 系统升级作业指导书A.2.2.1 目的规范主机、数据库、存储和中间件等系统的升级流程，保证系统升级过程的安全可靠。A.2.2.2 适用范围适用于主机、数据库、存储和中间件等系统的升级作业。A.2.2.3 职责操作系统维护岗负责对主机操作系统的升级发起请求，存储系统维护岗负责对存储系统的升级发起请求，数据库系统维护岗负责对数据

45、库系统的升级发起请求，中间件系统维护岗负责对中间件系统的升级发起请求。信息系统安全管理岗负责审批系统升级申请，并对系统的安全负责。操作系统管理岗负责对主机操作系统的升级方案进行分类及审核，存储系统管理岗负责对存储系统的升级方案进行分类及审核，数据库系统管理岗负责对数据库系统的升级方案进行分类及审核，中间件系统管理岗负责对中间件系统的升级方案进行分类及审核。操作系统执行岗负责对主机操作系统的升级方案进行实施，存储系统执行岗负责对存储系统的升级方案进行实施，数据库系统执行岗负责对数据库系统的升级方案进行实施，中间件系统执行岗负责对中间件系统的升级方案进行实施。信息系统管理岗负责对已经实施的系统升级

46、进行评价。信息系统安全审计岗负责对系统升级过程进行审计。A.2.2.4 程序A.2.2.4.1 升级请求的接收和记录操作系统维护岗|数据库系统维护岗|存储系统维护岗|中间件系统维护岗发起并报告系统升级事件，填写表B.3-系统升级记录表及制定相应的恢复策略，提交信息系统安全管理岗。A.2.2.4.2 审批信息系统安全管理岗对表B.3-系统升级记录表进行审批，判断是否清楚、合理，是否可执行。A.2.2.4.3 分类与批准操作系统管理岗|数据库系统管理岗|存储系统管理岗|备份管理岗|中间件系统管理岗对接受的表B.3-系统升级记录表进行分类并对升级方案进行审核批准，指定系统升级的影响和优先级。A.2.

47、2.4.4 实施实施前应对拟升级的配置进行备份,以供升级回撤使用。升级备份按照A.2.3-系统临时备份作业指导书进行操作。操作系统执行岗|数据库系统执行岗|存储系统执行岗|备份执行岗|中间件系统执行岗应在正式实施前对拟升级操作进行测试，测试成功后方可进行实施。操作系统执行岗|数据库系统执行岗|存储系统执行岗|中间件系统执行岗启动主机用户权限管理流程，在主机用户权限申请审批通过后对系统升级申请进行实施，如在升级过程中出现故障则引用A.2.4-系统恢复作业指导书或按照A.2.51-信息系统应急处理作业指导书进行应急操作，待系统升级完毕后填写表B.4-系统升级过程报告。A.2.2.4.5 变更评价信

48、息系统管理岗对已经实施的系统升级进行评价。A.2.2.4.6 审计信息系统安全审计岗对操作系统执行岗|数据库系统执行岗|存储系统执行岗|中间件系统执行岗的系统升级操作过程进行审计，并形成表B.5-审计记录表。 A.2.3 系统临时备份作业指导书A.2.3.1 目的规范主机操作系统、文件系统和数据库系统的数据临时备份流程。保证必要时能对数据进行时间点的恢复，操作系统、文件系统和数据库能够及时恢复。A.2.3.2 适用范围适用于主机操作系统、文件系统和数据库系统的备份作业。A.2.3.3 职责备份维护岗负责发起系统备份申请。信息系统安全管理岗负责对系统备份申请进行审批。备份管理岗负责对备份申请进行

49、分类，并对备份策略进行审核。备份执行岗负责对备份申请进行实施。信息系统安全审计岗负责对备份执行岗的系统备份操作过程进行审计。A.2.3.4 程序A.2.3.4.1 备份申请的接收和记录备份维护岗发生并报告系统备份事件，填写表B.6-系统临时备份记录表，提交信息系统安全管理岗。A.2.3.4.2 审批信息系统安全管理岗对表B.6-系统临时备份记录表进行审批，是否清楚、合理，是否可执行。A.2.3.4.3 分类备份管理岗对接受的备份请求进行分类，指定备份相应的影响、级别和优先级。A.2.3.4.4 实施备份执行岗进行主机用户权限的申请，在主机用户权限申请审批通过后对系统备份申请进行实施，并填写表B

50、.6-系统临时备份记录表。A.2.3.4.5 启动回撤或应急计划当临时备份实施不正常时，备份执行岗报请信息系统安全管理岗，启动回撤计划或按A.2.51-信息系统应急处理作业指导书进行应急操作。A.2.3.4.6 审计信息系统安全审计岗对备份执行岗的系统备份操作过程进行审计，并形成系统临时备份审计结果，填写表B.5-审计记录表。 A.2.4 系统恢复作业指导书A.2.4.1 目的规范主机和数据库系统的数据恢复流程。保证必要时能对数据进行时间点的恢复，操作系统、文件系统和数据库能够及时恢复。A.2.4.2 适用范围适用于主机和数据库系统的数据恢复作业。A.2.4.3 职责备份维护岗负责发起系统恢复

51、申请。信息系统安全管理岗负责对系统恢复申请进行审批。备份执行岗负责对系统恢复申请进行实施。信息系统安全审计岗负责对备份执行岗的系统恢复操作过程进行审计。A.2.4.4 程序A.2.4.4.1 系统恢复申请的接收和记录备份维护岗发起并报告系统恢复事件，填写表B.7-系统恢复记录表，提交信息系统安全管理岗。A.2.4.4.2 审批信息系统安全管理岗对表B.7-系统恢复记录表进行审批，是否清楚、合理；是否可执行。A.2.4.4.3 实施备份执行岗启动主机用户权限管理流程,并在主机用户权限申请审批通过后对系统恢复操作申请进行实施，形成系统恢复实施记录。A.2.4.4.4 审计信息系统安全审计岗对整个系

52、统恢复操作内容进行审计，并填写表B.5-审计记录表。A.2.5 系统安装作业指导书A.2.5.1 目的规范主机、数据库、存储和中间件的系统安装流程，保证系统安装过程有序进行。A.2.5.2 适用范围适用于主机、数据库、存储和中间件的系统安装作业。A.2.5.3 职责操作系统维护岗|数据库系统维护岗|存储系统维护岗|中间件系统维护岗负责新系统的安装规划及安装策略的制定A.2.5.4 程序A.2.5.4.1 系统安装规划操作系统维护岗|数据库系统维护岗|存储系统维护岗|中间件系统维护岗填写表B.8-系统安装记录表，针对需要安装的系统，制定安装策略，确定安装时间以及配置；并对安装的版本号进行规划。A

53、.2.5.4.2 系统安装计划操作系统维护岗|数据库系统维护岗|存储系统维护岗|中间件系统维护岗制定相应的安装计划，并提交信息系统安全管理岗进行审核。A.2.5.4.3 系统安装实施如果是数据库和中间件系统的安装，数据库系统执行岗|中间件系统执行岗启动主机用户权限管理流程，在主机用户权限申请审批通过后对系统安装申请进行实施，填写B.2.8-系统安装记录表；如果是操作系统和存储系统的安装，则操作系统执行岗|存储系统执行岗直接对系统安装申请进行实施，填写表B.8-系统安装记录表。A.2.5.4.4 测试操作系统维护岗|数据库系统维护岗|存储系统维护岗|中间件系统维护岗对安装的系统进行测试，填写表B

54、.9-系统安装测试报告，信息系统安全管理岗根据表B.9-系统安装测试报告确定是否能够试运行，如符合要求，则进行试运行。如不符合要求，则跳到A.2.5.4.1重新进行相应的测试和系统安装准备。A.2.5.4.5 系统试运行测试通过后，操作系统维护岗|数据库系统维护岗|存储系统维护岗|中间件系统维护岗、信息系统安全管理岗配合用户根据系统安装计划联合组织进行试运行。A.2.5.4.6 验收信息系统安全管理岗根据测试报告及系统试运行状况确定是否能够验收，如符合要求，则进行正式的验收。如不符合要求，则跳到A.2.5.4.1重新进行相应的测试和系统安装准备。A.2.5.4.7 试运行评审信息系统安全管理岗组织对试运行期间的相关情况进行评审，填写表B.5-审计记录表。评审通过则进行相应的系统配置。不通过则跳到A.2.5.4.2再进行测试、试运行和验收。A.2.5.4.8 安装配置操作系统维护岗|数据库系统维护岗|存储系统维护岗|