IT系统故障排查标准化流程手册

IT系统故障排查标准化流程手册一、适用故障场景本手册适用于企业IT系统各类故障的标准化排查与处理，涵盖以下典型场景：系统不可用：如业务系统无法登录、页面报错502/503、数据库连接失败等导致业务中断的情况；功能异常：如系统响应缓慢、接口超时、服务器CPU/内存/磁盘占用率持续过高影响用户体验；功能失效：如核心业务流程卡顿、数据同步失败、第三方接口调用异常等模块功能异常；数据异常：如数据丢失、重复、错乱，或备份恢复失败等数据相关问题；安全事件：如疑似账号盗用、恶意攻击、漏洞利用等需紧急响应的安全类故障。二、标准化故障排查流程（一）故障发觉与上报故障发觉监控系统自动告警：通过Zabbix、Prometheus等工具触发CPU、内存、网络流量等阈值告警时，值班运维人员需立即查看告警详情；用户反馈：通过客服、企业群、工单系统等渠道收到用户反馈的故障现象时，需记录故障发生时间、用户操作路径、错误提示等信息；主动巡检：运维人员定期巡检系统状态时，发觉日志报错、服务进程异常等情况，需立即标记为待处理故障。故障上报值班人员确认故障后，10分钟内通过企业ITSM系统创建故障工单，填写“故障编号-故障类型-发生时间-初步现象”，并根据影响范围和严重程度划分优先级（P1-P4，P1为最高级，如全业务中断）；优先级P1/P2故障需立即通知运维主管及业务接口人，同步故障概况及初步影响；工单需明确“第一负责人”（一般为值班运维人员），全程跟踪处理进度，保证信息传递畅通。（二）故障初步分析信息收集收集故障现场信息：包括系统截图、错误日志（应用日志、系统日志、数据库日志）、用户操作记录、监控数据曲线（如故障前后5分钟的服务器功能指标）；确认故障范围：明确故障影响的具体业务模块、用户群体（如“仅华东区域用户无法登录”）、是否伴随其他关联系统异常。初步判断基于收集的信息，快速定位故障可能层级：基础设施层：服务器硬件故障（如磁盘坏道）、网络中断（如交换机宕机）、机房断电等；平台层：操作系统异常（如服务进程僵死）、中间件故障（如Tomcat启动失败）、数据库功能瓶颈（如锁表、连接池满）；应用层：代码BUG（如接口参数错误）、缓存失效（如Redis连接超时）、第三方服务依赖异常（如支付接口返回超时）；数据层：数据损坏、主从同步延迟、备份文件缺失等。若初步判断无法明确层级，需立即启动深度排查流程。（三）故障深度排查根据初步判断的故障层级，分层级使用工具进行精准定位：1.基础设施层排查硬件检查：通过iDRAC/iLO等远程管理工具查看服务器硬件状态，检查磁盘SMART信息、内存错误日志、CPU温度等；网络连通性测试：使用ping、tracert、telnet命令测试目标服务器端口可达性，如telnet192.168.1.1008080检查应用服务端口是否开放；网络设备检查：登录交换机/路由器查看端口流量、错误包统计，确认是否存在网络环路、带宽拥塞等问题。2.平台层排查操作系统检查：使用top、htop查看进程资源占用，jps检查Java进程状态，df-h检查磁盘空间是否不足；中间件检查：对于Tomcat，查看catalina.out日志定位启动失败原因，通过JConsole监控JVM内存泄漏；对于Nginx，检查error.log确认配置语法错误或upstream超时；数据库检查：通过showprocesslist查看MySQL连接状态，使用slow.log定位慢查询，执行showmasterstatus检查主从同步状态。3.应用层排查日志分析：使用ELK（Elasticsearch+Logstash+Kibana）或Splunk检索应用关键词错误（如“NullPointerException”“TimeoutException”），定位具体代码行或调用链；链路跟进：通过SkyWalking或Zipkin跟进接口调用路径，确认是服务内部异常还是下游依赖服务超时；压力测试：若怀疑功能问题，使用JMeter模拟并发请求，观察接口响应时间、错误率是否随负载升高而恶化。4.数据层排查数据一致性校验：对比主库与从库数据差异，使用pt-table-checksum工具检查MySQL数据一致性；备份文件验证：尝试恢复备份文件至测试环境，确认备份文件完整性及可恢复性；事务日志分析：通过MySQL的binlog或Oracle的redolog回放操作，定位数据异常发生的时间点及操作人。（四）解决方案实施临时措施：针对紧急故障（如P1级），优先实施临时恢复方案，保障业务尽快运行：服务重启：僵死进程或服务异常时，执行systemctlrestarttomcat或/etc/init.d/nginxrestart；流量切换：使用F5或Nginx负载均衡将故障节点流量切至备用节点；数据回滚：若数据异常由误操作导致，通过备份文件或binlog回滚至故障前状态。根本解决：临时措施生效后，48小时内完成根因分析并实施永久解决方案：代码修复：开发人员定位BUG后，提交代码版本更新并部署至测试环境验证；配置优化：调整数据库连接池大小（如maxActive:50）、JVM堆内存参数（如-Xms2g-Xmx4g）等；硬件更换：确认硬件故障后，联系供应商更换故障磁盘、内存等组件；第三方协调：若故障源于第三方服务（如短信接口），通过供应商工单推动问题解决。方案审批：P1/P2级解决方案需经运维主管及业务部门负责人审批后实施，P3/P4级由第一负责人评估后执行。（五）故障验证与复盘效果验证功能验证：在测试环境或灰度环境执行解决方案后，模拟用户操作路径，确认故障现象已消除，核心功能（如登录、下单、支付）恢复正常；功能验证：通过监控工具对比故障前后的系统功能指标（如CPU使用率、接口响应时间），确认未引入新的功能瓶颈；数据验证：校验修复后数据的完整性和一致性，保证无数据丢失或错乱。复盘总结故障解决后24小时内，由运维主管组织故障复盘会，参与人员包括第一负责人、开发、业务接口人等；复盘内容包括：故障发生原因（根因分析）、处理过程中的不足（如响应延迟、沟通不畅）、改进措施（如优化监控告警阈值、完善应急预案）；编写《故障复盘报告》，明确责任人和整改时限，同步至IT知识库，避免同类问题重复发生。三、配套记录模板模板1：IT故障初始记录表字段名填写说明示例故障编号ITSM系统自动，格式：FT+年月日+流水号（如FT2023901）FT2023901故障发生时间精确到分钟（如2023-10-0114:30:00）2023-10-0114:30:00发觉渠道监控告警/用户反馈/主动巡检监控告警故障现象具体描述故障表现，避免模糊表述（如“系统很慢”改为“订单接口响应超时5秒”）订单列表页加载失败，提示“500ServerError”影响范围明确影响业务/用户区域（如“华东区域用户”“支付模块”）全网用户无法登录严重程度P1（致命业务中断）/P2（严重功能异常）/P3（轻微功能下降）/P4（不影响业务）P1第一负责人值班运维人员姓名（用*代替）张*初步处理措施已执行的临时操作（如“重启Tomcat服务”）检查Tomcat日志，暂无处理模板2：故障排查过程记录表排查时间操作步骤使用工具/命令结果描述负责人14:35-14:40查看服务器CPU/内存/磁盘使用率Zabbix监控面板CPU使用率5%，内存70%，磁盘使用率85%（/data分区不足）张*14:40-14:45检查Tomcat应用日志tail-fcatalina.out报错“java.io.IOException:Nospaceleftondevice”张*14:45-14:55清理Tomcat临时文件及过期日志rm-rf/tmp/*&&find/logs-name“*.log”-mtime+7-delete/data分区释放空间20GB，磁盘使用率降至65%张*14:55-15:00重启Tomcat服务systemctlrestarttomcat服务启动成功，访问订单列表页正常张*模板3：故障解决方案验证表验证项目验证方法验证结果（通过/不通过）验证人验证时间用户登录功能模拟5个不同区域用户登录系统通过李*2023-10-0115:30订单接口功能JMeter并发100请求，持续10分钟，观察响应时间平均响应时间800ms，无错误李*2023-10-0115:45数据完整性对比故障前后订单主表数据，检查是否存在丢失或重复数据一致，无异常王*2023-10-0116:00四、关键操作提示安全规范：故障排查前需确认操作权限，避免越权访问生产环境；涉及服务器或数据库变更时，必须提前备份配置及数据；禁止在业务高峰期执行高风险操作（如重启核心服务、修改数据库结构），确需执行的需提前报批并通知业务方。沟通协作：故障处理过程中，第一负责人需每30分钟在ITSM系统更新处理进度，重大进展（如临时措施生效、根因定位）需即时同步相关方；若故障涉及多部门（如开发、网络、安全），需每日召开简短碰头会，同步进展及下一步计划。文档记录：所有操作步骤（包括临时措施和最终解决方案）需详细记录在排查过程记录表中，关键日志截图需作为附件留存；复盘报告需明确“根因分类”（如代码缺陷/配置错误/硬件故障/第三方原因