IT系统故障排查与修复标准化操作手册

IT系统故障排查与修复标准化操作手册一、引言本手册旨在规范IT系统故障排查与修复的全流程操作，通过标准化步骤、统一记录模板及明确责任分工，提升故障响应效率，缩短系统恢复时间，降低业务损失风险。手册适用于企业内部各类IT系统（包括服务器、存储设备、网络设备、应用系统等）的故障处理，相关运维、开发及管理人员需严格遵循本手册要求开展工作。二、应用场景与适用范围（一）适用系统类型硬件类：服务器（物理机/虚拟机）、存储设备（SAN/NAS）、网络设备（交换机/路由器/防火墙）、终端设备（PC/打印机等）等；软件类：操作系统（Windows/Linux/Unix）、数据库（MySQL/Oracle/SQLServer）、中间件（Tomcat/Nginx/WebLogic）、业务应用系统（ERP/CRM/OA等）；网络类：局域网、广域网、VPN、DNS、负载均衡等网络环境故障；安全类：病毒感染、权限异常、数据泄露、DDoS攻击等安全事件。（二）适用故障类型突发性故障：系统宕机、服务中断、网络瘫痪等需紧急处理的故障；渐发性故障：系统功能下降、日志报错、数据异常等需逐步排查的隐患；重复性故障：同一问题多次发生，需深度分析根因的顽固故障。（三）适用人员IT运维团队、系统开发团队、网络安全团队；业务部门对接人（负责故障影响范围确认与业务需求沟通）；企业管理层（负责重大故障决策与资源协调）。三、标准化操作流程（一）故障发觉与信息上报故障发觉渠道监控系统告警（如Zabbix、Prometheus等触发阈值告警）；用户反馈（通过客服、企业/钉钉群、邮件等方式上报）；日常巡检发觉（运维人员定期检查时识别异常）。信息上报要求发觉故障后，10分钟内由第一发觉人通过“故障报告单”（见模板一）向上级负责人及IT运维组长汇报；上报内容需包含：故障发生时间、故障现象（如“无法访问OA系统”“服务器响应超时”）、影响范围（如“涉及销售部20人”“影响订单提交功能”）、已尝试的初步处理措施（如有）。启动响应机制IT运维组长接到上报后，根据故障严重程度划分等级（见下表），并启动对应响应流程：故障等级定义响应时间负责人一级（重大）核心业务中断，影响全公司或关键部门5分钟内IT总监二级（严重）非核心业务中断，影响部分部门或用户15分钟内运维组长三级（一般）轻微异常，不影响主要业务功能30分钟内运维工程师（二）初步诊断与影响评估收集故障信息调取监控系统数据（CPU/内存使用率、网络流量、服务状态等）；查看系统日志（如操作系统日志、应用日志、数据库日志）；与用户沟通确认故障复现条件（如“特定操作触发”“固定时间段出现”）。基础排查操作检查物理连接：网线是否松动、设备指示灯状态（如服务器硬盘灯、交换机端口灯）；检查服务状态：通过命令行或管理工具查看关键进程是否运行（如systemctlstatusnginx、ps-ef|grepjava）；检查网络连通性：使用ping、telnet、tracert等命令测试网络可达性（如ping8.8.8.8测试外网连通）。影响范围评估明确故障对业务的影响（如“导致无法下单”“数据无法同步”）；评估故障优先级，协调业务部门确认是否需要启动应急预案（如切换备用系统、暂停非核心业务）。（三）深入故障定位根据初步诊断结果，针对不同故障类型开展深度排查：1.硬件故障排查服务器硬件：使用ipmitool、dmide等工具查看硬件状态，检查内存（memtest）、硬盘（smartctl-a/dev/sda）、CPU（top）是否异常；网络设备：通过showinterface、showlog命令查看端口流量、错误包数量，检查设备温度（如showenvironment）；存储设备：使用df-h检查磁盘空间，通过vgdisplay、lvdisplay查看逻辑卷状态，确认存储阵列告警信息。2.软件故障排查操作系统：检查系统文件完整性（rpm-Va/dpkg-C），查看内核日志（dmesg），确认系统补丁是否缺失；数据库：通过showengineinnodbstatus查看MySQL状态，检查表空间使用率（SELECTtable_name,data_length+index_lengthFROMinformation_schema.tables），分析慢查询日志；应用系统：检查应用日志（如catalina.out），确认配置文件是否正确（如数据库连接参数、端口配置），查看线程堆栈（jstack）分析死锁问题。3.网络故障排查分层排查：从物理层（链路状态）→数据链路层（MAC地址、VLAN）→网络层（IP地址、路由表）→传输层（端口状态）→应用层（协议解析）逐步定位；抓包分析：使用Wireshark、tcpdump在故障节点抓取数据包，分析异常流量（如SYNFlood、端口关闭）。4.安全故障排查安全设备：查看防火墙、WAF日志（如iptables-L-n、modsecurity日志），确认是否误拦截正常流量；系统安全：使用last命令查看登录历史，psaux检查异常进程，扫描病毒（clamscan-r/）；数据安全：核对数据完整性（如md5sum校验文件），检查访问日志（auditd）确认权限变更。定位原则：遵循“从简到繁、从外到内”逻辑，优先排除常见问题（如资源耗尽、配置错误），再深入复杂根因；若30分钟内无法定位，需上报IT总监协调专家资源。（四）制定与执行修复方案方案制定根据故障根因，制定临时修复方案（如重启服务、切换备用设备）和长期根治方案（如更换硬件、优化代码、调整配置）；方案需包含：操作步骤、风险控制措施（如操作前备份、回滚预案）、所需资源（硬件/软件/人员）、预估耗时。方案审批一级故障方案需IT总监及业务部门负责人审批；二级故障方案需运维组长审批；三级故障方案由运维工程师直接执行，事后报备。执行操作操作前确认：备份关键数据（如数据库备份、配置文件备份），通知受影响用户（如“系统维护中，预计30分钟后恢复”）；按步骤执行：严格遵循方案操作，记录每一步执行结果（如“执行systemctlrestartnginx，服务状态running”）；风险控制：若操作中出现新异常（如重启服务后系统崩溃），立即启动回滚预案（如恢复备份、回滚版本），并上报负责人。（五）修复验证与系统恢复功能验证测试故障现象是否消失（如访问应用系统、提交订单、查询数据）；验证关联功能是否正常（如故障修复后，检查周边服务是否受影响）。功能验证监控系统资源使用率（CPU、内存、磁盘I/O、网络带宽），确认是否恢复正常阈值；压力测试（如ab-n1000-c10test），验证系统在高负载下的稳定性。业务验证协调业务部门进行实际场景测试（如销售部测试订单流程、财务部测试数据报表），确认业务功能完全恢复。恢复通知验证通过后，通过邮件、企业等渠道向用户及相关部门发送恢复通知，内容包括：故障解决时间、后续注意事项（如“数据可能存在5分钟延迟”）。（六）故障归档与经验总结记录填写使用“故障排查记录表”（见模板二）、“故障修复方案表”（见模板三）、“修复验证表”（见模板四）详细记录故障处理全过程，保证信息真实、完整。根因分析组织故障复盘会议（运维、开发、业务部门参与），分析故障根本原因（如“磁盘空间不足导致数据库宕机”“代码逻辑缺陷引发内存泄漏”），明确责任方（如“运维巡检遗漏”“开发测试不充分”）。经验沉淀针对重复性故障或重大故障，编写《故障分析报告》（见模板五），提出改进措施（如“增加磁盘空间监控脚本”“优化代码逻辑”“完善巡检清单”）；更新知识库，将故障案例、解决方案纳入《IT系统运维知识库》，供团队学习参考。四、标准化记录模板模板一：故障报告单故障ID故障发生时间故障上报时间上报人故障基本信息故障系统名称故障模块/功能故障现象描述影响范围影响部门影响用户数业务影响程度（□轻微□一般□严重□重大）已尝试处理措施附件（监控截图、日志片段等）模板二：故障排查记录表故障ID排查阶段排查人员排查时间排查步骤排查方法排查结果下一步操作示例：检查磁盘空间df-h根分区使用率98%清理磁盘空间或扩容异常记录模板三：故障修复方案表故障ID方案类型（□临时□永久）制定人审批人审批时间修复方案详情操作步骤：备份数据库：mysqldump-uroot-ptest>test_backup.sql清理磁盘空间：rm-rf/tmp/old_files重启数据库服务：systemctlrestartmysql风险控制措施|

1.操作前备份数据库，避免数据丢失；若重启失败，立即执行systemctlrollbackmysql回滚；资源需求|

硬件：无；软件：无；人员：*工程师|

预估耗时|30分钟|模板四：修复验证表故障ID验证项目验证方法验证结果（□正常□异常）验证人员验证时间功能验证示例：用户登录登录系统输入账号密码正常*工程师功能验证示例：CPU使用率监控系统查看45%（正常阈值<80%）*工程师业务验证示例：订单提交销售部实际下单成功提交业务代表备注模板五：故障分析报告故障ID故障发生时间解决时间持续时长故障概述故障现象、影响范围、处理过程摘要：根因分析直接原因：根本原因：责任认定|

责任部门：□运维□开发□业务□其他责任描述：改进措施|

短期措施：长期措施：经验教训|

|五、关键操作规范与风险提示（一）安全规范操作前必须确认权限，严禁越权操作（如非DBA不得直接修改数据库表结构）；硬件操作（如插拔内存、更换硬盘）需断电并防静电，避免设备损坏；修改重要配置（如防火墙规则、数据库参数）前需备份原配置，保证可回滚；涉及数据操作时，严格遵循“最小权限”原则，避免误删误改数据。（二）沟通协调故障处理过程中，每30分钟向上级汇报进展（一级故障每15分钟汇报）；业务部门需求变更时，需评估对故障处理的影响，经双方确认后再执行；重大故障解决后，24小时内向管理层提交《故障处理总结报告》。（三）文档记录所有操