前言
本文件按照GB/T 1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起草。
本文件代替JR/T 0079—2013《保险业信息系统运行维护工作规范》，与JR/T 0079—2013相比，除结构调整和编辑性改动外，主要技术变化如下：
a）根据行业最新业务发展以及监管要求，本文件所覆盖的服务管理流程由三类增加到五类，新增“服务交付流程”和“关系流程”；
b）结合相关文件和监管要求，进一步细化各流程环节和管理要求，在原有“事件管理”“问题管理”“配置管理”“变更管理”“发布管理”5个子流程的基础上，新增“服务目录和服务请求”“容量管理”“风险管理”“服务连续性和可用性”“信息安全管理”“业务关系管理”“供应商风险管理”7个子流程；
c）结合云计算、大数据、人工智能等新技术发展，增加新技术适配要求；
d）结合保险业数字化转型要求，增加数字化、自动化、智能化、自主可控等能力要求；
e）精简“作业指导书”和“表格文件”等附录内容。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
本文件由全国金融标准化技术委员会保险分技术委员会（SAC/TC 180/SC1）提出并归口。
本文件起草单位：中国人民财产保险股份有限公司。
本文件主要起草人：何激、王军、严亮、申海立、杨理国、柯登科、张妍、孙平、鲁京京、胡波、刘艳、杨建仁、吴昊、熊丽霞、翟烁、王金泽、余娜。
本文件及其所替代文件的历史版本发布情况如下：
——2013年首次发布为JR/T0079—2013；
——本次为第一次修订。
引言
信息科技是保险业快速发展的重要支撑。能否提供优良的信息科技服务，是影响保险业内外部客户满意度的重要组成部分，也是保险机构核心竞争力的重要组成部分。运行维护服务是信息技术服务的核心部分，对保障保险机构信息系统的安全稳定运行至关重要。
本文件旨在规范保险机构信息技术运行维护服务实施活动，指导保险机构通过有效的运行维护服务实施手段，提高运行维护服务实施水平，保障信息系统安全稳定运行，从而提高内外部客户的满意度，提高保险机构的核心竞争力。
保险业信息系统运行维护工作规范
1、范围
本文件规定了保险业信息系统运行维护工作流程和要求。
本文件适用于中华人民共和国境内保险机构的各类信息系统运行维护活动和管理，保险集团下的其他金融企业亦可参照使用。
2、规范性引用文件
下列文件中的内容通过文中的规范性引用而成为本文件的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
GB/T 29264—2012 信息技术服务分类与代码
GB/T 24405.1 信息技术服务管理第1部分：规范
GB/T 28827.1 信息技术服务运行维护第1部分：通用要求
3、术语和定义
下列术语和定义适用于本文件。
3.1 信息技术服务 information technology service
信息技术服务是指供方为需方提供开发、应用信息技术的服务，以及供方以信息技术为手段提供支持需方业务活动的服务。[来源：GB/T 29264—2012，2.1]
3.2 服务管理 service management
服务管理是指为满足业务需求对服务进行的管理。[来源：GB/T 24405.1，2.14]
3.3 运行维护服务 operation and maintenance service
运行维护服务是指采用信息技术手段和方法，依据需方提出的服务要求，对其信息系统的机房基础设施、物理资源、虚拟资源、平台资源、应用和数据，以及满足用户使用信息系统过程中的需求等提供的综合服务。[来源：GB/T28827.1，3.1]
3.4 过程 process
过程是指组织中利用输入实现预期结果的相互关联或相互作用的一组活动。[来源：GB/T28827.1，3.5]
3.5 流程 process
流程是指用于实现特定目标的一系列有组织的活动，可以包括角色、责任、工具和管理控制。
3.6 服务目录 service catalog
服务目录是指服务实施机构提供给用户的所有可申请服务的列表。注：服务目录通过用户语言对服务进行描述，并提供相关概要说明。
3.7 资源 resource
资源是指组织中用于交付运行维护服务所依存和产生的有形及无形资产。[来源：GB/T 28827.1，3.7]
3.8 服务请求 service request
服务请求是指用户发起服务操作的请求。
3.9 IT服务管理平台 IT service manage platform
IT服务管理平台是指用于支持信息系统运行维护各类过程的流程管理平台。
3.10 容量计划 capacity planning
容量计划是指容量交付、调整、回收活动的需求、时间、配置、方案等内容。
3.11 风险 risk
风险是指不确定性对信息系统运行服务水平的影响。
3.12 服务可用性 service availability
服务可用性是指一项服务在约定的时间点或时间段内执行所需功能的能力。[来源：GB/T 28827.1，3.17]
3.13 服务连续性 service continuity
服务连续性是指一项服务在按照商定的服务可用性要求中连续无中断交付服务的能力。[来源：GB/T28827.1，3.18]
3.14 服务台 service desk
服务台是指面向顾客的、完成大部分支持工作的支持组。[来源：GB/T 24405.1，2.12]
3.15 基线 baseline
基线是指在某个时间点上服务或各个配置项的状态。[来源：GB/T24405.1，2.2]
3.16 配置项 configuration item
配置项是指处于或将处于配置管理之下的基础设施部件或项。[来源：GB/T24405.1，2.4]
3.17 配置管理数据库configuration management database；CMDB
配置管理数据库是指包含每个配置项所有相关的详细信息和配置项之间重要关系的详细信息的数据库。[来源：GB/T 24405.1，2.5]
3.18 变更 change
变更是指对信息系统运行环境中的配置项所作的增加、修改或移除等操作。
3.19 变更模型 change model
变更模型是指标准化的变更过程、要素、方案，使之可以重复使用。
3.20 发布 release
发布是指经测试且被引入实际运行环境的新配置项和（或）变更的配置项的集合。[来源：GB/T 24405.1，2.10]
3.21 事件 incident
事件是指不属于某项服务的标准操作、导致或可能导致服务中断或服务质量降低的任一事态。[来源：GB/T24405.1，2.7]
3.22 问题 problem
问题是指一个或多个事件的未知的潜在原因。[来源：GB/T 24405.1，2.8]
4、运行维护过程框架
信息系统运行维护是信息系统服务管理的一部分，保险机构应建立有效的信息系统运行维护过程框架和流程管理规范，保障信息系统服务安全稳定运行，提高信息技术服务质量，支撑保险业服务过程的规范化管理和服务价值实现。
本文件将信息系统运行维护过程分为五大类，参考过程框架如图1所示。
信息系统运行维护五大类过程的定义和主要内容如下：
a）服务交付过程：指按照预先的承诺提供服务以满足客户或用户要求的相关流程，包括服务目录和服务请求管理、容量管理、风险管理、服务连续性和可用性管理、信息安全管理；
b）关系过程：指管理与客户或用户、供应商等相关方关系的流程，包括业务关系管理和供应商风险管理；
c）控制过程：指管理信息系统配置、变更等活动的流程，包括配置管理和变更管理；
d）发布过程：指管理应用系统生产环境版本变化的发布管理流程；
e）解决过程：指管理信息系统运行中产生的事件、问题及其处置过程的流程，包括事件管理和问题管理。
保险机构应根据实际情况明确列出岗位职责要求、服务管理流程和流程关系接口。相关内容可参考附录A岗位设置和附录B流程图。
保险机构应设置过程衡量指标，定期对过程运行结果进行评估，回顾实际运行中存在的问题，并依据评估结果对过程框架设计进行改进及持续跟踪，确保交付的运行维护服务内容符合GB/T28827.1规定，并满足质量要求。
5、服务交付过程
5.1 服务目录和服务请求管理
5.1.1 目的
服务目录管理用于描述信息技术服务详细信息，为用户提供唯一的、一致的服务供应入口。服务请求管理用于规范服务的响应和处理过程，提高处理效率，持续改善用户体验、提升用户满意度。
5.1.2 范围
服务目录和服务请求管理适用于保险机构信息科技部门内部使用的和为业务部门提供的各类信息技术服务，包括但不限于业务服务、数据中心服务、网络专线服务、信息安全运维、桌面运维、软件及应用系统运维服务、信息技术咨询等。
5.1.3 总体要求
服务目录和服务请求管理应符合以下要求：
a）清晰明确：服务目录中的服务在内容和形式上应清晰、明确，不应重复、矛盾；
b）以用户为中心：服务流程应以用户为出发点，用统一、标准化的方式提供服务；
c）责任明确：每个服务请求单在服务的任何阶段都应有明确的责任人，保证服务及时、有效；
d）闭环管理：用户的每一次服务请求，应及时登记受理、安排处置，将办理结果及时反馈用户，并记录用户意见。
5.1.4 服务目录管理流程
5.1.4.1 服务目录分类
服务目录可划分为业务服务目录和技术服务目录。业务服务目录用于支撑业务部门日常业务活动，包括应用系统需求交付服务、故障处理服务等；技术服务目录包括技术服务和配套服务，技术服务主要为数据中心基础设施服务，配套服务包括OA、邮件、账号管理、权限管理、桌面管理等。
5.1.4.2 需求发起
服务目录的需求发起应符合以下要求：
a）当新系统上线、服务升级/降级、资源变动、服务下线时，运维岗应按需发起服务目录更新申请；
b）运维岗负责收集并识别引起服务目录变更的相关信息，对需求进行梳理、分解；
c）运维岗应定期组织对服务目录进行评估和修订。
5.1.4.3 需求审批
服务目录的需求审批应符合以下要求：
a）运维经理对服务目录变更需求进行审批，并协调统一版本；
b）运维经理判断是否需要服务相关方审批会签，如无需会签则转入“维护更新”；审批不通过，退回运维岗修订。
5.1.4.4 维护更新
服务目录的维护更新应符合以下要求：
a）IT服务管理平台运维岗按照需求方要求与服务目录管理要求，对业务系统或技术条线运维工作的服务内容、服务方式和服务标准等内容进行整理修订；
b）提出需求的运维岗对修订后的服务目录进行测试，测试内容包括但不限于页面跳转的准确性、服务内容描述的一致性等。
5.1.4.5 发布生效
服务目录的发布生效应符合以下要求：
a）运维经理正式发布新的服务目录版本，并根据服务范围进行宣贯，向相关用户、运维岗、供应商传达涉及的变更内容；
b）按需发起变更流程，在IT服务管理平台上更新服务目录相关的服务项，如服务级别、配置信息等；
c）涉及服务水平级别变化的，应在服务级别管理中予以落实；
d）在服务目录修订过程中积累的经验可通过知识管理记录到知识库中。
5.1.5 服务请求管理流程
5.1.5.1 服务申请
用户、运维岗、开发岗、测试岗可作为服务申请人，根据服务目录选择合适的服务进行申请。
5.1.5.2 服务审批
服务审批应符合以下要求：
a）运维经理对服务申请的合理性、规范性、必要性进行审核，并填写审核意见；
b）运维经理判断是否需要服务相关方审批会签；
c）如果审批通过，运维经理将服务请求单分派给具体的运维岗实施；不通过，则退回至服务申请人补充或关闭。
5.1.5.3 服务实施
服务实施应符合以下要求：
a）运维岗收到服务请求后应尽快响应，并检查工单内容的合规性、完整性和准确性，必要时要求服务申请人补充信息，对于满足服务准入要求的服务请求单及时实施服务；
b）运维岗在确认本人无法解决被分派的服务请求单时，应及时将服务请求单转派至合适人员。转派服务请求单时应详细记录转派理由，包括已经执行过的实施手段、获得的结果及其他必要信息；
c）服务实施过程中，如需通过变更解决，应启动变更管理流程并关联变更单，并在变更实施完成后继续处理服务请求单；对需要调用子服务请求的服务办理，可由运维岗新建并关联调用的子服务请求；对需要多人共同办理的服务，可由运维岗发起办理会签；
d）服务实施完毕后，运维岗应填写解决方案、处理过程以及处理结果等信息。
5.1.5.4 反馈关闭
反馈关闭应符合以下要求：
a）服务申请人在获得服务请求实施结果后，确认并判断服务实施结果是否达到了预期效果。如果是，则进行满意度评价并及时关闭工单；如果否，将工单退回给实施环节重新处理；
b）保险机构应定期对本机构的服务请求流程执行和实施情况进行分析、总结和回顾，不断提高服务满意度。
5.2 容量管理
5.2.1 目的
容量管理的目的是规范信息化基础资源管理，促进资源合理分配，提高资源使用效率，增强资源管理的透明程度，有力保障业务稳定运行与信息化项目有序推进。
5.2.2 范围
容量管理的对象涵盖生产、灾备、开发和测试等各类环境所使用的信息化基础资源，包括但不限于分布式组件、中间件、主机、存储、网络线路、网络设备、安全设备、机房环境等。
5.2.3 总体要求
保险机构应制定容量规划，以适应外部环境变化产生的业务发展和交易量增长，容量规划应涵盖生产系统、备份系统及相关设备。容量管理应符合以下要求：
a）业务支撑：资源容量服务于公司业务发展，应与业务应用现状、持续发展需求相匹配；
b）经济性：在保障业务服务水平的前提下，应降低资源的消耗、冗余及长期闲置。
5.2.4 容量管理流程
5.2.4.1 容量监控
容量经理、运维经理、开发经理应对重要信息系统开展有效的日常容量监控，确保能及时预测、发现资源瓶颈。
容量监控应符合以下要求：
a）开发经理、运维经理等作为容量需求提出人提交容量工单，准确地量化预估业务活动规模，例如用户数量、交易总量、服务时间、服务水平、预计业务高峰时段等；
b）容量经理分析新需求对现有系统容量的影响，同时分析应用软件的性能风险和变化趋势，监控系统容量使用，参与容量异常处理和变更分析工作；
c）新旧系统过渡期间，对仍承载重要业务功能的旧系统，容量经理协调开发经理、运维经理定期开展生产系统的性能容量评估，对风险隐患及时采取升级扩容措施或将业务切换至新系统承载。
5.2.4.2 容量差距分析
容量经理判断现有资源能否满足容量需求，是否需要进行采购。如需采购，根据需求制定下一阶段容量发展计划，后续安排采购。
5.2.4.3 容量计划
容量计划应符合以下要求：
a）容量经理负责制定容量调整计划，确定系统容量调整的具体范围、目标值和时间点。容量经理可建立资源分配优先级规则，按照相关要素权重评估资源交付优先级，优先级高的优先获得资源。容量经理应协调运维经理充分运用负载调度和弹性扩缩容等手段提升资源动态管理能力；
b）各板块容量经理明确应交付的资源，并进行资源的内部匹配，包括计算、存储、访问带宽、安全防护、物理空间等；
c）信息科技部门领导层可召开容量审议会议，对容量调整计划进行评审，对资源管理活动中的争议进行决策。评审内容可包括：资源容量分配情况、资源池和资源整体使用率情况、资源现状分析和资源需求、年度资源计划和实施进展、实际申请资源与预算评估资源差距说明等。出现审议年度资源采购计划、有重大项目容量需求或重大资源调整、存在资源分配争议等情况，也可临时召开会议或者其他方式评审；
d）资源交付岗根据容量调整计划对资源进行补充、调整或回收。交付资源应确保相关基线配置和监控设置，调整资源应通过变更管理流程实施。
5.3 风险管理
5.3.1 目的
风险管理的目的是消除信息系统运行过程中的潜在风险隐患，提高信息科技服务的可靠性，最大化地支持业务的正常运行，实现业务的相关目标。
5.3.2 范围
管理的风险包括影响信息系统运行或服务连续性的内部和外部环境风险，例如系统软硬件风险、数据风险、外部发布的产品漏洞、人员风险等。
5.3.3 总体要求
保险机构应制定全面的信息科技风险管理策略，制定持续的风险识别和评估流程，依据信息科技风险管理策略和风险评估结果，实施全面的风险防范措施。风险管理应符合以下要求：
a）整合性：风险管理是所有信息系统运行维护活动的组成部分。风险管理方法可应用于其他管理流程，例如变更管理、服务连续性管理等；
b）动态性：随着系统内部和外部环境的变化，风险可能会出现、变化或消失，风险管理应以适当和及时的方式预测、监督、掌握和响应这些变化；
c）定制化：根据系统及其服务相关的外部和内部环境来制定风险管理框架和流程，二者密切相关。
5.3.4 风险管理流程
5.3.4.1 风险识别与分析
信息系统运维岗、开发岗、测试岗分析、总结风险点，连续性经理汇总形成风险指标集。风险来源包括但不限于以下方面：
a）事件应急风险；
b）事件、问题中存在的风险；
c）按照发布的风险点定期识别的风险；
d）专项风险；
e）系统上线、升级、变更中存在的风险；
f）外部发布的相关风险；
g）根据运维经验自行识别的风险。
连续性经理组织运维岗、开发岗、测试岗人员开展风险分析工作，包括但不限于以下内容：
a）对风险影响程度、发生概率等进行分析，定性、定量地给出风险大小或等级；
b）分析应对风险的人力、物力等投入，制定风险应对方案；
c）分析现有控制措施的有效性及效果；
d）形成风险评估表。
5.3.4.2 风险评价与应对
连续性经理基于风险分析结果给出评价报告，并定期汇报给信息科技部门领导层。领导层对于无法应对的风险进行决策，并协调资源应对风险、转移风险，或明确风险的潜在影响并接受风险。
运维岗、开发岗、测试岗根据风险应对方案落实相关举措，持续监控风险变化，并定期将进展报告给连续性经理，连续性经理记录风险相关情况。
5.3.4.3 风险审查与改进
信息科技部门应定期开展风险管理会议，对风险清单进行检查和更新，核实风险状态，跟踪风险应对措施，监督风险应对情况。
5.4 服务连续性和可用性管理
5.4.1 目的
服务连续性和可用性管理的目的是确保向用户承诺的服务连续性和可用性目标能够实现。
5.4.2 范围
服务连续性管理适用于应对及处理重要信息系统灾难性事件和重大突发中断事件。服务可用性管理适用于所有信息系统的运维服务。
5.4.3 总体原则
保险机构应将服务连续性管理纳入全面风险管理体系，建立与本机构战略目标相适应的服务连续性管理体系，确保重要业务在运营中断事件发生后快速恢复，降低或消除因重要业务运营中断造成的影响和损失，保障业务持续运营。保险机构应加强灾备建设，定期组织开展应急演练，提升同城灾备和异地灾备的覆盖度，确保灾备中心资源充足可用。
服务连续性管理应符合以下原则：
a）及时性：针对重大突发中断事件，根据连续性计划和应急预案及时进行评估和应急处理；
b）规范性：通过明确启动服务连续性的标准和责任，采用预防和恢复相结合的控制措施，将灾难和重大突发中断事件对重要业务造成的影响降低到可接受的水平。
服务可用性管理应符合以下原则：
a）支撑业务需求：围绕业务对信息服务需求，设置应用及基础设施服务水平与可用性指标；
b）可量化可监控：指标可量化、可监控，并持续进行管理和改进。
5.4.4 服务连续性管理要求
5.4.4.1 连续性计划
连续性经理开展针对服务连续性的风险分析，并制定服务连续性计划和总体应急预案，作为发生重大灾难时的执行依据。
服务连续性计划应至少包含以下内容：
a）启动服务连续性的条件和责任；
b）重要业务及关联关系、业务恢复优先次序；
c）重要业务运营所需关键资源；
d）应急指挥和危机通讯程序；
e）服务连续性计划启用时的服务可用性目标和服务恢复要求；
f）各类预案以及预案维护、管理要求；
g）残余风险。
5.4.4.2 应急演练
连续性经理对灾难恢复预案进行管理，定期组织预案培训，每年至少组织一次灾难恢复预案演练，演练类型可以是模拟演练、实战演练、部分演练或全面演练。
应急演练应符合以下要求：
a）对重要信息系统开展灾难恢复演练；
b）在实施灾难备份切换、回切时，业务部门要对中断时的重要业务数据进行核对，并在信息科技部门配合下，对丢失的数据进行追补；
c）在实施灾难备份切换、回切时，要进行测试和验证，确保保险业务可靠性；
d）关键业务变更时，需要对关键业务的应用系统灾难恢复应急预案进行更新并进行测试；
e）根据演练结果编写应急演练报告，回顾应急演练结果，总结问题并制定改进措施；
f）进行全面灾备切换和真实业务接管演练前应向保险监管机构或其派出机构报告，并在演练结束后报送演练总结。
5.4.5 服务可用性管理要求
服务可用性管理是针对日常可用性管理工作进行持续改进的过程。
服务可用性管理应符合以下要求：
a）运维经理基于业务对应用系统服务水平需求，确定可用性需求。当新应用系统上线或应用系统重大升级时，对可用性需求的变化进行评估；
b）可用性管理关键绩效指标包括系统可用率、系统故障平均间隔时长、系统故障次数等；
c）运维经理根据可用性需求，制定可用性管理活动的措施和计划，必要时测试措施的有效性，不同应用系统和不同信息资源可分别制定可用性计划；
d）连续性经理基于各应用服务水平需求、各应用间关联关系、系统架构及各组件的可用性进行评审，评审内容可包括：可用性需求与可用性现状差距、可用性计划的必要性、可用性计划所需资源的合理性、可用性计划时间进度可行性等。连续性经理统筹各个应用可用性的时间安排，必要时提交专家团队审核；
e）运维经理收集并记录可用性数据，如事件中断时长、变更引起计划/非计划中断时长等，监控可用性状态、分析可用性趋势，必要时可采取措施满足可用性需求，如调整监控策略、调整资源容量、调整灾备管理需求等；
f）信息科技部门应对信息系统可用性进行考核，每月组织对可用性现状、趋势以及可用性计划执行情况进行回顾，以确保当前的可用性计划以及趋势满足服务水平对可用性的需求。
5.5 信息安全管理
5.5.1 目的
信息安全管理的目的是保护信息系统免受各种威胁的损害，确保服务连续性和业务风险最小化。
5.5.2 范围
信息安全管理适用于信息安全日常管理活动。
5.5.3 总体要求
信息安全管理应符合以下要求：
a）完整性：信息在存储、使用和传输过程中应保持一致，避免被篡改；
b）保密性：信息只为授权用户使用；
c）可用性：信息资源可被授权实体按要求访问、正常使用或在非正常情况下快速恢复使用；
d）可控性：具备对网络系统和信息传输的控制能力。
5.5.4 信息安全管理要求
保险机构应通过管理机制和技术手段，加强信息安全保障工作，保障业务活动的连续性。
信息安全管理应符合以下要求：
a）信息安全经理应定期收集、整理和解读合规要求，完善信息安全管理制度和技术体系，制定信息安全管理策略；
b）根据等级保护相关要求，信息安全经理组织对新建信息系统定级或者发生重大变更的信息系统重新定级，并及时备案。每年对等级保护三级系统开展测评，或者在发生重大变更或级别发生变化时进行等级测评，并对发现不符合相应等级保护标准要求的事项及时整改；
c）信息系统运维岗从通信网络、网络边界、局域网络、计算环境及业务应用等各个层次落实各种安全措施，形成纵深防御体系；
d）信息系统运维岗划分特定的管理区域以及安全的信息传输路径，对网络中的安全设备或安全组件进行管控，实现对安全策略、恶意代码、补丁升级等各个层面的安全功能在统一策略的指导下集中管理；
e）信息系统运维岗在关键网络节点、设备节点和应用系统检测、防止或限制从外部与内部发起的网络攻击行为，具备技术措施对网络行为进行分析，实现对网络攻击特别是新型网络攻击行为的分析，能够记录攻击源IP、攻击类型、攻击目标、攻击时间，在发生严重入侵事件时应提供报警；
f）信息系统运维岗在关键网络节点对恶意代码、垃圾邮件进行检测、清除和防护；
g）信息安全经理在网络边界、重要网络节点对重要的用户行为和重要安全事件进行审计，对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖；
h）信息安全经理每年对信息安全进行风险评估，识别信息系统相关资产重要程度、脆弱性、威胁和现有控制措施；对于不可接受的风险进行处置，采用管理和技术措施消除资产脆弱性或者降低威胁程度；对于可暂不处置的风险，应监控其风险态势和变化趋势。
6、关系过程
6.1 业务关系管理
6.1.1 目的
业务关系管理的目的是提高信息服务的工作效率和服务质量，更好满足用户不断增长的服务需求，提升用户满意度。
6.1.2 范围
业务关系管理适用于信息科技部门为用户提供的系统操作咨询、系统使用问题处理、体验优化等工作，包括用户服务流程、主动服务流程和投诉管理流程。
6.1.3 总体要求
业务关系管理应符合以下要求：
a）用户满意：以用户为中心，为用户交付满意的服务，满足用户合理需求并及时反馈，持续提升服务质量；
b）关注用户体验：关注信息服务的用户体验，加强与用户沟通，与用户实现价值共创；
c）确保服务承诺：通过规范化的服务管理，不断提升信息服务水平，履行服务承诺。
6.1.4 用户服务流程
6.1.4.1 提出服务申请
用户作为服务提出人提出服务申请。
提出服务申请流程应符合以下要求：
a）用户通过线下渠道或服务流程提交服务申请，服务台可引导、协助用户自助填写，或代为操作。服务台根据日常收集的客户意见和主动观察、分析的结果，识别用户的问题和需求，提交服务申请；
b）服务申请应明确相关要素信息，如期望的完成期限、需要的交付物、申请的理由、完工的准则等。
6.1.4.2 分析和办理
服务申请分析和办理应符合以下要求：
a）服务台或运维一线判断服务申请是否合理，是否具备实施条件，若无法处理，则退回服务提出人并解释理由；服务台或运维一线判断服务申请是否为故障，若是应转为事件工单进行处理；若服务单的事项在服务台或运维一线职责和能力范围内，可直接处理；否则应转派给运维二线进行处理，提交时要详细说明既有分析结论和监控、日志、代码等分析记录；
b）运维二线收到派单后，在已有的分析结论与过程记录基础上，通过对监控、日志、数据等进行再分析，判断是否是代码问题、是否需要特殊权限；经分析研判，初步确定为疑似程序问题、用户体验和业务需求类问题，通过程序问题、需求相关流程提交对应的开发岗进行分析；
c）运维二线根据分析确认结果制定解决方案，必要时应测试方案的有效性和安全性；涉及开发岗发布新的程序代码的，应将该升级包的开发需求和部署方案作为解决方案；解决方案中如果需要特殊权限的，应按照相关要求提出权限申请；
d）服务台或运维岗按照解决方案完成服务办理。涉及对生产环境更改的操作，需要通过变更管理完成；涉及发布新的程序代码的，需要通过发布管理完成；无法在规定时限内完成或无法全部完成时，应提交运维经理判断是否升级，以获取更多的资源满足服务级别要求；
e）运维经理对升级的服务协调更多的资源支持，如协调技能、精力、工具方面有优势的人员处理，按照期望的时间和标准开展工作。运维经理对处理进度保持关注，酌情安抚服务申请人并向申请人通报进度；
f）处理用户问题的相关人员应及时总结问题现象和解决方案，形成知识并提交知识库，促进知识在不同的组织、系统、团队间横向传播和共享，提高工作效率，提升用户体验。宜采用人机交互、自然语言处理、数字员工、大语言模型等新技术实现系统使用问题的快速处理、自助服务，通过科技赋能提升基层人员定位、解决问题的效率。
6.1.4.3 服务反馈
服务反馈应符合以下要求：
a）服务台应初步验收服务成果是否完全满足服务需求，若不满足应协调返工；如果已解决，则反馈解决时间、解决方案和效果；如果不能短期解决，则反馈解决方案、预计解决时间；
b）服务台应使用易于申请人理解的语言在工单中反馈问题或需求解决结果，避免使用纯技术语言。
c）邀请用户进行服务评价。
6.1.5 主动服务流程
服务台应关注用户体验，通过服务回访、满意度调查、数据分析等多种方式与用户主动沟通、互动，收集服务优化问题和需求。
主动服务流程应符合以下要求：
a）服务台制定主动回访计划，明确回访频次和主动沟通内容，并按照计划定期开展回访活动，主动与用户沟通，收集用户服务体验和服务需求；
b）服务台制定满意度调查方案，明确调查对象、调查时间、调查内容，设计满意度调查问卷。服务台根据满意度调查方案，通过邮件、系统、电子问卷、纸质问卷等方式开展满意度调查工作。服务台要关注满意度调查问卷的回收情况，对调查问卷初步筛选出合格问卷；
c）服务台收集用户关于服务质量的服务信息和服务需求，通过专项分析或综合分析得到服务质量的实现情况，分析出需要优化的服务需求或问题，并通过用户服务流程解决；
d）运维经理从用户视角完善服务质量分析模型，借助分析模型获得服务质量的量化数据，可借助工具平台不断提升数据分析能力，准确挖潜用户需求和问题。通过客户服务质量数据报表或报告，掌握信息系统运行情况及使用信息，提出优化改进措施，提升服务质量。
6.1.6 投诉管理流程
6.1.6.1 提出投诉
用户通过对外公布的各种有效渠道提出投诉。
6.1.6.2 调查和解决
投诉管理的投诉调查和解决应符合以下要求：
a）运维经理应及时响应投诉，安抚用户情绪，与用户进行沟通，充分了解投诉原因及相关信息，包括：投诉人姓名、投诉人联系方式、投诉事由、发生时间、对业务的影响、期望结果等；
b）运维经理根据获取的信息，对投诉事件开展调查。运维经理会同服务台和运维岗，分析投诉原因，解决投诉问题，编制调查诊断结果；
c）运维经理将调查诊断结果反馈投诉人，若投诉人不认可，可将投诉升级到上级领导进一步处理，必要时继续升级，直到给出投诉人认可的调查诊断结果和处理意见。
6.1.6.3 总结和改进
投诉管理的总结和改进应符合以下要求：
a）运维经理根据投诉记录、调查诊断结果、补救措施，制定服务改进计划，并进行优化整改，跟踪服务改进计划执行情况；
b）运维经理编制最终的投诉处理报告，记录投诉处理的全过程、原因、处理方案、责任划分、改进计划和改进方案；
c）运维经理发布投诉处理报告并归档，接收对象包含但不限于投诉人、上级领导、承担相关责任者；若本次投诉的内容、处理方法和改进方案有借鉴和推广价值，可抄送给其他人员；
d）运维经理对处理过程中有参考价值的信息进行总结，作为知识条目提交知识库。
6.2 供应商风险管理
6.2.1 目的
供应商风险管理的目的是规范信息科技外包活动，加强信息科技服务提供商风险管控，保障业务安全稳定运营。
6.2.2 范围
供应商风险管理适用于原本由自身负责处理的信息科技活动委托给服务提供商进行处理的行为，包括咨询规划、运行维护、安全服务、业务支持等服务。
6.2.3 总体要求
保险机构应当建立与本机构信息科技战略目标相适应的信息科技外包管理体系，将信息科技外包风险纳入全面风险管理体系，有效控制由于外包引发的风险。供应商风险管理应符合以下要求：
a）自主可控：以不妨碍核心能力建设、积极掌握关键技术为导向，涉及信息科技战略管理、信息科技风险管理、信息科技内部审计及其他有关信息科技核心竞争力的职能不得外包，信息科技管理责任、网络安全主体责任不得外包；
b）风险效益平衡：保障网络和信息安全，加强重要数据和个人信息保护，强调事前控制和事中监督，保持外包风险、成本和效益的平衡；
c）持续改进：持续改进外包策略和风险管理措施。
6.2.4 供应商风险管理要求
6.2.4.1 管控策略
保险机构应制定明确的供应商风险管控策略。供应商风险管理的管控策略应符合以下要求：
a）信息科技外包活动和报送工作应符合保险监管机构的相关要求；
b）应制定信息科技能力建设方案，通过补充内部人员，调整内外人员比例、提升内部人员技能、知识转移等方式，有针对性地获取或提升内部管理和技术能力，降低对供应商的依赖；
c）信息科技外包的供应商管理应符合保险监管机构要求，并通过信息科技外包准入和退出机制，合理控制高风险服务提供商的数量，防范行业垄断和集中度风险的外包服务；
d）信息科技外包活动应引入适当的竞争机制，降低采购成本，提升服务质量；
e）信息科技外包活动及相关供应商应区分重要外包和一般外包，并进行分级和差异化管理；
f）对于人力资源外包，应优先采用驻场人力外包；
g）原则上不使用跨境外包、同业外包，如因业务发展确实需要使用的，应经过充分的风险评估并通过公司外包风险决策机构的审议，管理活动还应满足各类监管要求；
h）使用关联外包时不应因关联关系降低外包管理要求；
i）应预判外包终止的可能性，制定外包退出策略。退出策略应至少明确可能造成外包终止的情形、外包终止的业务影响分析、终止交接安排。
对于重要外包应加强风险管控，下列信息科技外包活动原则上属于重要外包：
a）信息科技工作整体外包，仅保留必要的管理团队和核心职能；
b）数据中心（机房）整体外包；
c）涉及基础设施和信息系统整体架构发生重大变化的信息科技外包；
d）核心业务系统开发测试和运行维护的整体外包；
e）信息科技战略规划（含中长期规划）咨询外包；
f）安全运营的整体外包；
g）涉及集中存储或处理公司重要数据和客户个人敏感信息的外包；
h）直接影响实时服务、影响账务准确性的重要信息系统外包；
i）其他对公司业务运营具有重要影响的外包。
6.2.4.2 准入要求
保险机构应根据信息科技外包战略，结合风险评估情况，明确服务提供商的准入要求，对备选服务提供商进行筛选，审慎引入集中度风险较高或增加公司整体风险的服务提供商。
信息科技部门在签订合同前，统筹组织对重要外包的备选服务供应商深入开展尽职调查，必要时可聘请第三方机构协助调查。在服务供应商经营状况未发生重大变化的前提下，尽职调查结果原则上一年内有效。尽职调查应包括但不限于：
a）服务供应商的技术和行业经验，人员及能力；
b）服务供应商的内部控制和管理能力；
c）服务供应商的网络和信息安全保障能力；
d）服务供应商的持续经营状况；
e）服务供应商及其母公司或实际控制人遵从国家和保险监管机构相关法律法规要求的情况；
f）服务供应商过往配合公司或其他银行保险机构审计、评估、检查及监管机构监督检查情况；
g）服务供应商与公司的关联性。
6.2.4.3 监控评价
6.2.4.3.1 保险机构应对外包服务过程进行持续监控，及时发现和纠正服务过程中存在的各类异常情况；应建立明确的信息科技外包服务目录、服务水平协议以及服务水平监控评价机制，确保相关监控信息和评价结果的真实性和完整性，且数据应至少保存到服务结束后三年。
6.2.4.3.2 保险机构应建立服务效能和质量监控指标，并进行相应监控。常见监控指标包括：
a）信息系统和设备及基础设施的可用率；
b）故障次数、故障解决率、故障的响应时间、故障的解决时间；
c）服务的次数、客户满意度；
d）业务需求的及时完成率、程序的缺陷数、需求变更率；
e）外包人员工作饱和率、外包人员的考核合格率；
f）网络和信息安全指标、服务连续性指标。
6.2.4.3.3 保险机构应对服务提供商的财务、内控及安全管理进行持续监控，关注其因破产、兼并、关键人员流失、投入不足和管理不善等因素引发的财务状况恶化及内部管理混乱等情况，防范外包服务意外终止或服务质量急剧下降。
6.2.4.3.4 监控到信息科技外包服务出现异常情况时，保险机构应及时督促服务供应商采取纠正措施，情节严重的或未及时纠正的，应当及时约谈服务供应商高管人员并限期整改。对于逾期未整改的服务供应商应当暂停或取消其服务资格，并向保险监管机构或其派出机构报告。
6.2.4.3.5 在信息科技外包服务到期前，保险机构应就是否继续外包、原服务供应商是否满足后续合作要求等事项进行评估决策。对具有持续性特点的外包服务，终止外包或更换服务供应商，应及时制定周密的退出和交接计划。
6.2.4.4 风险管理
6.2.4.4.1 保险机构应建立并持续完善风险管理制度和流程，应充分识别并评估信息科技外包可能产生的风险，包括但不限于：
a）科技能力丧失：过度依赖外包导致失去科技控制及创新能力，影响业务创新与发展；
b）业务中断：支持业务运营的外包服务无法持续提供导致业务中断；
c）数据泄露、丢失和篡改：因服务供应商的不当行为或其服务的信息系统遭受网络攻击，导致保险机构重要数据或客户个人信息泄露、丢失和篡改风险；
d）资金损失：因服务供应商的不当行为或其服务的信息系统遭受网络攻击，导致保险机构客户资金被盗取风险；
e）服务水平下降：由于外包服务质量问题或其内外部协作效率低下，使得保险机构信息科技服务水平下降；
f）可能导致的战略、声誉、合规等风险。
6.2.4.4.2 保险机构应事先针对可能对服务连续性管理造成重大影响的重要外包服务建立风险控制、缓释或转移措施，包括但不限于以下内容：
a）事先制定退出策略和供应链安全保障方案，在外包服务实施过程中持续收集服务供应商相关信息，尽早发现可能导致服务中断或服务质量下降的情况；
b）明确措施和方法，在服务供应商服务质量不能满足合同要求的情况下，保障获取其外包服务资源的优先权；
c）要求服务供应商提供必要的应急和灾备资源保障，制定应急处理预案并在预案中明确为公司提供应急响应和恢复的优先级，原则上应为最高级；
d）组织服务供应商参与应急计划编制和应急演练，至少每年在综合性演练或专项演练中纳入一个或多个服务供应商开展一次相关演练；
e）需考虑预先在内部配置相应的人力资源，掌握必要的技能，以在外包服务中断期间自行维持最低限度的服务能力。
6.2.4.4.3信息科技部门应制定和落实网络和信息安全管控措施，包括但不限于以下措施：
a）对服务供应商和外包人员进行信息安全教育或培训，增强网络和信息安全意识；
b）明确外包活动需求访问或使用的信息资产，按“必须知道”和“最小授权”原则进行访问授权，严格管控远程维护行为；
c）严格控制服务供应商和外包人员进入安全区域，如需进入应得到适当的批准，其活动也应受到监控。针对长期或临时聘用的技术人员和承包商，尤其是从事敏感性技术相关工作的人员，应制定严格的审查程序，包括身份验证和背景调查；
d）对信息系统开发交付物（含拥有知识产权的源代码）进行安全扫描和检查；
e）对客户信息、源代码和文档等敏感信息采取严格管控措施，对敏感信息泄露风险进行持续监测；
f）对服务供应商所提供的模型、算法及相关信息系统加强管理，确保模型和算法遵循可解释、可验证、透明、公平的原则；
g）定期对外包活动及服务供应商进行网络和信息安全评估。
6.2.4.4.4信息科技部门应识别对公司具有集中度风险的外包服务及其供应商，积极采用分散信息科技外包活动、提高自身研发运维能力、储备潜在替代服务供应商等形式，减少对个别外包服务供应商的依赖，降低集中度风险。
6.2.4.4.5信息科技部门应组织对符合重要外包标准的非驻场集中式外包服务进行实地检查。
6.2.4.4.6信息科技部门应定期开展全面的信息科技外包风险管理评估，并形成评估报告。
7、控制过程
7.1配置管理
7.1.1目的
配置管理的目的是更好地识别、定义、控制、维护和审核应用与基础设施组件及其相关架构、关联关系、参数设置和运行状态等配置项信息，并保持其信息准确，为信息服务管理提供精确的数据支撑，并向其他管理流程提供相关信息和支持。
7.1.2范围
配置管理适用于与信息服务有关的配置项管理活动，包括桌面硬件、计算机辅助设备、基础网络、各类应用系统等。
7.1.3总体要求
保险机构应建立配置管理流程，统一管理、及时更新数据中心基础设施和重要信息系统配置信息，支持变更风险评估、变更实施、故障事件排查、问题根源分析等服务管理流程。配置管理应符合以下要求：
a）统一数据：配置管理数据库信息服务管理的权威基础数据，统一登记信息资源的基本信息，为所有信息系统运行、监控及服务管理流程提供所需信息；
b）数据一致：配置管理数据库应准确反映当前信息系统架构状态，配置项应与实际环境的对应实体保持一致；
c）权限控制：只有得到适当授权的人员才能对配置管理数据库中的配置项信息进行人工修改，除自动采集外，对配置管理数据库的修改应遵循变更管理流程；
d）持续改进：通过定期回顾与数据审核，确保配置项数据和配置管理活动得到持久和有效的控制，避免违规操作，提升运行效率。
7.1.4配置管理流程
7.1.4.1规划和改进
配置管理的规划和改进应符合以下要求：
a）配置经理负责配置管理规划，确定配置管理的范围和分类，制定配置模型和命名规则，并识别其他运维管理流程对配置数据的需求；
b）配置经理组织发起配置管理数据库的初始化，并组织对配置审计发现的问题进行优化改进；
c）配置管理员负责对配置项实体的识别和导入，负责对配置项实体属性信息的收集和核查；
d）配置管理员负责整理和制作典型的配置消费场景，描述配置数据、功能接口和其他流程的关系。配置规划应满足以下策略：
a）配置项应被唯一地识别，并记录在配置管理数据库中；
b）配置项属性、配置项关系应明确维护职责；
c）配置管理应提供基础设施及其组件的识别、控制和追溯版本的机制；
d）配置管理应为变更管理、事件管理、服务请求管理等流程提供完整、准确的配置信息；
e）应主动管理并验证配置信息，以确保配置信息的可靠性和准确性，需要的人员可以获得配置项的状态、版本、位置、相关的变更、问题以及文档；
f）配置信息审计应包括记录偏差、发起纠正措施和报告的内容；
g）配置管理应结合变更和发布管理进行计划和实施；
h）可采取一定的自动化手段确保配置信息的准确性和配置管理流程的有效性。
7.1.4.2 识别和控制
7.1.4.2.1 配置管理数据库的更新请求主要来源于：
a）配置管理数据库初始化；
b）服务设计和转化流程，应对服务目录中新增、变更或撤销的服务的配置信息进行更新；
c）事件、变更、发布或服务请求管理流程对配置项实体或配置模型的增、删、改操作引发的配置信息更新；
d）配置信息验证或配置审核，对配置信息账实不符情况的修正；
e）服务管理策略、组织架构的调整或人员变动，对配置模型或配置项实体的管理属性的更新需求，如运维责任人、服务水平要求等。
7.1.4.2.2在配置管理数据库初始化过程中，配置管理员根据配置项范围和识别策略，对现有配置项或新的配置项进行识别，确定是否属于当前管理范围，继而确定配置项所属的分类。配置管理员应根据配置管理数据库模型定义不同类型的配置信息收集模板，以便运维经理收集数据并填写。如有自动采集等技术手段，可通过技术手段进行数据初始化。
7.1.4.2.3 在服务设计和转化过程中，运维经理应按照配置项生命周期或技术规格特点定义配置基线，规定配置项各个生命周期所必备的配置项属性及关系，以及生命周期转换的流程要求。
7.1.4.2.4 在事件、变更、发布或服务请求等日常运维过程中，运维经理和配置管理员应按流程管控要求及时更新配置信息：
a）变更管理、发布管理：变更或发布成功实施后，需更新配置信息；
b）事件管理：当事件解决方案涉及配置修改时，需更新配置信息；
c）服务请求：资源交付、配置信息整改等相关服务办理时，需更新配置信息。
d）配置信息应作为运维流程必要要素记录在运维工单中，并作为运维流程办理、流转的必要依据。
7.1.4.3 验证和审计
配置审计有两种触发条件：基于时间的触发和基于场景的触发。
a）基于时间的触发条件是每年定期进行配置审计，审核和验证配置项及其属性和关系等信息，确保配置管理数据库的正确性和完整性。该工作由配置经理发起，由配置管理员负责具体执行；
b）基于场景的触发条件包括：新系统上线、服务迁移、服务供方的变化、服务撤销或系统下线、发生重大事件、组织架构的调整、人员换岗或离职等。
可以采用抽样的方式对配置项进行审核，每次审核选择多个配置项类别，按照一定的抽样比例抽取样本进行审核。在审核前将所有需要审核的配置项信息导出，并将审核状态设置为“未审核”，根据审核的结果，将审核状态设置为“匹配”、“不匹配”或者“丢失”，同时记录审核时间。对审核状态为“不匹配”或者“丢失”的配置项进行纠正后，将其审核状态修改为“匹配”。对配置项账实不符的情况，配置管理员应判断出现差异的原因。在审核工作结束后，应出具审核报告并提供给相关方。
7.2 变更管理
7.2.1 目的
变更管理的目的是减少变更对服务水平的影响，控制变更风险，提升变更质量。
7.2.2 范围
变更管理适用于生产环境应用系统和基础环境所涉及的变更。对于应用系统变更，包括应用服务重启、应用参数配置等，但不包含涉及应用程序代码、业务流程规则的调整，此类变更应遵从发布管理流程。对于基础环境变更，包括但不限于网络资源、硬件设备、平台软件、机房基础设施等基础环境的变更。
7.2.3 总体要求
保险机构信息科技部门应建立重要信息系统变更管理机制、制度与流程，承担技术管理工作，协调业务、管理部门开展重要信息系统变更工作，保障信息科技资源投入。业务、管理部门应配合信息科技部门开展变更工作，进行业务影响分析，组织用户测试，保证业务资源投入。变更管理应符合以下要求：
a）业务影响最小：按照对业务影响最小原则，采取与风险程度相适应的变更策略；
b）风险效率平衡：充分考虑“风险”和“效率”的平衡，通过对变更的充分评估和审核，降低变更的风险，对不同类型的变更在流程或审批路径上区别对待，以达到高效的目标。
7.2.4 变更分类与分级
7.2.4.1 变更分类
信息系统变更可根据变更对象所属运维板块进行分类，如可将变更类别划分为应用系统变更和基础环境变更。应用系统变更包括应用服务、应用组件等变更，基础环境变更包括数据库、虚拟化、操作系统、存储、网络、机房等变更。
7.2.4.2 变更分级
7.2.4.2.1 风险评估模型
根据变更的风险程度，预先定义变更风险评估模型，量化风险等级。可根据风险等级的大小，将变更分为重大变更、常规变更、标准变更。
变更风险评估模型可参考如下两个维度定义：
a）变更失败的影响：从变更失败对信息系统可用性的影响进行评估；
b）变更失败的可能性：对变更方案的技术复杂度进行评估。
7.2.4.2.2 重大变更
变更失败的影响很大、变更失败的可能性很高的变更应列为重大变更进行重点管理。
重大变更应至少包括如下内容：
a）支撑重要信息系统运行的机房和网络基础设施变更；
b）影响全辖或一个（含）以上省级分支机构系统服务、重要业务中断时间3小时（含）以上的重要信息系统以及支持其运行的基础设施变更，包括机房场地迁移、网络及核心业务系统应用架构变更等；
c）其他对保险重要业务运营及重要信息系统的可用性、完整性、安全性具有较大潜在影响的变更。
7.2.4.2.3 常规变更
变更失败的影响中等、变更失败的可能性中等的变更应列为常规变更进行日常管理。
7.2.4.2.4 标准变更
变更失败的影响很小、变更失败的可能性很低的变更应列为标准变更，标准变更应减少审批环节，提高流程效率。
7.2.4.2.5 紧急变更
根据变更的紧急程度，可将变更分为紧急变更、非紧急变更。紧急变更原则上由事件管理流程触发。保险机构应对紧急变更的次数进行有效控制，提高变更管理的计划性和风险管控能力。
7.2.5 变更管理流程
7.2.5.1 发起与准备
变更管理流程触发条件包括：
a）事件或问题流程解决方案涉及配置项内容变更或对应用系统有影响需进一步评估风险；
b）服务请求需变更操作才能履行；
c）巡检结果异常时，需采取变更操作进行预防性处理；
d）发布流程需配套实施基础环境部署；
e）风险整改、资源和架构优化方案涉及配置项内容变更；
f）计划内的应急预案演练、例行维护等变更；
g）第三方（如运营商等）实施的变更，对组织应用系统有影响，需进行变更评估、配合验证等操作。
应用系统或基础环境技术板块运维岗作为变更发起人创建变更工单，应符合以下要求：
a）变更发起人负责收集必要的变更信息创建变更工单，如变更来源、变更原因、变更类型、变更对象等；变更流程需由其他相关流程作为前导流程，并关联相关流程工单；
b）变更发起人根据变更风险评估模型，对变更风险程度进行初步计算，并对变更进行初步定级；
c）实施频次较高的变更应建立变更模型，规范化管理变更要素和方案，使之可重复使用，提高变更效率。对于有变更模型的变更，变更发起人可根据变更模型拟定变更方案和计划。对于无变更模型的变更，变更发起人负责制定变更方案和计划；
d）变更方案应包含实施方案、配合方案、回退方案、验证方案、计划实施时间等，涉及灾备同步变更的应制定灾备环境变更方案和计划，涉及重要信息系统变更的应制定应急预案，必要时应实施演练；变更方案的每一步骤均应明确岗位职责，确保关键岗位职责分离；
e）变更方案原则上应在测试环境进行充分、完整的测试，测试环境应模拟生产环境的真实情况并与生产环境相隔离，测试结果应经过相关团队确认，并形成测试和验收报告，确保变更后系统正常稳定运行以及变更结果与业务目标的一致性；
f）对涉及重要信息系统的变更，应加强数据管理。测试环境中使用的敏感生产数据应进行脱敏、变形处理；需要历史数据迁移的，应制定详细的数据迁移计划，并提前进行数据迁移测试和数据有效性、兼容性验证，确保迁移后数据的完整性、安全性和可用性；
g）对变更对象有服务依赖关系的系统或设备的屏蔽告警、配合操作、服务启停、服务验证，应在同一个变更单内实施；对变更对象无服务依赖关系的系统或设备的操作，不应包含在同一变更中，应单独发起变更；
h）应针对不同类型的变更制定变更窗口规则，减小对服务水平的影响。变更窗口包括变更实施、验证、回退，以及灾备同步变更的时间，变更计划时间窗应满足基准变更窗口规则。变更窗口规则应合理避开业务高峰期和敏感时段；
i）应针对不同类型的变更制定前导时间规则，明确从提交变更到变更实施之前所需要进行评估、审核等准备活动应遵循的最少时间，以保证有充分的时间进行评估和制定计划。变更发起时间应满足变更前导时间规则。紧急变更不受前导时间规则限制，紧急变更建单后直接提交变更审批，非紧急的变更建单后进入变更评估环节。
7.2.5.2 变更评估
保险机构应安排专岗或有别于变更发起岗位的其他岗位作为变更评估岗，对变更进行充分的识别、分析和评估。变更评估从以下方面进行：
a）合规检查：检查变更请求填写的完整性、准确性、一致性，并对变更级别进行评估、调整和确认；
b）冲突检查：根据运维日历对多个变更的实施是否存在时间或逻辑冲突进行检查；
c）技术评估：检查变更方案的技术可行性；
d）风险评估：评估变更所造成的影响和存在的风险，包括业务中断、交易缓慢、客户信息泄露或其他因素可能造成的操作风险。若变更发起人初步影响评估未全面覆盖受影响方，评估人应组织所有受影响方补充配合或验证方案，并明确配合或验证人。对于重大变更，应形成风险评估报告，提交上级领导层审批。针对风险评估中发现的薄弱环节，应制定整改方案，明确整改时间，不具备整改条件的应采取风险缓释措施；
e）灾备同步：检查变更是否需灾备同步实施，如需要则对灾备环境实施方案进行评估。
经评估可实施的变更提交下一环节处理。已获得预授权的标准变更，评估后即可到达实施环节等待变更时间窗。常规变更和重大变更评估通过后，进入变更审批环节。
7.2.5.3 变更审批
变更审批人应由保险机构内部人员担任。常规变更可由应用系统或基础环境技术板块运维经理进行审批；重大变更由运维经理初审后，提交专家团队审批，必要时可提交上级领导层审批；紧急变更可由变更发起人所在机构的负责人进行审批。变更审批人根据变更影响、风险、窗口等情况确认是否批准变更。
变更审批通过后，变更发起人应更新运维日历。应用系统运维岗根据运维日历及变更受影响情况判断是否需要通知用户。涉及互联网业务系统的变更，应将可能对服务的影响提前告知客户。
7.2.5.4 变更实施
应用系统或基础设施技术板块运维岗作为变更实施人严格、审慎执行变更实施方案，保险机构应安排变更复核人员对变更实施人的操作进行监督与复核，避免操作失误和非法操作。信息科技部门应加强重要信息系统变更过程的风险监控和预警，协调相关部门做好应急准备。
变更实施应符合以下要求：
a）变更实施前，变更实施人应核实变更计划和变更方案相关条件是否发生变化；如发生变更需求取消、变更方案需修改或资源准备不足等情况，应取消变更，并通知相关人员，主动释放变更占用的资源，注明变更取消原因并关闭变更工单；
b）变更实施过程中，变更实施人组织各方按照变更方案完成变更准备、变更实施、变更验证等操作；当遇到变更实施失败，或到达回退时间点没有按照计划实施完成，需要进行变更回退操作，将服务恢复到变更前状态或可用状态，并消除相关影响，回退的变更将作为变更失败而关闭；当遇到变更实施失败或回退异常引发了计划外服务影响时，变更实施人应新建事件工单，并与当前变更工单进行关联；
c）涉及服务器后台操作的变更应确保通过堡垒机进行操作，保障生产网与开发测试网的有效隔离，严格管控运维操作用户权限，实现对关键岗位、异常操作等高风险因素的记录；
d）宜采用自动化手段和工具进行变更操作，减少人工操作风险，提高变更工作效率；所采用的自动化工具应满足自主可控要求；
e）涉及进入物理机房作业的变更，变更复核人员应现场陪同变更实施人进入机房，确保双人临岗，一人操作，一人复核；
f）变更实施完成后，变更实施人应组织相关岗位人员对变更的有效性进行验证，详细记录实施结果和验证结果，并通过巡检或监控系统观察记录变更影响，关联与此次变更有关的事件、问题；变更实施人员应通知配置管理员及时更新相关配置信息；
g）生产环境变更后，经观察系统运行正常的，原则上应在一个工作日内完成灾备环境变更工作。
7.2.5.5 回顾与关闭
在变更回顾与关闭环节，运维经理应对变更进行回顾，并提出后续改进建议。变更回顾应包括实施方案的合理性、验证方法的有效性、实施结果和配置项更新的准确性、变更资料的完整性、变更引起的事件等内容。未达到预期目标的变更，应复盘分析原因并制定后续改进计划。运维经理可视变更方案、变更实施过程中的经验教训等内容是否具有代表性和可复用性向知识库提交知识。涉及重要信息系统的变更，应及时更新各项相关应急预案，并适时实施演练。
保险机构信息科技部门应定期审计堡垒机操作日志，及时排查非法操作行为。
7.2.6 变更报告
对于重大变更，保险机构应根据监管要求进行上报。报告规则应至少包含如下内容：
a）在重要信息系统变更实施前至少10个工作日向保险监管机构或其派出机构报告，并在变更实施后1个月内提交总结报告材料；
b）在数据中心规划筹建阶段，以及在数据中心正式运营前至少20个工作日，向保险监管机构或其派出机构报告；
c）变更数据中心场所时应至少提前2个月，其他重大变更应至少提前10个工作日，向保险监管机构或其派出机构报告。
8、发布过程
8.1 发布管理
8.1.1 目的
发布管理的目的是规范应用系统的部署、发布和投产工作，提升信息服务交付效率，控制交付风险，强化研发、测试、运维协同。
8.1.2 范围
发布管理适用于所有涉及应用系统生产环境版本变化的变更。
8.1.3 总体要求
保险机构应建立信息系统投产管理机制、制度与流程，特别是对于支撑业务运营的重要信息系统应加强技术管理，协调业务、管理部门开展信息系统投产工作，保障信息科技资源投入。业务、管理部门应配合信息科技部门开展投产工作，进行业务影响分析，组织用户测试，保证业务资源投入。发布管理应符合以下要求：
a）业务影响最小：按照对业务影响最小原则，采取与风险程度相适应的发布策略；
b）安全可控：采取有效的信息安全控制措施，确保生产环境操作安全；
c）自动化导向：保险机构可充分利用自动化方法进行软件版本的编译、测试、准入、安全扫描、生产部署和发布，确保流程的可重复性，提高版本发布效率。
8.1.4发布分类与分级
保险机构应根据自身业务特点和信息系统架构，对发布进行分类分级管理，并定义重要信息系统变更。发布的分类和分级可参考如下维度：
a）应用系统所承载的业务重要性，如核心业务、重要业务、一般业务、其他；
b）应用系统架构，如稳态架构、敏态架构；
c）发布对业务功能和可用性的影响，如是否为应用系统首次上线、发布过程是否中断业务服务、应用程序架构设计是否发生变化、应用程序功能是否发生重大变化、应用程序的使用范围是否变化等。
保险机构应对重要信息系统的版本变更、应用架构变更加强管理。
8.1.5 发布管理流程
8.1.5.1 发起与准备
生产环境软件版本发布流程作为衔接信息系统开发、测试流程的后续流程，应遵循统一、完善的版本管理制度，经过严格的测试流程并通过测试后，方可发起生产环境发布流程。保险机构应建立与生产环境相隔离的测试环境，测试环境应模拟生产环境的真实情况，测试环境中使用的敏感生产数据应进行脱敏、变形处理。软件版本测试结果应经过信息科技部门和相关业务部门确认，并形成测试和验收报告，需要历史数据迁移的，应制定详细的数据迁移计划，并提前进行数据迁移测试和数据有效性、兼容性验证，确保版本上线后的正常稳定运行以及系统功能与业务目标的一致性。
对于稳态架构系统，版本质量经理可为软件版本管理人员；对于敏态架构系统，可由流水线自动触发。发起发布流程时，应提供必要的版本信息，包括版本号、是否涉及数据库结构变更、操作手册、回退方案、关联系统版本信息、需求信息表等。业务部门对需求上线时间有特殊要求的，应在版本信息中明确。重要信息系统发生重大服务变化时，发布方案应对服务连续性进行评估，包括灾备方案、应急预案的修改等，必要时应实施演练。发布方案的每一步骤均应明确岗位职责，确保开发和运维过程独立、人员分离。必要时，可由版本质量经理组织开发经理对用户开展业务培训，对运维岗开展技术培训。
8.1.5.2 方案评估
在方案评估环节，应用系统运维岗作为发布评估人根据版本信息进行评估。方案评估从以下方面进行：
a）合规检查：检查版本信息填写的完整性、准确性、一致性，包括发布手册是否完备清晰、是否有回退方案、是否有性能测试、是否有回退测试等；
b）依赖检查：检查依赖版本是否已完成生产环境升级；若未完成，应与依赖版本升级实施负责人沟通，协调统一时间同步升级；
c）时间确认：根据运维日历确定生产环境发布上线时间，原则上应在确保服务连续性的情况下尽早完成生产发布，提高需求交付效率；中断业务服务的发布，原则上应在非业务时段或业务相对最少时段实施，以减小发布对业务服务的影响；
d）风险评估：应充分识别、分析、评估发布风险，包括系统功能缺陷、客户信息泄露、业务中断、交易缓慢或其他因素可能造成的操作风险；对于重大发布，应形成风险评估报告，提交上级领导层审批；针对风险评估中发现的薄弱环节，应制定整改方案，明确整改时间，不具备整改条件的应采取风险缓释措施；业务规模大、影响范围广的信息系统应具有灰度发布能力，并支持发布熔断，出现问题时可将影响控制在最小范围；
e）资源检查：检查当前已有人员、技术、设备等资源是否满足发布方案，如果不满足，则进行相应的资源申请，如防火墙开通、数据准备等工作。
8.1.5.3 方案审批
发布经理作为发布管理的审批授权人，结合评估结果确认是否批准发布。新服务或者重大服务发布前，应组织专家团队进行发布前评审，再次确认发布前准备工作的完善性。发布前评审包括但不限于以下活动：
a）应确认检查测试报告无重大缺陷，明确测试报告中的风险评估结果，并确认风险可接受；
b）评估应用软件或版本上线带来的影响，确认采取的措施能够消除负面影响或负面影响可被接受；
c）评审部署方案，确保部署方案中的操作步骤准确、技术人员到位、相关方沟通到位等；
d）确认上线后的保障工作，如安排运行保障人员等；
e）确认运维岗为此次发布做好准备。
方案审批通过后，应用系统运维岗应更新运维日历，并根据运维日历及服务受影响情况判断是否需要通知用户。涉及互联网业务服务变更的，应将可能对服务的影响提前告知客户。
8.1.5.4方案实施
应用系统运维岗作为发布实施人按照发布手册实施，并记录发布结果、观察发布影响。保险机构应安排发布复核人员对发布实施人的操作进行监督与复核，避免操作失误和非法操作。信息科技部门应加强重要信息系统发布过程的风险监控和预警，协调相关部门做好应急准备。
发布管理的方案实施应符合如下要求：
a）发布实施前，实施人应核实发布计划和方案是否发生变化；如发生紧急叫停、需求取消、资源准备不足等情况，应取消发布，并通知相关人员，主动释放占用的资源，注明发布取消原因并关闭发布工单；
b）发布实施过程中，实施人严格按照发布手册完成准备、实施等操作，并与开发项目组充分沟通，共同解决技术问题，提升工作效率；实施过程应确保双人临岗，一人操作，一人复核；当遇到实施失败，或到达回退时间点没有按照计划实施完成，需要进行回退操作，将应用系统恢复到发布前版本或可用状态，并消除相关影响；回退的发布将作为发布失败而关闭；当遇到发布失败或回退异常引发了计划外服务影响时，实施人应新建事件工单，并与当前发布工单进行关联；
c）发布实施应确保通过堡垒机进行操作，保障生产网与开发测试网的有效隔离，严格管控运维操作用户权限，实现对关键岗位、异常操作等高风险因素的记录；
d）宜对应用系统进行分布式架构改造，并采用Devops工具开展生产发布工作；Devops平台应及时识别并处理分布式技术开发中的风险点，加强对分布式架构下大规模应用集群运维的管理；所采用的Devops工具应满足自主可控要求；
e）发布实施完成后，应进行充分的业务验证，确保检查操作覆盖关键业务节点，及时发现版本问题，减少发布对用户的影响；实施人应在发布工单中详细记录实施结果，关联与此次发布有关的事件、问题；发布实施人员应通知配置管理员及时更新相关配置信息；必要时更新服务目录，如添加新服务、删除失效的服务、更新有变化的服务等；
f）生产环境发布后，经观察系统运行正常的，原则上应在一个工作日内完成灾备环境发布升级工作。
8.1.5.5 回顾与关闭
在回顾与关闭环节，发布经理检查发布实施记录，对未达到预期目标的发布应复盘查明原因，制定后续行动计划。在版本发布后3天内，应结合监控数据，对与发布相关的事件、问题进行测量和分析，以评估对业务、运营和支持人员的影响，必要时可制定服务改进计划。涉及重要信息系统的变更，应及时更新各项相关应急预案，并适时实施演练。
保险机构信息科技部门应定期审计堡垒机操作日志，及时排查非法操作行为。
8.1.6发布报告
保险机构应在重要信息系统首次上线或重大版本发布实施前至少10个工作日向保险监管机构或其派出机构报告，并在发布实施后1个月内提交总结报告材料。
9、解决过程
9.1 事件管理
9.1.1 目的
事件管理的目的是规范事件流程中各环节活动，快速处置信息系统运行中的突发事件，及时恢复业务和服务水平，提高系统稳定性，确保服务连续性。
9.1.2 范围
事件管理适用于保险业务日常运营中，任何原因导致的业务服务中断、服务品质下降、用户服务体验下降或可能导致服务水平降低的故障的处置过程，但不包括用户侧环境或用户自身操作引起的问题。
9.1.3 总体要求
保险机构应制定应对信息系统相关的突发事件管理制度，与服务连续性管理、信息科技风险管理、网络安全管理等制度有效衔接，明确组织管理、流程和应急预案等工作要求，及时启动应对预案，健全风险管理，确保基本业务服务功能的安全性和连续性。事件管理应符合以下要求：
a）常态管理：建立信息系统突发事件应对工作机制，并将突发事件应对管理纳入全面风险管理体系；
b）及时处置：使用技术手段尽早发现系统运行异常，及时启动应对预案，制定科学的应急措施、调度所需资源；
c）最小影响：以快速恢复业务为首要目标，采取必要措施将突发事件对业务连续运行的影响控制在最小程度，确保持续提供基本业务服务；
d）分类分级：保险机构应根据自身业务特点和信息系统架构对事件进行分类分级管理，预先定义事件级别和类别，明确不同级别和类别事件的响应要求和处置流程，优先处理对业务影响较大的事件，降低潜在损失。
9.1.4 事件分类与分级
9.1.4.1 业务重要性参考定义
根据业务的重要性，可将信息系统的业务级别定义为核心业务、重要业务、一般业务、其他。
a）核心业务：核心业务发生事件，影响服务连续性、造成损失、影响公司形象，如线上化承保业务、线上化理赔业务、影像系统、保险产品中心等；
b）重要业务：重要业务发生事件，影响核心业务稳定性、造成部分用户不能使用重点业务，如支撑线上化业务的销售管理、用户管理、数据处理等系统；
c）一般业务：一般业务发生事件，影响重要业务稳定性，不影响核心业务稳定性，如数据清分、数据分析类系统；
d）其他：其他业务发生事件，不直接影响业务可用性，如内部协同办公、需求管理、开发管理、运维管理等系统。
9.1.4.2 事件分类参考定义
事件分类可围绕可用性进行分类，如配置变更类、安全类、网络类、三方类、突发流量类等。
a）配置变更类：由于代码上线，或数据库、服务器、网络、脚本等配置变更导致的事件；
b）安全类：由于程序漏洞导致数据泄露、DDOS攻击等；
c）网络类：由于运营商网络故障导致业务无法访问等；
d）三方类：由于三方服务异常导致业务不可用，如支付平台、云服务商等；
e）突发流量类：由于突发事件、社会热点、业务促销活动流量预估不足导致业务不可用等。
9.1.4.3 事件级别参考定义
事件级别可根据业务重要性、业务影响程度、业务影响范围、持续时间、发生时间段等因素定义，可从可用性、安全、资产损失、用户体验等不同维度进行定义。事件级别应随着故障时长的增长而升级。
事件级别可定义为特别重大事件、重大事件、较大事件、一般事件。各级别事件参考定义如下：
a）特别重大事件：
·重要信息系统服务中断，或重要数据损毁、丢失、泄露，造成经济秩序混乱或重大经济损失、影响金融稳定，或对公众利益、社会秩序、国家安全造成特别严重损害的事件；
·由于重要信息系统服务异常，在业务服务时段导致两个（含）以上省（自治区、直辖市）业务无法正常开展达3个小时（含）以上，或一个省（自治区、直辖市）业务无法正常开展达6个小时（含）以上的突发事件；
·业务服务时段以外，重要信息系统出现的故障或事件救治未果，可能产生上述故障的突发事件；
·国家秘密信息、重要敏感信息和关键数据丢失或被窃取、篡改、假冒，对国家安全、社会秩序、经济建设和公众利益构成特别严重威胁、造成特别严重影响的网络安全事件。
b）重大事件：
·由于重要信息系统服务中断或重要数据损毁、丢失、泄露，对保险或客户利益造成严重损害的突发事件；
·由于重要信息系统服务异常，在业务服务时段导致两个（含）以上省（自治区、直辖市）业务无法正常开展达半个小时（含）以上，或一个省（自治区、直辖市）业务无法正常开展达3个小时（含）以上的突发事件；
·业务服务时段以外，出现的重要信息系统故障或事件救治未果，可能产生上述故障的突发事件；
·国家秘密信息、重要敏感信息和关键数据丢失或被窃取、篡改、假冒，对国家安全、社会秩序、经济建设和公众利益构成严重威胁、造成严重影响的网络安全事件。
c）较大事件：
·由于重要信息系统服务中断或重要数据损毁、丢失、泄露，对保险或客户利益造成较大损害的突发事件；
·由于重要信息系统服务异常，在业务服务时段导致一个省（自治区、直辖市）业务无法正常开展达半个小时（含）以上的突发事件；
·业务服务时段以外，出现的重要信息系统故障或事件救治未果，可能产生上述故障的突发事件；
·国家秘密信息、重要敏感信息和关键数据丢失或被窃取、篡改、假冒，对国家安全、社会秩序、经济建设和公众利益构成较严重威胁、造成较严重影响的网络安全事件。
d）一般事件：
·除上述情形外，其他一般业务功能不可用、造成部分资产损失、造成部分用户体验变差的突发事件，或对国家安全、社会秩序、经济建设和公众利益构成一定威胁、造成一定影响的网络安全事件。
9.1.5 事件管理流程
9.1.5.1 事件识别与报障
事件可通过监控系统主动发现，也可由运维岗、开发岗、测试岗在日常信息服务过程中发现，或来自信息系统内外部用户向IT服务台的报告。保险机构应建立7×24小时的IT服务台，接收电话报障或即时通信工具报障。事件报告人或监控系统建立事件工单，识别并报告事件基本信息，包括受影响系统、影响范围和影响类型等信息。在对事件进行记录时，应避免对同一时间点发生、根本原因相同的事件进行重复记录。
保险机构应建立与服务连续性相适应的监控体系，监控并记录应用系统、网络链路、基础设施、网络安全态势、云平台、物理机房环境等运行状态，及时发现故障、启动应急，减少或消除用户报告事件，提高事件排查与处置的技术能力。监控体系建设要求包括但不限于：
a）根据业务重要性明确监控配置标准，包括监控对象、指标、告警和执行策略等，并按照分级分类的标准进行监控配置；
b）促进监控工具与事件流程工具的联动、衔接，实现监控告警、自动建单等功能，不断提升事件识别能力；
c）应积极采用智能化算法进行告警降噪、告警压缩和故障预测，减少重复告警事件，避免告警风暴，提升节点感知和异常发现能力；
d）监控工具应具备自主可控能力；
e）信息系统日志应至少留存六个月，且在留存期限内不得删除、修改或者覆盖。
9.1.5.2 事件处置
各应用系统和基础设施技术板块运维岗可根据能力不同分为一线和二线。运维一线为事件的主要处理人员，主要职责为事件的受理、分派、处置、过程记录以及事件的恢复确认。运维二线负责疑难事件处理，主要职责为对疑难事件进行诊断分析、制定处置方案，支持运维一线处置事件。
事件处置环节，运维一线对事件基本信息进行确认，并进行分析和处置。具体工作如下：
a）评估服务影响，合并重复事件，更新影响范围，根据影响程度进行事件升级或降级，并根据事件级别确定处置优先级；
b）定位故障点，参考应急预案或知识进行处置，并在工单中详细记录解决方案和故障原因；如需变更解决，则需提交变更工单；
c）由于应用系统、基础设施之间的关联性，如定位故障点为其他运维板块，则会签相关板块运维岗协查并处置；
d）疑难事件及时升级至运维二线处置；
e）充分运用云计算、大数据、人工智能等新技术，采用自动化、智能化手段进行业务影响分析、故障根因定位和自动化处置，不断加强多场景的协同联动和多节点一体管控，降低人工操作风险，提升事件处置效率。
运维二线对疑难事件进行分析诊断，提出解决方案或临时应急措施，及时恢复业务。如需要其他运维板块会诊，应在第一时间会签相关岗位。必要时可使服务降级，最大限度降低对业务活动的影响，例如通过开关关闭存在故障的功能。
9.1.5.3 恢复确认
恢复确认环节，运维一线与用户确认业务是否恢复，并查看关联工单列表，确认关联工单中受影响系统是否全部恢复。如业务已恢复，则填写恢复时间，确认事件发生时间、现象特征、影响业务或功能、影响范围等各要素的准确性和真实性，并在工单中完善或修订；如未恢复，则退回到事件处置环节继续处理。
9.1.6 应急管理
应急管理是指发生重大业务影响事件时所启动的应急管理机制。应急管理应遵循统一领导、综合协调、分类管理、分级负责的工作原则，持续提升重大事件发生时应急决策和应急组织协同的效率，保证应急预案在真实场景可有效执行，并通过培训、演练等措施不断提升各关键岗位应急处置能力。
保险机构应当建立关键时点的监测与预警机制，在重大业务和社会活动等关键时点，或在业务功能、关键资源发生重大变更时，加强风险监控和预警。业务条线部门与信息科技部门等相关部门之间应当相互通报信息、提示风险，协同做好应急准备。
9.1.6.1 应急处置
当发生重要业务影响事件时，应按照应急预案立即启动应急响应，组建事件应急指挥小组和应急处置小组，评估事件影响，快速分析定位故障原因，根据专业技术经验和资源状况，制定有效的应急举措。应急处置小组按照应急举措快速处置、恢复业务。如确定为灾难性事件，应启动灾难恢复流程。事件应急处置过程中，应急指挥小组应根据实际情况及时调整事件级别，对于调高级别的事件，应按新的事件级别进行应急报告和处置。
保险机构宜建立企业级的、自主可控的社交化工具，并在应急管理中应用，在数据化社交模式中提升根因分析、故障处置、应急决策效率，促进跨业务、跨系统、跨团队的应急协同能力。
9.1.6.2 故障复盘
应急事件恢复后，应及时组织开展故障复盘工作，全面收集故障的相关信息和数据，包括故障发生的时间、影响范围、影响程度、原因分析、处置过程、对可用性的影响时长等，并形成故障报告。
应急管理的故障复盘应符合以下要求：
a）准确分析和说明故障的根本原因和解决方案，对事件进行最终定级，明确对业务的影响，明确故障责任方；
b）对于未找到故障原因或未根本解决的故障，要启动问题管理流程进一步排查根因，推演复现故障，理清传导过程、技术机理；
c）对事件处置过程时间线进行详细描述和准确回顾，识别存在的风险点并提出整改措施，预防或避免类似故障再次发生。整改措施应明确责任人、完成时间，并由专人定期跟进整改措施进展，确保整改措施有效落实；
d）对处理过程中有参考价值的信息进行总结，形成可持续学习的经验，并作为知识条目提交知识库，以便未来遇到类似故障时快速解决。
9.1.6.3 事件上报
对于重大及以上级别事件，保险机构应根据监管要求进行上报。报告规则如下：
a）发生重大及以上级别事件应在事件发生后1小时内向保险监管机构或其派出机构报告，并于12小时内提交正式书面报告。后续处置进展应及时续报，直至处置结束；
b）涉及信息系统的其他重大操作风险应在5个工作日内，按监管职责归属向保险监管机构或其派出机构报告，并及时续报风险处置情况。
9.2 问题管理
9.2.1 目的
问题管理的目的是加强问题的根源分析和解决，降低突发事件发生概率，提高信息系统运行可靠性。
9.2.2 范围
问题管理适用于运维管理过程中产生的问题，问题来源包括用户报告、事件回顾、可用性分析、监控趋势分析、日常运维主动发现等。
9.2.3 总体要求
保险机构应建立并完善有效的问题管理流程，以确保全面地追踪、分析和解决信息系统问题，并对问题进行记录、分类和索引。问题管理应符合以下要求：
a）分级处置：根据问题等级，将资源优先分配至高等级问题；
b）彻底解决：确定问题根本原因，力争彻底解决问题，消除潜在隐患，防止问题转变成事件重复发生。
9.2.4问题管理流程
9.2.4.1问题识别和记录
信息系统运维岗、开发岗、测试岗作为问题发起人在故障处置、服务分析、风险分析等过程中发现并识别问题，详细记录问题现象和影响，将相关来源工单与问题工单关联。
9.2.4.2问题审派
问题经理审核问题有效性，若为无效问题或重复问题，则关闭问题工单。问题经理根据问题的实际情况调整问题等级，并将问题分派给相应运维岗进行诊断。
9.2.4.3问题诊断和解决
问题所在技术板块相关运维岗作为问题处理人对问题进行分析，查明问题原因并解决问题。
问题管理的问题诊断和解决应符合以下要求：
a）根据问题特征确定是否需其他板块支持，可将工单会签给相应专家会诊；必要时可召集会议，并在问题工单中记录会议结论；
b）疑似程序缺陷问题应及时推送给开发岗、测试岗，并提供应用系统、版本号、问题描述等信息；
c）根据问题原因，制定问题解决方案；如需供应商提供支持服务或技术援助，应向相关人员提供所需的合同和相关信息，并将过程记录在案；
d）对已查明根本原因但不具备解决方案实施条件的问题进行记录，明确应急恢复措施，以便发生相关事件时，能够快速发现并恢复服务；
e）组织实施问题解决方案，若解决方案涉及变更或应用系统升级，则需提交相应工单，并将实施结果记录到问题工单中；问题处理人应确保问题得以解决，必要时可与用户进行确认；
f）信息科技部门应对信息系统问题进行分类分级管理，可参考事件级别定义问题级别；根据问题工单实际解决情况调整问题级别与问题分类；当问题升级时，问题经理协调更多资源协助进行诊断和解决。
9.2.4.4问题评价和关闭
问题发起人验证问题处理结果，对问题处理的满意度进行评价。
问题经理对问题的处理过程进行回顾，根据问题解决情况将解决方案提交知识库，选择问题关闭代码并关闭工单。
附录A（资料性）保险业信息系统运行维护工作规范参考岗位设置
A.1总则
本部分为实施运行维护服务时各参与者所属岗位的划分。为适宜于电子化实现，本部分岗位的划分原则为每个岗位职能最小化。各保险机构可以根据实际情况对其进行增加或修改，或者按照实际需求对岗位进行组合，使实际的运行维护服务提供者具备能够完成其工作的岗位授权。
A.2岗位定义
表A.1提供了实施运行维护服务的参考岗位设置、职责要求和不相容要求。
表A.1 岗位定义表
|
岗位名称 |
职责要求 |
不相容岗位 |
|
运维经理 |
为应用系统或基础设施技术板块的运维负责人，对职责范围内的应用系统或运维技术领域的整体运维绩效负责，可根据机构的实际情况进行设置。 |
开发经理、开发岗测试经理、测试岗 |
|
运维岗 |
为应用系统和基础设施技术板块的运维人员，承担职责范围内的应用系统或运维技术领域的日常运维工作，如服务办理、变更实施、发布实施、风险评估等。运维岗可根据能力不同分为一线和二线，接受本运维领域的运维经理管理。 |
开发经理、开发岗测试经理、测试岗 |
|
开发经理 |
为应用系统软件版本的开发负责人。 |
运维经理、运维岗测试经理、测试岗 |
|
开发岗 |
负责开发软件程序，实现需求功能；提供软件版本信息、发布操作手册；提出软件版本测试申请。 |
运维经理、运维岗测试经理、测试岗 |
|
测试经理 |
为应用系统软件版本的测试负责人。 |
运维经理、运维岗开发经理、开发岗 |
|
测试岗 |
负责对软件版本进行测试，并提供测试报告；负责判断是否满足发布门禁要求；负责提出生产发布请求，并对发布风险进行预警。 |
运维经理、运维岗开发经理、开发岗 |
|
容量经理 |
负责容量监控、容量需求分析，参与容量异常处置；负责制定并定期修订容量计划；负责召集组织容量评审会议；负责对资源进行统筹协调，归集采购需求与交付计划。 |
一 |
|
资源交付岗 |
负责根据容量计划实施容量调整方案。 |
一 |
|
连续性经理 |
负责开展服务连续性和可用性风险分析，制定服务连续性和可用性计划；负责组织服务连续性应急演练；负责对服务连续性、可用性计划执行情况进行回顾，并提出改进策略。 |
一 |
|
信息安全经理 |
负责完善信息安全管理制度和技术体系，制定信息安全管理策略；负责等级保护测评和信息系统定级；负责信息安全审计；负责信息安全风险评估工作。 |
一 |
|
服务台 |
为用户提供基本信息系统服务的专职团队。负责识别、记录、初步分析用户的问题和需求；负责将问题分派给相关运维岗；负责向用户反馈解决结果；负责服务回访、满意度调查。 |
一 |
|
配置经理 |
负责配置规划和改进，组织配置审计工作。 |
一 |
|
配置管理员 |
负责识别和控制配置项，执行配置审计并出具审计报告。 |
一 |
|
变更评估岗 |
负责变更评估工作。 |
一 |
|
版本质量经理 |
负责软件版本质量检查，审批软件版本是否可进行生产发布。 |
一 |
|
发布经理 |
负责确认批准发布，负责组织重大发布前的方案评审；负责回顾发布情况，对未达到预期目标的发布进行复盘，并制定改进计划。 |
一 |
|
问题经理 |
负责审核问题有效性，并分派问题；负责协调资源，协助运维岗对问题进行诊断和解决；负责对问题的处理过程进行回顾。 |
一 |
|
应急指挥小组 |
负责组织指挥重大业务影响事件的应急响应。 |
一 |
|
应急处置小组 |
负责按照应急预案快速处置、恢复业务。 |
一 |
|
专家团队 |
负责对重大变更发布方案进行评审。 |
一 |
附录B（资料性）保险业信息系统运行维护工作规范参考流程图
B.1流程图
B.1.1服务目录管理流程图
服务目录管理流程，如图B.1所示。
图B.1 服务目录管理流程
B.1.2 服务请求管理流程图
服务请求管理流程，如图B.2所示。
图B.2 服务请求管理流程
B.1.3容量管理流程图
容量管理流程，如图B.3所示。
图B.3 容量管理流程
B.1.4风险管理流程图
风险管理流程，如图B.4所示。
图B.4 风险管理流程
B.1.5用户服务流程图
用户服务流程，如图B.5所示。
图B.5 用户服务流程
B.1.6主动服务流程图
主动服务流程，如图B.6所示。
图B.6 主动服务流程
B.1.7投诉管理流程图
投诉管理流程，如图B.7所示。
图B.7 投诉管理流程
B.1.8配置管理流程
配置管理流程，如图B.8所示。
图B.8 配置管理流程
B.1.9变更管理流程图
变更管理流程，如图B.9所示。
图B.9 变更管理流程
B.1.10发布管理流程图
发布管理流程，如图B.10所示。
图B.10 发布管理流程
B.1.11事件管理流程图
事件管理流程，如图B.11所示。
图B.11 事件管理流程
B.1.12问题管理流程图
问题管理流程，如图B.12所示。
图B.12 问题管理流程
参考文献
[1]银行保险机构操作风险管理办法（国家金融监督管理总局令2023年第5号）.2023-12-27
[2]中国银保监会办公厅关于银行业保险业数字化转型的指导意见（银保监办发〔2022〕2号）.2022-1-17
[3]中国银保监会办公厅关于印发银行保险机构信息科技外包风险监管办法的通知（银保监办发〔2021〕141号）.2021-12-30
[4]银行保险机构应对突发事件金融服务管理办法（中国银行保险监督管理委员会令2020年第10号）.2020-9-9
[5]中国银保监会关于印发银行业保险业突发事件信息报告办法的通知（银保监发〔2019〕29号）.2019-6-14