如果你做过运维或者后端开发一定遇到过这种情况。线上报警ERROR 日志激增第一反应通常是系统是不是挂了于是开始排查日志。一、事故背景某天生产环境出现报警服务oa-server 报警ERROR 日志突增 时间15:05日志系统里很快出现大量异常2026-03-08 15:05:09 ERROR GlobalExceptionHandler BusinessException: 该业务功能已绑定流程接下来几秒钟2026-03-08 15:05:10 ERROR GlobalExceptionHandler 2026-03-08 15:05:11 ERROR GlobalExceptionHandler 2026-03-08 15:05:12 ERROR GlobalExceptionHandler日志数量200 行此时值班工程师要判断一件事这是事故吗二、传统排查方式大多数团队排查流程差不多。第一步打开日志系统ELK Loki Kibana第二步搜索ERROR Exception第三步开始人工阅读日志。典型流程翻日志 找异常 分析堆栈 判断影响这个过程通常需要5 ~ 10 分钟如果日志多时间更长。三、运维真正想知道的其实只有三件事其实值班工程师只关心三个问题1 是否系统故障还是只是业务异常2 是否影响用户例如是否请求失败 是否服务不可用3 要不要现在处理可能是立即处理也可能只是观察但这些结论通常要翻完日志才能判断。四、AI 自动分析日志为了减少人工翻日志的时间我做了一个开源工具Incident Community核心能力日志 → 自动生成事故报告五、AI 分析结果同样一段日志BusinessException: 该业务功能已绑定流程系统生成的事故报告 Incident Report Service: oa-server Environment: production Severity: P3 Root Cause BusinessException triggered by business rule. Impact No system failure detected. Recommendation No immediate action required.核心结论其实只有两句话结论业务异常 动作无需处理值班工程师5 秒就能判断情况。六、事故报告自动生成系统还能生成完整事故复盘报告# Incident Report ## Incident Summary Service: oa-server Environment: production ## Root Cause Business rule triggered BusinessException. ## Impact No service outage detected. ## Recommendation No action required.支持导出Markdown HTML PDF方便事故复盘 团队知识库 技术博客七、为什么做这个工具在很多团队里运维每天都在做重复的事情翻日志 找异常 写事故报告如果这些事情可以自动化排查效率会提高很多这也是我做这个项目的原因。八、开源项目项目地址https://github.com/LukeGitHub-xd/incident-community核心功能日志上传分析支持日志文件 文本日志自动异常识别识别Exception Error Timeout Database errors自动生成事故报告报告包含事故概述 根因分析 影响范围 修复建议多格式导出支持Markdown HTML PDF九、总结很多线上事故排查的时间其实都花在翻日志如果日志可以自动生成结论排查效率会提升很多如果你也遇到过凌晨报警 翻几百行日志 不知道问题严不严重可以看看这个项目https://github.com/LukeGitHub-xd/incident-community如果觉得有帮助欢迎给一个 ⭐ Star。