信息软件系统故障处理方案

信息软件系统故障处理方案一、故障分级与响应时效1.一级故障：核心交易链路中断、数据一致性破坏、全网不可用。响应：值班工程师3分钟内电话确认，15分钟内完成主备切换或降级，30分钟内给出初步根因定位，2小时内提交修复版本或热补丁。2.二级故障：非核心模块不可用、局部性能衰减50%以上、监控误报率高于20%。响应：值班工程师5分钟内认领，45分钟内给出临时方案，4小时内提交回归测试报告。3.三级故障：偶发异常、日志报错低于0.1%、无用户感知。响应：次日版本评审会统一排期，72小时内完成修复。二、值班与升级机制1.7×24小时三级值班：L1一线值守（驻机房或VPN待命），L2模块Owner，L3架构师与供应商专家。2.升级路径：故障发生10分钟未定位→自动电话通知L2；30分钟未恢复→拉通L3与CTO级别群组；60分钟仍无进展→启动“战情室”视频会议，冻结当日所有非紧急发布。三、信息收集checklist（打印贴在监控台）1.时间轴：故障发现、用户报障、监控告警、操作记录四列精确到秒。2.环境指纹：版本号、配置MD5、容器镜像SHA、操作系统内核、宿主机型号、网络设备固件。3.数据指纹：最近10分钟QPS、RT、错误码分布、线程池水位、GC次数、TCP重传、磁盘IOutil、慢查询Top10。4.变更指纹：最近7天代码合并记录、配置中心推送、灰度比例、数据库DDL、网络ACL、证书替换。5.外部依赖：CDN、短信网关、支付渠道、第三方SDK、DNS、NTP。四、快速止血四板斧1.回滚：配置回滚优先于代码回滚，配置回滚60秒完成；代码回滚使用蓝绿发布平台，10秒内流量清零。2.隔离：按“用户维度+接口维度”双重熔断，先切流量再重启实例，防止雪崩。3.降级：预置“功能开关+Mock数据”，一级故障默认降级非关键功能，降级后写操作转异步队列。4.限流：令牌桶与漏桶组合，网关层按用户等级、IP段、接口类型三维限流，突发流量时先丢弃5%低优先级请求。五、根因定位实战流程1.建群：拉通开发、测试、运维、DBA、网络、安全六方，群名“RCA-日期-模块”，所有发言@责任人，禁止语音，方便后续溯源。2.画图：使用统一白板工具，先画“用户→网关→服务→缓存→数据库”五层拓扑，再叠加“时间轴”与“变更轴”，颜色标记异常指标。3.对比：找“最后一台正常实例”，把它的内存、线程、网络抓包与故障实例做diff，使用BeyondCompare与Wireshark并排分析。4.复现：在staging环境回放1:1流量，使用GoReplay或TcpCopy，禁止直接在生产压测；若复现失败，则检查时钟、数据、密钥差异。5.定位：a.CPU飙高：perftop查看热点函数，若出现GC标记线程占比>30%，检查是否大对象晋升；b.内存泄漏：pmap-x后按大小排序，若[anon]持续增长，使用jeprof生成火焰图；c.线程阻塞：jstack连续三次采样，过滤TIMED_WAITING与BLOCKED，若80%卡在同一锁，查看锁持有者；d.网络超时：tcpdump抓包看RTT与重传，若SYN重传>3次，检查防火墙conntrack表是否被打爆；e.慢查询：MySQL执行计划对比，若rows_examined相差1000倍以上，查看是否隐式转换或索引缺失；f.缓存穿透：Redis监控键命中率，若低于50%且存在单Key空值，检查布隆过滤器是否被清空。六、典型故障场景剧本1.缓存雪崩现象：缓存集群80%Key同时过期，QPS瞬间打到数据库，连接池耗尽。剧本：①立即启动“缓存续命”脚本，随机过期时间追加0-300秒抖动；②网关层开启“降级开关”，读接口返回304与本地stale数据；③DBA将数据库最大连接临时上调50%，同时开启线程池隔离；④事后把过期时间打散到24小时窗口，并增加二级缓存（本地Caffeine）。2.消息队列堆积现象：Kafka消费延迟30分钟，Lag持续增加，业务方反馈订单状态未同步。剧本：①检查消费组重平衡日志，若出现“coordinator负载高”，立即扩容分区；②临时调大fetch.min.bytes=1与max.poll.records=500，提高拉取效率；③将非关键日志topic降级到异步落盘，释放磁盘IO；④若仍无法消化，启用“批量补偿”方案：消费端双写Redis与数据库，后续离线校验。3.容器节点NotReady现象：K8s节点状态变为NotReady，其Pod无法调度，业务副本数下降。剧本：①登录节点执行journalctl-ukubelet，若出现PLEG超时，重启containerd；②检查磁盘inode，若小于5%，清理孤儿镜像与日志；③若节点硬件故障，使用kubectldrain--force--ignore-daemonsets驱逐Pod；④启用集群级自动修复（NodeAutoRepair），15分钟未恢复则触发重建。4.证书过期现象：HTTPS握手失败，浏览器报ERR_CERT_DATE_INVALID，支付回调全部超时。剧本：①立即在CDN控制台上传新证书，强制刷新全网边缘节点；②源站使用acme.sh自动续签，并设置30天预警；③对旧证书做OCSPstapling关闭，防止客户端继续校验；④事后把证书有效期写入Prometheus，提前60天告警。5.线程池耗尽现象：应用日志出现RejectedExecutionException，接口503比例升高。剧本：①查看线程池配置，若核心线程=最大线程，立即调大max并开启队列监控；②使用Hystrix或Sentinel包裹，设置99RT作为熔断阈值；③把耗时操作拆分为异步线程池，与业务线程池隔离；④上线前通过ChaosBlade注入线程满载故障，验证熔断效果。七、应急工具箱（一键脚本已放/opt/sre/bin）1.fast_rollback.sh传入服务名与版本号，60秒内完成镜像回滚；2.network_tap.sh自动在sidecar容器注入tcpdump，输出到OSS，默认抓100M包；3.jvm_stats.sh每5秒采样一次GC、线程、内存，生成CSV便于Excel绘图；4.sql_kill.sh按关键字Kill慢查询，支持MySQL与PostgreSQL；5.redis_flushdb.sh带二次确认与备份，可指定前缀删除，防止误操作；6.k8s_pdb_check.sh检查PodDisruptionBudget是否满足，防止节点维护时可用副本不足。八、灰度与验证1.灰度策略：按“内部员工→10%真实用户→30%→50%→100%”四阶段，每阶段持续6小时，错误率高于0.1%立即暂停。2.监控指标：业务成功率、P99延迟、GC次数、慢查询、错误日志、容器重启次数、带宽峰值。3.自动化用例：使用Gatling模拟1万并发，断言成功率>99.5%，P99<500ms；同时跑1000条单元测试与200条集成测试，全部通过方可进入下一阶段。九、数据修复与对账1.主备不一致：先锁写主库，使用pt-table-checksum做差异校验，生成修复SQL，经DBA二次审核后执行。2.消息重复：以业务唯一键为幂等键，在消费端插入前先selectforupdate，若已存在则丢弃；事后跑离线MapReduce任务去重。3.金额差错：对账系统每日04:00拉取支付渠道账单，与本地订单逐笔核对；差异>1分钱自动开ticket，财务、运维、开发三方会签。十、复盘与改进1.复盘会议：故障恢复后24小时内召开，时长控制45分钟，禁止追责，聚焦流程缺陷。2.五问法：连续追问五次“为什么”，直到找到可改进流程，而非人为失误。3.行动项：每一条必须含“责任人+完成时间+验收标准”，用Jira跟踪，逾期自动升级给部门总监。4.经验库：把故障报告转成Markdown存入GitBook，按“现象-根因-止血-修复-复盘”五段式模板，供全文检索。5.演练：每季度举行“红蓝对抗”，红队注入故障，蓝队负责恢复，演练后更新playbook，确保文档与系统同步演进。十一、容量与混沌工程1.容量模型：采用Little’sLaw计算L=λ×W，结合历史峰值乘以1.5倍冗余，CPU利用率不超60%，内存不超70%，网络带宽不超50%。2.混沌实验：每月随机下线5%节点、注入200ms网络延迟、杀进程、打满磁盘，验证自愈与告警有效性；实验结果低于80分（满分100）立即整改。十二、安全与合规1.故障期间禁止把生产数据下载到个人电脑，所有临时表加_tmp后缀并设置72小时TTL。2.日志脱敏：手机号、身份证、卡号采用中间6位打星，脱敏逻辑封装在日志框架层，防止工程师手工遗漏。3.权限回收：应急账号使用后2小时内由安全团队强制下线，并生成审计报告。十三、沟通与舆情1.对内：每30分钟更新Confluence公告栏，标注“当前进展/预计恢复/影响范围”，避免重复询问。2.对外：由PR部门统一口径，模板“我们注意到部分用户反馈××问题，技术团队正在全力处理，将在××时间前更新进展”，禁止工程师私自发微博或朋友圈。十四、知识考核与培训1.入职3个月内必须通过“故障处理”上机考试：给