IT系统故障排查与修复手册

IT系统故障排查与修复手册一、典型应用场景本手册适用于企业IT系统在运行过程中各类故障的应急响应与处理，覆盖以下常见场景：硬件故障：服务器宕机、存储设备损坏、网络中断（如交换机故障、光纤链路中断）、终端设备（如电脑、打印机）无法启动或异常。软件故障：操作系统崩溃、应用程序无法启动或功能异常（如数据库连接失败、服务报错）、系统功能骤降（如卡顿、响应超时）、中间件（如Tomcat、Nginx）配置错误或进程异常。网络故障：局域网内无法访问特定服务、广域网连接中断、DNS解析失败、IP冲突、网络延迟过高。数据故障：数据丢失（如误删、存储损坏）、数据损坏（如文件乱码、数据库表损坏）、数据同步异常（如主从数据库不一致）。安全故障：病毒/木马感染、账户异常（如密码泄露、非授权登录）、DDoS攻击导致服务不可用、安全策略误触发（如防火墙规则拦截正常流量）。二、故障排查与修复操作流程（一）故障接收与初步响应故障信息登记接收故障报告时，记录以下核心信息：故障发生时间、故障现象（如“用户无法登录系统”“页面加载失败”）、受影响范围（如“某部门员工”“全国用户”）、上报人联系方式（内部通讯工具）、故障级别（依据业务影响程度分为P1-P4，P1为最高级，如核心业务中断）。示例：2024–14:30，*用户（销售部）反馈CRM系统无法登录，影响10名销售人员业务办理，初步判定为P2级故障。启动应急响应P1/P2级故障：立即通知IT运维团队负责人（*经理），组建临时处理小组，30分钟内完成初步响应。P3/P4级故障：分配至对应模块工程师（如网络故障交由网络工程师，软件故障交由应用工程师），2小时内响应。（二）故障信息收集与核实收集关键信息系统日志：导出操作系统日志（如Windows事件查看器、Linux的/var/log）、应用日志（如Tomcat的catalina.out、数据库的alertlog）、网络设备日志（如交换机的syslog）。用户操作记录：询问故障发生前用户的操作流程（如“是否安装了新软件”“是否修改了密码”），截图或录屏保存故障现象。系统状态检查：通过远程工具（如TeamViewer、SSH）登录服务器/终端，检查CPU、内存、磁盘使用率，网络连通性（如ping、telnet命令），服务运行状态（如Windows服务管理器、Linux的systemctlstatus）。信息核实与分类核查故障现象是否可复现：若为偶发故障，记录触发条件（如“高峰期出现”“特定操作后出现”）；若为必现故障，直接定位故障模块。依据收集的信息初步判断故障类型（硬件/软件/网络/数据/安全），明确排查方向。（三）故障根因分析分层排查法硬件层：检查设备指示灯（如服务器硬盘灯、交换机端口灯）、物理连接（如网线是否松动、电源是否正常），使用硬件检测工具（如MemTest内存检测、CrystalDiskInfo硬盘健康检测）确认硬件状态。系统层：检查操作系统版本是否兼容、系统文件是否损坏（如Windows的sfc/scannow命令、Linux的fsck命令）、系统服务是否异常（如依赖服务未启动）。应用层：检查应用程序版本、配置文件是否正确（如数据库连接串、中间件端口）、代码异常（如通过日志分析错误堆栈）、第三方接口是否故障。网络层：使用tracert跟进网络路径，检查防火墙规则、路由表配置、带宽占用情况（如iftop工具），确认是否存在网络拥堵或链路中断。工具辅助分析网络分析：用Wireshark抓包分析数据包异常（如丢包、重传）；功能分析：用PerfMon（Windows）、top（Linux）监控资源瓶颈；日志分析：用ELKStack（Elasticsearch+Logstash+Kibana）或Splunk集中分析日志，定位错误关键词（如“Connectionrefused”“Timeout”）。（四）制定修复方案方案设计原则优先保障业务恢复：对于P1/P2级故障，可采用临时措施（如切换备用服务器、重启服务）快速恢复业务，再根因修复；风险最小化：修复操作前评估风险（如数据丢失、服务中断范围），避免二次故障；可追溯性：方案需包含操作步骤、回退计划（如“若修复失败，回退至配置”）、责任人及时间节点。方案审批P1/P2级故障方案需经IT运维负责人（经理）审批；P3/P4级故障由模块工程师（工程师）确认即可执行。（五）执行修复操作操作前准备备份数据：对故障涉及的关键数据（如数据库、配置文件）进行全量或增量备份，保证可回退；环境隔离：若为安全故障，隔离受感染设备（如断网、下线受影响服务器）；工具确认：准备好修复所需的工具（如系统镜像、安装包、日志分析工具），保证版本兼容。按步骤执行修复示例（软件故障-服务无法启动）：停止故障服务：systemctlstoptomcat；检查服务日志：tail-f/usr/local/tomcat/logs/catalina.out，发觉“端口8080被占用”；终止占用进程：lsof-i:8088，kill-9<PID>；重启服务：systemctlstarttomcat；验证服务状态：systemctlstatustomcat，确认服务正常。异常处理若修复过程中出现新故障（如备份数据失败），立即停止操作，启动回退计划，上报负责人（*经理）。（六）修复验证与系统恢复功能验证核心功能测试：模拟用户操作流程，确认故障现象已解决（如“用户可正常登录CRM系统”“页面加载时间<3秒”）；关联功能测试：检查修复后是否影响其他模块（如“修复数据库连接后，报表功能是否正常”）；功能验证：监控系统资源（CPU、内存、网络）使用率，确认无功能瓶颈。业务恢复确认通知用户（如销售部）进行业务验证，确认无异常后，由业务负责人签字确认故障解决。（七）故障记录与归档填写故障记录表（详见模板1）详细记录故障从接收到解决的完整过程，包括关键时间节点、操作步骤、根因分析、修复方案、验证结果等，保证信息可追溯。文档归档将故障记录表、相关日志、截图、修复方案文档归档至知识库，按“故障类型+日期”命名（如“2024—CRM系统登录故障记录.docx”）。（八）复盘与优化故障复盘会议故障解决后24小时内，组织处理小组（经理、工程师、*用户）召开复盘会，分析故障根本原因（如“配置文件未更新”“硬件老化”）、处理流程中的不足（如“响应延迟”“信息遗漏”）。优化措施落地制定改进计划（如“更新配置文件管理流程”“更换老化服务器”），明确责任人（*工程师）和完成时间，跟踪落实情况，避免同类故障重复发生。三、核心记录模板模板1：IT系统故障记录表字段填写内容故障IDIT-2024-（按年份+序号自动）故障发生时间YYYY-MM-DDHH:MM:SS故障系统/模块如CRM系统、数据库服务器、核心交换机故障现象描述详细描述故障表现（如“用户输入账号密码后，页面提示‘验证失败’，无法登录”）故障级别P1（核心业务中断，影响全体用户）/P2（部分业务受影响，影响局部用户）/P3（轻微故障，不影响核心业务）/P4（信息类故障）上报人*用户（部门：销售部）联系方式内部通讯工具（如企业）初步处理人*工程师根因分析如“数据库连接池配置错误，导致连接数耗尽”修复方案如“调整连接池最大连接数从100增至200，重启数据库服务”修复时间YYYY-MM-DDHH:MM:SS验证结果如“用户可正常登录，系统响应时间<2秒，业务负责人签字确认”归档人*工程师备注如“后续需增加连接池监控告警，避免类似故障”模板2：故障排查步骤记录表步骤编号操作内容操作结果异常情况操作人操作时间1登录服务器，检查Tomcat服务状态服务显示“active(running)”-*工程师2024–14:352查看Tomcat日志catalina.out发觉“.BindException:Addressalreadyinuse”错误-*工程师2024–14:403执行lsof-i:8080查看占用进程进程PID为5，为Java应用进程-*工程师2024–14:454执行kill-95终止进程进程已终止-*工程师2024–14:505重启Tomcat服务服务启动成功，状态为“active”-*工程师2024–14:55四、关键注意事项与风险规避数据备份优先任何修复操作前，必须对故障涉及的关键数据进行备份（特别是数据库、配置文件），避免因操作失误导致数据丢失。备份数据需存储在独立存储设备中，保证与故障设备隔离。操作权限与复核高风险操作（如系统重装、数据库主从切换）需由2名及以上工程师共同确认，一人执行、一人复核，保证操作步骤准确无误。禁止使用个人账户执行运维操作，需统一使用企业授权的管理账户。沟通与同步故障处理过程中，需定期（每30分钟）向负责人（*经理）和受影响用户同步进展情况，避免信息差导致误解。重大故障（P1级）需实时上报IT部门负责人。避免过度修复修复范围需聚焦故障根因，避免对无关模块进行操作（如“因网络故障修复时，误删系统服务”），减少二次风险。若无法确认根因，优先采