人社业务系统故障应急处置预案

人社业务系统故障应急处置预案1.总则人社业务系统承载着社保缴费、待遇发放、就业登记等高频民生服务，其连续运行直接关系群众切身利益与社会稳定。本预案旨在建立标准化、可量化的故障应急处置机制，通过明确分级响应、场景化处置与闭环管理，确保在系统遭遇突发故障时，技术团队与业务部门能在规定时间窗口内完成故障定位、业务降级与系统恢复，将负面影响降至最低。1.1适用范围本预案适用于人社核心业务系统（含省集中式社保经办系统、公共就业服务平台、人事人才考试系统等）及其依赖的基础设施（服务器、存储、网络、安全设备）发生的突发性故障处置。核心目标为：核心业务系统RTO（恢复时间目标）leq21.2工作原则业务连续性优先：技术处置必须让位于群众办事体验。当技术修复预计超1小时时，必须立即启动线下手工或离线收件降级方案。双线并行处置：故障确认后，技术抢修组与业务保障组必须同时运作，技术组寻找根因，业务组疏导前台群众。数据绝对安全：任何应急处置动作不得以破坏业务数据完整性为代价。严禁为缩短恢复时间强制执行可能导致数据覆盖的failover操作。2.应急组织机构与职责应急组织架构的扁平化与职责的绝对穿透性，是决定30分钟内能否拉起有效防御阵型的唯一前提。指挥部下达指令必须精确到具体操作对象，技术组执行动作必须反馈量化结果。2.1应急指挥部由分管副局长担任总指挥，信息中心主任与政务服务局局长任副总指挥。负责Ⅰ、Ⅱ级故障的全局资源调度、对外信息发布审批及跨部门协调。总指挥拥有跨系统防火墙策略紧急豁免权与业务降级最终裁定权。2.2技术处置组由信息中心系统管理员、DBA（数据库管理员）、网络工程师及核心厂商驻场工程师组成。负责故障排查、系统重启、数据恢复、补丁应用等底层技术操作。技术处置组内部分设网络通信岗、数据库恢复岗、应用中间件岗，各岗必须在10分钟内明确接口人并上线响应。2.3业务保障组由各业务经办大厅主任及业务骨干组成。负责办事大厅现场群众安抚、业务降级方案启动、线下纸质单据收件及事后数据补录。业务保障组必须常备至少500份纸质表单及3套离线单机版录入系统。2.4外部支持组包含云服务商技术支持、核心软件供应商（如东软、易联众等）、网络安全应急响应中心（CERT）技术人员。建立7×24小时直连通讯录，要求外部支持团队在SLA协议约定15分钟内响应，提供远程或现场技术介入。3.风险分析与场景化故障定级故障定级的本质不是统计宕机时长，而是衡量对社会民生服务的阻断烈度，必须按业务影响面进行双维度量化。定级过低会导致资源投入不足，定级过高则引发不必要的应急成本与社会恐慌。3.1风险演化路径人社系统故障的触发往往并非单一节点崩溃，而是伴随连锁反应。典型演化路径如下：数据库慢查询雪崩：月末社保缴费高峰期，并发查询量激增->数据库活跃会话数打满（如Oracle的PROCESS参数达上限）->新连接被挂起->应用中间件（如Weblogic/Tomcat）线程池耗尽->前端Nginx返回504GatewayTimeout->群众在大厅排队积压超50人->触发群体性投诉风险。专线网络阻断：政务外网市级节点路由器BGP邻居状态震荡->路由表收敛失败->经办网点至省集中数据中心链路中断->终端无法认证登录->全市业务办理停滞。3.2故障分级标准依据影响业务范围、受影响人群数量及预计恢复时间，将故障划分为三个等级：故障等级判定标准启动权限处置原则Ⅰ级（特别重大）省级核心系统宕机，影响人数>10万人，预计RTO>总指挥全量启动，请求省级技术支援，市级媒体通报。Ⅱ级（重大）单一地市核心业务模块（如社保参保模块）不可用，影响人数1∼10万人，预计RTO副总指挥启动技术抢修与业务降级，大厅发布公告。Ⅲ级（较大）单一非核心功能异常或单网点网络中断，影响人数<1000人，预计RTO<大厅主任现场疏导，技术组按常规工单流程处理。4.应急响应处置流程应急响应是与时间赛跑的工程，每个节点的时长必须以分钟为单位强制切片，拒绝“尽快”“及时”等模糊指令。整个流程涵盖监测、接报、研判、处置四个核心阶段。4.1监测与接报（0~15分钟）系统监控平台（Zabbix/Prometheus）触发阈值告警后，必须在3分钟内以短信及企业微信双通道推送至当班L1运维人员。L1运维人员接收告警后，须在10分钟内完成初步核实，排除误报。业务人员或12333热线接到群众集中报障（5分钟内超10起同类投诉），须立即拨打技术处置组值班电话0431-8890XXXX上报。4.2研判与定级（15~25分钟）技术处置组接报后，由当班L2工程师牵头，在10分钟内联合DBA、网络岗完成故障面研判。通过查看Nginx访问日志（排查5xx错误率）、数据库AWR报告（排查TOP10慢SQL）、网络设备端口流量（排查带宽跑满或丢包），界定故障边界并按3.2节标准定级。定级结果须以书面工单形式推送至应急指挥部。4.3场景化应急处置规程不同技术栈与故障触点的处置逻辑存在本质差异，必须穷尽常见场景并预设标准动作，严禁在故障现场“凭感觉”盲目操作。4.3.1场景一：核心数据库宕机（以OracleRAC脑裂为例）动作机理：脑裂发生时，RAC集群节点间私有网络心跳中断，各节点均认为对方已死亡并尝试接管集群资源。若两节点同时写入共享存储的相同数据块，将导致数据块内部结构冲突与物理损坏。处置步骤：DBA必须在5分钟内介入，通过crsctlstatres-t检查集群资源状态。优先强制关闭心跳异常节点（执行crsctlstopcrs-f），保留主节点运行。若主节点已宕机，优先启动备库DataBroker进行FAILOVER切换，应用连接串自动漂移至备库。禁忌三件套：严禁直接对存活节点执行reboot重启（会导致内存中未落盘的RedoLog丢失，造成事务数据不可逆损坏）→必须先执行shutdownabort强制拉平状态，再通过存储层面做快照保护后进行实例恢复。4.3.2场景二：网络专线中断（政务外网阻断）动作机理：市级汇聚交换机至省级核心路由器间BGP邻居关系失效，导致路由表无法收敛，业务网段不可达，ARP解析大面积失败。处置步骤：网络工程师登录汇聚交换机，执行showinterface查看端口物理状态及错包率。优先联系运营商排查线路光衰（要求OTDR测量光衰<28若30分钟内无法恢复，立即启用4G/5G备用VPN通道，在核心防火墙上调整路由策略，将指向省中心的默认路由下一跳切换至备用网关。禁忌三件套：严禁直接拔插主备路由器主干网线进行盲测（会引发STP生成树重计算，导致全网业务中断30~50秒）→必须先在防火墙策略中放行备用IPsecVPN隧道，验证连通性后再切换路由。4.3.3场景三：应用层无响应（Weblogic线程池耗尽）动作机理：突发大流量（如养老金发放日集中查询）打满应用中间件最大线程数（MaxThreads），新请求进入队列等待，超出StuckThreadMaxTime（默认600秒）后线程被标记为卡死，最终触发OOM（OutofMemory）或服务假死。处置步骤：应用管理员登录Weblogic控制台，查看服务器运行状态及线程队列积压数。导出ThreadDump文件，分析线程阻塞在哪个业务方法。在Nginx负载均衡器上临时开启限流策略（limit_req_zone速率限制为50req/s）。重启假死的Weblogic节点：先执行./stopWebLogic.sh，确认进程退出后清理tmp及cache目录，再执行./startWebLogic.sh。禁忌三件套：严禁直接采用kill-9杀死进程（会破坏WeblogicJTA事务日志，导致分布式事务悬空，恢复后需人工逐条排查补偿）→必须优先使用控制台正常Shutdown，若5分钟内未停止，再使用kill-15发送正常终止信号。4.3.4场景四：勒索病毒/数据篡改（安全事件）动作机理：攻击者通过办公网终端钓鱼邮件进入内网，利用SMB445端口漏洞横向移动，拿下Web服务器Shell，并尝试通过应用系统提权访问数据库，对数据文件进行AES加密或恶意篡改。处置步骤：发现异常加密行为或流量告警，网络安全岗必须在5分钟内通过堡垒机切断受害主机的网络连接（禁用网卡或物理拔除网线）。提取内存镜像用于取证分析（使用LiME或DumpIt）。将业务流量紧急切换至异地灾备数据中心。禁忌三件套：严禁在被感染节点上直接运行杀毒软件查杀（会导致被加密文件的文件头被破坏，即使拿到解密密钥也无法恢复数据）→必须先隔离磁盘镜像备份，再从干净的PE系统启动进行取证清理。4.4应急处置的闭环管理每次应急响应结束后，必须执行完整的PDCA闭环。故障恢复后24小时内召开复盘会，48小时内出具《故障复盘报告》，报告必须包含时间轴（精确到分钟）、根因分析（使用5Whys法）、暴露的短板及整改清单。整改清单须明确责任人、完成时间及验收标准，纳入下月度IT运维考核（KPI）。5.业务连续性保障与降级方案系统可以宕机，但民生业务不可阻断，降级方案的核心是将“数字化阻断”转化为“纸质化降速”。业务保障组在接到技术处置组“预计RTO>15.1线下收件降级方案优先启用大厅单机版离线应急办理终端（通过本地SQLite存储数据，支持身份证读取及指纹验证）；若无离线终端或故障涉及身份认证核心，则采用纸质表单手工收件模式。社保参保业务：前台使用《参保登记业务线下受理单》一式三联（群众留存联、业务存根联、财务记账联）。工作人员需手工填写群众身份证号、参保起止时间及缴费基数，并加盖经办人私章及大厅业务专用章。待遇发放业务：严禁现场承诺发放时间。前台收取群众银行卡复印件及身份证复印件，出具《待遇发放延期办理告知书》，明确告知系统恢复后3个工作日内完成核算与发放。5.2业务数据补录机制系统恢复后24小时内，由各网点业务主管核对纸质单据，在核心系统中执行离线数据补录。补录必须遵循“双人双录双复核”原则：录入员录入系统，复核员持原件逐字段核对，复核通过率必须达到100%。若发现录入错误，须在系统中发起冲正交易并留存纸质情况说明。6.故障恢复与验证恢复不是简单地重启服务，而是基于数据一致性与业务逻辑闭环的严密验证，任何未经验证的上线都是对公众利益的二次犯罪。6.1恢复前置检查清单在执行应用服务启动前，必须完成以下核心组件的状态校验：数据库层面：执行`SELECTopen_modeFROMv$database;`确认状态为`READWRITE`；执行`SELECTcount(*)FROMv$archive_gap;`确认归档日志无Gap（间隙）。缓存层面：检查Redis集群状态，执行CLUSTERINFO确认cluster_state:ok，且无Failover进行中的状态。中间件层面：确认Weblogic/JVM的HeapSize使用率<706.2灰度放量与验证严禁直接将核心业务全量切回生产库（可能瞬时打满恢复后的脆弱数据库连接池，引发二次雪崩）。灰度引流：在Nginx上配置按客户端IPHash或按比例（初始10%）将流量路由至恢复后的节点。观察15分钟无5xx报错且平均响应时间<500业务验证：安排业务人员在测试环境执行核心用例（参保登记、待遇计算、核定征集等），核对测试数据结果与预期一致。全量恢复：按30%、50%、100%阶梯逐步放量，每阶段观察10分钟，确认无异常后完成最终恢复。6.3移交与确认业务功能验证通过后，技术处置组向业务保障组办理移交。业务保障组确认大厅排队积压清理完毕且无新发异常报错后，由副总指挥宣布应急响应终止。7.应急保障保障体系不能停留在纸面协议，必须将备件、通道、账号落实到物理位置与具体代码仓库。7.1通讯与指挥保障建立专用应急指挥微信工作群。故障发生后，技术处置组每30分钟在群内滚动播报处置进度（格式：当前时间、已执行动作、当前状态、下一步计划）。12333热线中心须提前拟定标准安抚话术（如：“因省人社系统网络波动，您办理的业务暂受影响，我们已启动紧急抢修，预计于X时X分恢复，给您带来不便敬请谅解”），话术需经指挥部审批后统一下发。7.2物资与账号保障灾备机房的跳板机访问密钥（YubiKey及动态口令卡）需存放在信息中心值班室保险柜，实行双人双锁管理。备用服务器、网络交换机、光模块需在备件库单独存放，关键备件库存量ge7.3第三方支持保障与云服务商及核心软件供应商签订高级支持协议，明确P1（最高优先级）级别故障响应时间leq15分钟，远程接入时间l8.监督管理与预案演练演练是检验预案有效性的唯一标准，未经实战演练的预案等同于没有预案。8.1演练频次与要求每半年至少组织1次无脚本桌面推演，重点检验组织指挥与通讯协同；每年至少组织1次实战断网切换演练，在非业务高峰期（如周日上午9:00）真实切断主数据中心链路，验证灾备系统拉起时长及业务接管可用性。8.2考核与问责对于因巡检不到位、已知漏洞未修复导致本可避免的故障，追究当班人员及技术主管责任（扣减当月绩效10%8.3动态更新机制本预案由信息中心运维管理科负责维护。每次演练或真实故障处置结束后，须在1周内根据暴露的问题修订预案内容，更新联络通讯录及技术操作参数。预案版本号采用v[年份].[修订次数]格式管