校园系统卡顿瘫痪应急办法

校园系统卡顿瘫痪应急办法第一章总则1.1编制目的与背景随着教育信息化建设的深入推进，校园网络与各类业务系统（如教务管理系统、财务缴费系统、图书馆借阅系统、一卡通系统、在线教学平台等）已成为全校师生日常学习、工作和生活不可或缺的基础支撑设施。然而，面对突发的设备故障、恶意网络攻击、病毒传播、人为操作失误或极端高并发访问（如选课、查分期间），系统可能出现卡顿、服务响应迟缓甚至完全瘫痪的情况。为了建立健全校园信息系统安全应急响应机制，提高应对突发网络与信息安全事件的能力，确保在发生系统故障时能够迅速、高效、有序地进行处置，最大程度地减少对学校正常教学秩序和管理工作的负面影响，保障数据资产的完整性与安全性，特制定本应急处理详细办法。1.2适用范围本办法适用于全校范围内所有基于校园网运行的服务器硬件、操作系统、数据库管理系统、中间件及各类业务应用软件。具体涵盖但不限于以下场景：1.核心交换机、汇聚交换机及服务器等关键网络设备发生故障，导致大面积网络中断或系统不可访问。2.服务器操作系统崩溃、服务进程异常停止或资源耗尽（CPU、内存、磁盘IO占用率持续100%）。3.数据库出现死锁、表空间损坏、数据文件丢失或性能严重下降，导致业务无法办理。4.应用程序因代码Bug、配置错误或第三方接口调用失败而陷入瘫痪。5.遭受DDoS攻击、勒索病毒感染、网页篡改等网络安全事件导致的系统服务中断。6.因选课、评教、双学位报名、四六级报名等引发的突发性高并发流量，导致系统严重卡顿或崩溃。1.3工作原则1.统一指挥，分级负责：成立应急响应领导小组，统一指挥协调应急处置工作。各部门根据职责分工，各司其职，协同配合。2.预防为主，平战结合：加强日常监测与巡检，完善备份策略，定期进行应急演练，将隐患消除在萌芽状态。3.快速反应，保障重点：故障发生后，第一时间响应，优先保障核心业务（如教务、一卡通）的恢复，确保教学秩序稳定。4.规范操作，数据安全：在应急处置过程中，严格遵守操作规程，任何操作不得导致数据丢失或二次破坏，数据恢复是首要任务。第二章应急组织架构与职责2.1应急响应领导小组设立信息系统应急响应领导小组，作为最高决策机构。组长：分管信息化建设的校领导。副组长：网络信息中心主任、教务处处长、财务处处长。职责：负责审定应急预案，决定应急响应的启动与终止；指挥重大、特大突发事件的处置；协调学校各部门资源投入；负责向上级主管部门汇报情况。2.2技术应急工作组由网络信息中心技术骨干组成，分为网络保障组、系统保障组、数据保障组和安全攻防组。网络保障组：负责网络设备的监控、故障排查与链路切换，确保网络层畅通。系统保障组：负责服务器操作系统、虚拟化平台、中间件及应用系统的重启、日志分析与故障修复。数据保障组：负责数据库的健康检查、数据完整性校验及数据备份恢复操作。安全攻防组：负责攻击流量的清洗、病毒样本的查杀、漏洞修补及溯源取证。2.3业务协调组由教务处、学工部、财务处及各学院教学秘书组成。职责：负责向师生发布故障通知及安抚工作；根据技术组建议，启动线下业务替代方案；收集师生反馈的故障现象，协助技术组定位问题。2.4后勤保障组职责：负责应急处置所需的硬件备件、电力供应、机房环境（空调、UPS）保障及车辆调度。2.5联络通讯机制为确保故障发生时信息传递的及时性，建立分级联络表。所有成员必须保持手机24小时开机，并在微信群、钉钉群设置强提醒。角色姓名联络方式备用联络方式备注应急总指挥[姓名]138xxxx0000办公电话：xxxx决策层技术负责人[姓名]139xxxx1111短号：xxxx技术统筹网络组长[姓名]137xxxx2222短号：xxxx网络层数据库专家[姓名]136xxxx3333短号：xxxx数据层业务联络人(教务)[姓名]135xxxx4444短号：xxxx业务发布第三章预防与监测预警机制3.1日常巡检制度1.每日巡检：每日上午8:30前，系统管理员通过监控平台检查核心服务器CPU利用率、内存使用率、磁盘剩余空间及网络流量。若发现资源使用率超过80%（警戒线），立即记录并排查原因。2.每周巡检：每周五下午，检查数据库日志增长情况、应用系统中间件连接池状态、备份任务执行日志，确保所有备份任务成功完成。3.每月巡检：每月最后一周，对机房UPS电池、精密空调、消防系统进行物理检查，对核心交换机配置文件进行备份并对比差异。3.2高并发场景专项保障针对选课、查分、评教等高并发场景，实施“事前评估、事中监控、事后清理”策略。1.事前评估：在业务开始前3天，技术组与业务组沟通预估访问量（如在线人数峰值）。根据预估，临时扩容应用服务器节点，调整数据库连接池参数，清理无用历史数据以优化表结构。2.流控策略：在负载均衡设备上配置限流策略，当并发连接数超过阈值（如5000）时，自动开启排队页面或验证码拦截，防止系统雪崩。3.熔断机制：在应用代码中预设熔断开关，一旦检测到数据库响应时间超过3秒，自动切断非核心查询请求，优先保障登录和核心交易接口。3.3监控预警指标体系建立全方位的监控指标，一旦触发阈值，自动通过短信、邮件发送报警。系统级指标：CPU持续>90%超过5分钟；内存剩余<10%；磁盘利用率>95%；Ping丢包率>1%。应用级指标：应用服务JVM堆内存占用>85%；Tomcat/Nginx线程池满载；HTTP请求50X错误率>1%。数据库级指标：数据库锁等待时间>10秒；连接数占用率>90%；主从同步延迟>60秒。第四章故障分级与响应流程4.1故障等级定义根据系统故障的影响范围和持续时间，将故障划分为三个等级：故障等级定义描述影响范围响应时限I级（特别重大）核心系统（如教务、一卡通）完全瘫痪，或全校范围网络中断，且预计恢复时间超过4小时。全校师生，教学秩序停滞立即响应，10分钟内上报II级（重大）核心系统功能严重受损，访问极慢，或局部楼宇网络中断，预计恢复时间超过1小时。大部分师生，主要业务受阻15分钟内响应，30分钟内上报III级（一般）单一非核心模块故障，或个别终端无法访问，不影响主要业务流程。少数师生，局部影响30分钟内响应，1小时内上报4.2应急响应标准流程1.故障发现与报告：监控系统报警或用户报修->值班人员记录故障时间、现象、影响范围->判断故障等级。2.预案启动：值班人员立即通知技术负责人->技术负责人根据等级决定是否启动应急小组->若启动，通知所有成员到位。3.初步排查（遏制）：检查网络连通性->检查服务器状态->检查应用进程->采取临时措施（如重启服务、切换流量）止损。4.深入诊断（根因分析）：分析系统日志、数据库日志、网络抓包->确定故障根本原因（硬件、软件、攻击、流量）。5.实施修复：根据故障类型执行对应的修复操作（详见第五章）。6.验证与恢复：技术人员内部测试通过->通知业务部门验证->逐步对外开放访问->全量恢复。7.后续处理：监控运行稳定性24小时->撰写故障分析报告->总结经验教训。第五章典型故障场景技术处置方案5.1服务器资源耗尽（卡顿）处置1.现象：系统响应极慢，SSH登录困难，CPU或内存爆满。2.处置步骤：步骤一（Top分析）：使用`top`或`htop`命令查看进程资源占用，定位消耗资源最高的PID。步骤二（进程判断）：若为Java进程：立即导出ThreadDump文件（`jstack-lPID>dump.log`），分析是否存在死锁或死循环。若无法立即分析且严重影响业务，在保留现场快照的前提下，重启该应用服务节点。若为数据库进程：检查是否有慢SQL正在执行，使用`showprocesslist`查看，必要时`kill`掉执行时间过长的查询线程。若为I/O等待高：使用`iostat-x1`查看，检查是否为磁盘故障或日志疯狂写入。若是日志写入，临时暂停日志记录或清空非关键日志。步骤三（紧急扩容）：若当前物理资源已达上限，立即在虚拟化平台上申请增加vCPU或内存，或启动备用节点接入负载均衡。5.2数据库死锁或崩溃处置1.现象：前端提示“连接超时”或“系统繁忙”，数据库无法连接。2.处置步骤：步骤一（服务状态）：检查数据库服务是否运行。若停止，尝试查看错误日志（如MySQL的error.log）。步骤二（启动失败）：若启动失败且提示表空间损坏，切勿直接重启。应立即从最近的物理备份中恢复数据文件到临时目录，尝试启动并导出数据。步骤三（死锁处理）：若服务运行但无响应，查询锁等待表。找到阻塞源头的会话ID，评估是否可以Kill。若涉及关键事务（如正在扣费），必须联系业务组确认是否可回滚，不可盲目Kill导致账目错乱的二次故障。步骤四（主从切换）：若主库彻底损坏且无法在短时间内修复，立即停止应用写入，将备用从库提升为主库（修改VIP漂移或修改DNS），修改应用连接配置，恢复服务。5.3网络攻击（DDoS/CC攻击）处置1.现象：防火墙出口带宽跑满，Web服务器充斥大量恶意请求，正常用户无法访问。2.处置步骤：步骤一（攻击确认）：在核心交换机镜像流量，使用Wireshark分析数据包特征。检查源IP是否分布均匀、是否针对特定URL、User-Agent特征。步骤二（边界防护）：在边界防火墙上启用ACL策略，封堵攻击源IP段。若为CC攻击，在WAF（Web应用防火墙）上启用频率限制策略，如“同一IP每分钟请求超过60次则封禁”。步骤三（流量清洗）：若攻击流量超过学校出口带宽（如超过1Gbps），立即联系上级教育网节点或运营商启用流量清洗服务，将流量牵引至清洗中心。步骤四（静态化/CDN）：若是针对动态页面的攻击，紧急将首页和关键公告页切换为静态页面发布，并启用CDN加速分担源站压力。5.4存储硬件故障处置1.现象：服务器日志提示IO错误，存储阵列红灯报警，文件系统变为只读。2.步骤一（保护数据）：严禁对故障存储进行任何写操作（如fsck修复），防止数据彻底覆写。3.步骤二（RAID状态）：登录存储管理界面，查看RAID卡状态。若为单块硬盘离线且RAID级别为5或6，系统应仍能运行（降级模式），此时应尽快插入新硬盘进行Rebuild（重建）。4.步骤三（双盘离线）：若RAID阵列中两块硬盘离线，数据将丢失。此时必须启动灾难恢复流程，从磁带库或异地备份中心恢复数据。5.步骤四（业务迁移）：利用冷备存储或本地SAN网络，将surviving的LUN挂载到备用服务器上，启动应用服务。第六章业务连续性管理与替代方案当技术修复无法在预期时间内完成时，为维持学校基本运转，必须启动线下或替代业务流程。6.1教务管理替代方案1.选课期间瘫痪：暂停在线选课，发布通知延长选课时间。若急需安排课程（如公共选修课），由各学院教学秘书收集学生纸质选课单，统一汇总后由教务处技术人员后台批量录入数据库。2.成绩录入期间瘫痪：教师下载空白成绩模板（离线版），离线填写成绩。系统恢复后，通过系统提供的“批量导入”功能上传，或由技术人员直接导入数据库后台。6.2财务缴费替代方案1.线上缴费瘫痪：暂停线上缴费通道，发布通知告知学生及家长。开启线下收费窗口，支持POS机刷卡、现金缴纳。系统恢复后，财务人员将线下缴费数据手动录入系统，并核销未缴费订单。6.3校园一卡通替代方案1.消费终端瘫痪：若为一卡通专网故障，POS机通常具备“脱机消费”功能。确认终端处于脱机模式，允许师生刷卡消费（消费数据存储在终端缓存）。系统恢复后，技术人员下发“采集指令”上传流水数据，并执行“结算”操作，确保账户余额同步。2.圈存充值瘫痪：暂停自助圈存，引导师生前往现金充值点或使用银行APP转账至校园卡账户（通过银行端到校园端的代发接口）。6.4网络教学替代方案1.在线教学平台瘫痪：教师改用微信群、QQ群或钉钉群发布教学资料。若为直播课故障，立即切换至备用直播平台（如腾讯会议、Zoom），或转为异步教学，录制视频课后上传。第七章沟通与信息发布机制7.1信息发布原则1.透明度：不隐瞒故障事实，但要避免使用过于专业的术语引起恐慌。2.及时性：故障确认后15分钟内发布首报，随后每30分钟更新一次进度，直至恢复。3.多渠道：利用校园网主页弹窗、官方微信公众号、企业微信/钉钉通知、校园广播、辅导员微信群等多渠道触达用户。7.2故障通报模板【故障初报】标题：关于教务系统暂时无法访问的紧急通知内容：各位师生，目前教务系统出现突发故障，技术人员正在紧急抢修。由此给您带来的不便，敬请谅解。预计恢复时间待定，后续进展将及时通知。【进度通报】标题：教务系统抢修进度通报内容：经排查，故障原因为数据库服务器硬件故障，目前正在更换备件并进行数据恢复。预计还需要2小时，请耐心等待。【恢复通知】标题：教务系统已恢复正常内容：经过抢修，教务系统现已恢复服务。请大家分散登录，避免集中访问。如有问题请联系客服。7.3内部沟通技术组内部建立即时通讯群，实时通报操作日志。“10:00发现数据库连接池满，正在重启应用节点A。”“10:05重启成功，观察中。”“10:10连接数再次飙升，正在排查慢SQL。”这种高频度的内部同步有助于指挥官掌握实时战况。第八章灾难恢复与后期整改8.1数据恢复验证系统恢复后，不能立即宣布成功。必须进行严格的“数据一致性验证”：1.记录数核对：对比故障发生前后的关键业务表记录数（如学生表、选课记录表、财务流水表）。2.金额核对：打印财务报表，核对系统总余额与实际账面金额是否一致。3.抽样校验：随机抽取部分学生的选课结果、成绩数据进行人工核对，确保未出现“张冠李戴”或数据乱码。8.2故障复盘（RCA）故障解决后48小时内，召开故障复盘会，形成《故障分析报告》。1.根本原因分析：使用“5Whys”法挖掘深层原因。例如：为