企业信息化系统故障应急预案

企业信息化系统故障应急预案一、总则1.1目的本预案用于指导企业在核心信息化系统发生中断或性能严重劣化时，30分钟内恢复关键业务操作能力，4小时内恢复核心系统可用，72小时内完成全部业务校验与复盘。预案不追求“绝对不故障”，而是追求“故障发生后损失可控、恢复路径清晰、责任边界明确”。1.2适用范围本预案适用于企业总部及分支机构以下系统的故障应急处置：ERP系统（含财务、采购、库存、销售模块）OA协同办公系统CRM客户管理系统MES生产执行系统数据中心网络、服务器、存储及虚拟化平台数据库、中间件、备份系统及容灾系统以下情形不适用本预案，另行启动相关专项预案：火灾、爆炸、水浸等物理灾难（启动《机房物理安全应急预案》）网络安全攻击持续且已造成数据泄露（启动《网络安全事件应急预案》并同步上报）办公区域断电导致终端不可用（启动《动力环境应急预案》）1.3核心原则信息化系统故障应急需要先恢复业务、再修复技术、最后追究责任。在故障初期，判断是否恢复业务的标准是“用户能否完成核心交易或审批”，而不是“系统是否修好”。因此全程遵循以下原则：业务连续性优先：优先保障财务支付、订单交付、生产排产、客户服务等核心价值链，不优先恢复内部公告、报表查询等非关键功能。最小权限启动：应急操作只授予经过授权的人员，避免慌乱中越权修改生产数据。标准变更冻结：故障未恢复前，冻结所有非应急变更、发布、部署，防止二次叠加故障。全过程留痕：所有应急操作必须记录操作人、操作时间、操作指令、影响范围，作为事后溯源基础。1.4响应等级定义企业信息化系统故障按影响范围与业务损失程度分为三级，如下表：等级判定标准启动权限处置原则Ⅰ级（特别严重）核心系统中断超过2小时，或影响财务结算、生产发料、客户交付等关键业务，预估直接经济损失超100万元总裁或授权副总经理全员进入应急状态，启动容灾切换，必要时停止相关业务操作Ⅱ级（严重）核心系统中断30分钟至2小时，或多部门业务受阻，预估损失10万至100万元信息技术部负责人启动专项处置组，30分钟内定位问题，1小时内完成降级方案Ⅲ级（一般）系统性能下降、部分功能不可用，中断30分钟以内，影响范围限于单部门班组负责人按既定SOP处理，处理后1个工作日提交故障报告二、应急组织与职责应急组织必须在平时就明确到人，不能等故障发生后再临时分配。以下职责以“岗位”表述，实际人员由各企业按岗位任命并报应急办公室备案。2.1应急指挥中心应急指挥中心是故障响应的最高决策机构，设主任1名、副主任2名、成员若干。主任：由分管信息化副总经理担任，负责启动Ⅰ级响应、批准容灾切换、向上级汇报副主任：由信息技术部负责人及财务部负责人担任，分别负责技术恢复与业务确认值班员：由数据中心值班工程师24小时轮值，负责接收报警、判定初报等级、发布通知应急指挥中心每月召开1次会议，检查应急预案更新情况、通报故障隐患、更新联系人清单。2.2技术处置组技术处置组由网络、系统、数据库、应用、安全五个方向的工程师组成，职责包括：接收工单后5分钟内确认故障现象按故障类型选择对应的SOP操作每15分钟向指挥中心报告一次处置进展变更任何生产配置前必须取得指挥中心书面或电子审批2.3业务保障组业务保障组由各业务部门指定负责人组成，包括财务、生产、销售、采购、仓储、客服各1名。负责在系统不可用时启用纸质或线下替代流程负责在系统恢复后组织本部门业务数据核对负责向客户、供应商说明业务延误情况，避免形成商誉风险2.4公关与法律组当故障可能影响客户订单、合同履约或涉及数据泄露时，公关与法律组在1小时内介入。职责包括：起草对外口径，禁止未经授权对外发布技术细节评估故障是否触发合同中的不可抗力或违约责任条款涉及数据泄露时，按《中华人民共和国个人信息保护法》规定，在72小时内向监管机构报告2.5RACI责任矩阵活动应急指挥中心技术处置组业务保障组公关与法律组故障初报ACII处置方案审批ARCI技术实施恢复IRCI业务线下切换AIRI对外信息发布ACCR恢复确认ACRI复盘与整改ARCC注：R=负责执行，A=负责审批，C=咨询，I=知会。三、风险分析与故障分级信息化系统故障的风险在于数字中断会瞬间放大业务损失，且故障点之间会相互传导。必须精确识别故障类型，分级响应，才能避免“小故障拖垮全局”。3.1风险识别企业信息化系统故障的源头可归结为以下五类：基础设施故障：机房断电、线路中断、空调失效、网络拥塞软件缺陷：应用代码错误、参数异常、接口调用失败硬件失效：服务器硬盘坏道、内存条松动、交换机端口故障人为误操作：误删数据、误发指令、错误部署网络攻击与恶意代码：勒索软件、DDoS攻击、SQL注入3.2故障演化路径每类故障都可能沿固定链路扩展，必须提前识别演化路径：线路中断→分支机构无法访问核心系统→订单无法录入→仓库停止出库→客户断供数据库死锁→ERP事务队列堆积→财务无法过账→月末关账延误→审计不通过虚拟化平台单台主机故障→多台虚拟机迁移失败→应用系统全部不可用网络交换机环路→广播风暴→全网拥塞→所有系统超时3.3分级判定分级判定的量化标准与响应权限见1.4表格，但现场判定时优先看业务影响，不看技术难易。例如：如果宕机的是“报表查询系统”，中断1小时仍属Ⅲ级如果宕机的是“财务支付接口”，中断15分钟即可判定为Ⅱ级故障判定执行“一线初判、指挥中心终判”两条线。一线值班员在5分钟内提交初步等级，指挥中心在10分钟内终判并通知各小组。3.4常见故障处置SOP清单以下SOP由技术处置组定期维护，每年至少演练1次：SOP-01：服务器硬件故障处理SOP-02：数据库RAC节点故障处理SOP-03：ERP应用服务启停与回滚SOP-04：核心交换机故障切换SOP-05：备份异机恢复SOP-06：勒索软件隔离与数据恢复SOP-07：终端病毒感染批次处理SOP-08：机房空调失效紧急处置四、预警与监测机制预防故障的关键在于早于用户发现系统异常。数据中心的监控系统如果只用来记录故障，就失去了存在的价值。企业必须建立覆盖基础设施到应用层的立体监测。4.1监测范围监测应覆盖以下四层：层级监测对象关键指标基础设施层机房温湿度、UPS电压、空调出风温度温度18°C~27°C，湿度40%~70%，UPS输出220V±5V网络层核心交换机、路由器、防火墙、链路负载链路利用率≤70%，丢包率≤1%主机层服务器CPU、内存、磁盘I/O、文件系统CPU使用率≤80%，内存使用率≤85%，磁盘占用≤80%应用层ERP、OA、CRM、MES的关键接口响应时间登录响应≤3s，事务提交≤5s4.2预警分级预警按严重程度分三级：蓝色预警：监控指标接近阈值但业务未受影响，如磁盘占用达到75%黄色预警：关键指标超阈值或有恶化趋势，如ERP接口响应时间连续3次超过5秒红色预警：核心系统不可用或即将不可用，如数据库实例持续ORA-02019连接超时4.3预警通知预警触发后，监控系统应自动通过短信、邮件、企业微信三条渠道通知值班员和相关负责人，并要求值班员在10分钟内确认预警并反馈处理意见。若10分钟后无人确认，系统应自动升级通知至技术处置组组长及应急指挥中心副主任，形成冗余通知闭环，防止单点人员遗漏。五、应急响应流程应急响应流程必须像生产线一样顺序推进，每一步有明确产出物和时限，不允许出现“先看看再说”的模糊地带。5.1故障发现与初判故障来源包括监控告警、用户报修、外包商通知值班员接到通知后，立即登录监控平台核对告警真实性初判内容包括：影响系统、影响范围、可能原因、建议等级值班员在10分钟内完成初判并报告指挥中心5.2启动响应指挥中心根据初判结果，决定启动对应等级响应：Ⅲ级响应：技术处置组当日值班人员直接处理，处置过程记录在工单系统Ⅱ级响应：技术处置组全员到岗，业务保障组准备线下方案，30分钟内完成信息同步Ⅰ级响应：全公司相关岗位停止非必要工作，启动容灾系统切换和重要数据保全5.3技术处置技术处置组按故障类型选择SOP执行，但必须遵循以下通用步骤：立即隔离：断开故障节点的网络连接或从负载均衡池中移除，防止故障扩散保护证据：导出系统日志、数据库alert日志、网络抓包数据，至少保留15天寻找根因：按“网络→服务器→操作系统→数据库→应用”顺序自底向上排查，避免盲目重启执行恢复：恢复方案必须明确是回滚、切换、重启还是补丁修复验证业务：由业务保障组确认登录、查询、提交、审批等关键动作恢复正常后方可收工严禁未经根因确认就重启生产服务器。盲目重启可能导致中间数据丢失，并且错失保留故障现场的最后窗口。5.4业务连续性措施遇到Ⅱ级及以上故障，业务保障组必须启动线下或替代流程。例如：财务系统不可用时，使用纸质单据登记付款申请，待系统恢复后2小时内补录库存系统不可用时，仓库启用Excel临时台账，所有出入库必须双人签字ERP销售模块不可用时，订单信息由客服手工登记，并立即通知仓库延迟发货5.5信息报送与升级Ⅱ级响应启动后30分钟内，由应急指挥中心向分管副总经理报告Ⅰ级响应启动后15分钟内，由应急指挥中心向总经理报告对外信息发布统一由公关与法律组审核，审核时限不超过1小时六、专项处置方案专项处置方案是应急响应的核心操作层。本预案选取三个高风险场景展开列示，分别为数据中心电源故障、数据库服务崩溃、勒索软件攻击。各企业可不限于这三个场景，但处置思路均可复用。6.1数据中心电源故障电源故障的风险在于市电中断本身未必致命，但柴油发电机启动失败或UPS电池耗尽往往才是真正的灾难。必须关注供电链路的每一个中断点。6.1.1故障处置步骤动力值班员确认UPS是否正常供电，检查各机柜电压是否在220V±5V范围检查柴油发电机是否自动启动，若未启动，立即改为手动启动检查发电机油箱液位，若低于40%，立即安排加油若UPS电池可持续供电时间低于30分钟，优先关闭非核心服务器，保留核心存储和网络设备市电恢复后，先稳定运行30分钟再逐步切回市电，避免频繁启停损坏设备6.1.2出问题怎么办若UPS电池已至低电压保护边缘，应主动有序关机，避免全部负载瞬间掉电导致数据库文件损坏。恢复供电后，立即对受损文件系统执行fsck或等效检查，并恢复备份。6.2数据库服务崩溃数据库崩溃不仅会使业务中断，还可能造成提交事务丢失或数据文件不一致。处置原则是“先保数据，再保服务”。6.2.1故障处置步骤数据库管理员在5分钟内定位实例状态，判断是单节点故障还是集群整体故障导出alert日志、trace文件，确认故障类型是ORA-00600、MySQL端口的连接拒绝，还是文件系统满导至无法写入如果为单节点故障，将应用连接串切到正常节点，保持业务不中断若为文件系统满，立即清理归档日志或扩展空间，保证实例可写恢复后验证pg_ctlstatus/sqlplus/assysdba等典型命令，确认实例可正常接受连接6.2.2数据不一致处置若数据库恢复后出现丢数据或账务不平，严禁直接在数据库手工修改生产数据。应通过应用系统补录或调整，确保每笔数据都有业务单据支撑。手工修改数据属于高危操作，必须经财务或业务负责人签字确认后执行。6.3勒索软件攻击勒索软件攻击的典型特征是文件被大量加密且要求赎金，处置核心是“切断传播、保护未感染数据、报警溯源”。6.3.1处置步骤立即断开受感染主机的网线，禁用Wi-Fi，物理隔离被感染终端隔离可能受感染网段，禁止普通终端访问核心数据区检查防病毒平台是否捕获到加密行为，阻断恶意进程对被感染主机制作全盘镜像，保留原始加密状态，作为溯源与取证材料不支付赎金，不打开攻击者提供的解密工具，将样本提交安全厂商分析基于防病毒平台对全网终端执行全盘扫描，确认无其他潜伏样本6.3.2恢复路径优先从备份系统恢复数据。恢复前，必须先在隔离环境验证备份未被感染，恢复后立即打安全补丁并修改弱口令，避免二次感染。6.4网络环路导致的广播风暴广播风暴通常由新增网络设备或错误跳线导致，一旦发生会在数秒内让整网瘫痪。处置方法是：抓取网络流量，确认是二层环路还是三层路由震荡在核心交换机上执行shspanning-tree，定位异常端口临时关闭疑似端口，观察全网流量是否回落永久修复需为交换机配置STP或RSTP，并禁止非授权设备接入七、恢复与重建故障恢复技术上线并不意味着应急结束。真正的结束标志是业务数据一致、系统性能稳定、防护措施更新。恢复阶段必须像故障处理阶段一样有章法。7.1恢复确认技术恢复后，由业务保障组组织各业务部门在2小时内完成核心业务流程的回归验证，验证项包括：核心审批流程可正常发起和审批关键报表数据与故障前一致对外支付、订单、库存等接口可正常回调用户权限未发生异常变更7.2数据校验财务、库存、订单等关键系统恢复后，应进行快照比对，确认故障期间的业务流水与实际一致。若发现差异，由业务部门提出调整申请，技术部门配合出具数据恢复报告。7.3故障复盘Ⅰ级、Ⅱ级故障结束后3个工作日内召开复盘会，形成《故障复盘报告》，报告至少包含：故障时间线（精确到分钟）根因分析，采用“5个为什么”法直接损失与间接损失估算改进措施与责任人及完成时限改进措施验证方式Ⅲ级故障在1个工作日内复盘并提交简要报告。八、保障措施应急能力的保障不体现在预案文本的厚度，而体现在随时可调用的工具、随时可联系到的人、随时可恢复的数据。本节明确人、财、物、技术四类保障。8.1人员保障应急组织成员实行A/B角机制，核心岗位保证任意时间有2人可联系所有应急人员手机保持24小时畅通，若无法联系，视为缺勤并追究责任新员工须在入职培训中完成信息化应急基础知识及对应部门SOP考核8.2资金保障应急备用金单独预算，不得与其他项目混用采购应急设备（如备件、应急存储、备用网络设备）经指挥中心批准后可简化审批流程8.3技术保障核心系统必须有异地备份，备份数据定期恢复验证，至少每半年演练1次远程应急通道（堡垒机、VPN）不得与日常办公网络混用变更管理系统中必须有“紧急变更”通道，但事后必须补录全部信息8.4文档保障本预案每年12月前评审1次，由应急指挥中心组织所有SOP与预案配套，修订后5个工作日内发布更新版本版本文件统一存放于企业文档管理系统，离线备份存放于机房密钥柜九、培训与演练预案的生命力在于演练。不演练的预案等于没有预案。培训与演练必须固化到年度计划，并配套考核与改进。9.1培训要求全员每年至少参加1次信息化应急知识培训，时长不少于2小时技术处置组每季度进行1次专项案例学习，案例应包含内部和历史行业真实故障新员工入职后1个月内完成培训及在线考核，低于80分者补训9.2演练计划每年至少组织2次演练，其中至少1次为全公司级别的综合演练。演练可采用桌面推演、模拟操作、真实切换三种形式。演练类型频率参与范围检验重点桌面推演每季度1次指挥中心、技术处置组决策流程、沟通效率模拟操作每半年1次技术处置组、业务保障组操作熟练度、SOP可行性真实切换每年1次全公司容灾切换、业务连续性、数据一致性9.3演练评估与改进演练结束后7个