把Sentry报错变成GitHub issue
Okou是一个自动完成每日报错分诊的AI DevOps智能体。每天早上，它从Sentry和Axiom拉取未解决的报错，跨两个来源去重，在站会之前建好带完整堆栈的GitHub issue并指派到人，为工程师省下20到30分钟的人工排查。
Okou交付什么：一份每日报错分诊报告
看一份AI生成的报错分诊报告样例：按优先级排列的事故、跨来源去重、已指派的GitHub issue、严重程度、发生量和节省的时间。其中的数据仅作示意，报告格式则是Okou基于Sentry和Axiom能真实生成的产物。
智能体总结
Okou检查了来自Sentry和Axiom的17条原始报错，去重后归为13个根因，建了6个已指派的GitHub issue，另有2条只需观察的信号发到了#dev。
- 检查的原始报错
- 17Sentry 12条 · Axiom 5条
- 独立根因
- 13去重之后
- 创建的GitHub issue
- 6全部已指派
什么是报错分诊？
报错分诊，也叫bug分诊或事故分诊，是把生产环境的报错分组、排优先级并指派到人的过程，目的是让工程师知道先修哪一个。Okou在Sentry、Axiom和GitHub之间扮演AI SRE智能体的角色：给报错去重、套用阈值、附上堆栈、指派代码负责人。结果是一套稳定的每日报错分诊自动化，告警疲劳也更少。
人工分诊为什么会带来告警疲劳
每天早上，工程师都要打开Sentry翻一遍未解决的告警，再到Axiom交叉核对，分清哪些是新问题、哪些是重复的，判断哪些严重，建GitHub issue，再找到该负责的人。这一轮重复的初筛要花掉20到30分钟的专注时间，正事还没开始，告警疲劳就先来了。Okou在早上8:45运行，在所有人打开电脑之前就把同样的分诊做完。
Okou如何自动完成每日报错分诊
第一步：连接你的工具
第二步：交给Okou
第三步：再往前一步
报错分诊用到的Sentry、GitHub和Axiom集成
这条工作流就是一套中间站着智能体的Sentry与GitHub集成：Okou从Sentry读取，在Axiom里核对同一个时间窗口，再写入GitHub。每个连接器都单独授权，权限范围只覆盖工作流真正用到的部分，所以读取报错数据的权限，不会顺带变成写入你仓库的权限。
Sentry集成：Okou读取的报错
必需Okou通过Sentry的issues API读取你的报错监控数据，按你指定的环境查询未解决的报错，并按出现频率排序。对每一条，它会读取标题和出错位置、事件次数和受影响用户数、级别，以及首次和最近一次出现的时间，再取出最新一次事件，拿到完整堆栈及其版本和环境标签。分诊判断需要的信息就都齐了：坏了什么、多频繁、在哪里、从什么时候开始。这条工作流里的Sentry集成是只读的。Okou不会把你的Sentry issue标成已解决、合并或改派，它写下的记录只会进GitHub。
GitHub集成：Okou建出的issue
必需每一条越过阈值的报错，都会在你指定的仓库里变成一个GitHub issue。issue里带着报错标题、堆栈、出现次数和受影响用户数、首次与最近一次出现的时间，还有一个回到原Sentry issue的链接，原始数据始终只隔一次点击。Okou会打上你指定的标签，并按堆栈里出现的文件指派代码负责人。写入权限只限于你授权的仓库，而且它只会建issue：不提交代码、不开pull request、不碰仓库设置。
Axiom集成：Okou交叉比对的Axiom日志
可选Axiom是可选的，它的价值体现在去重上。如果你的日志管理已经跑在Axiom上，Okou会在同一轮里一起读：对你选定的数据集执行一次APL查询，时间窗口与拉取Sentry时保持一致，再把这些Axiom日志和它已有的报错特征做匹配。这样就能抓到同一个故障以两种格式出现两次的情况，也补上了单看Sentry事件拿不到的请求级上下文。不接Axiom，这条工作流照样能跑完，只是去重会退回到只用Sentry的数据。
Okou、人工分诊与Sentry告警规则的对比
每日报错分诊是自动化事故响应的第一层。团队用Okou把Sentry接到GitHub，在问题需要更大范围的AI事故管理之前，先把重复的初筛做完。
人工分诊
工程师自己看Sentry和Axiom，找出重复项，判断严重程度，建issue，再找到负责人。灵活，但每天早上都要重复同样的20到30分钟。
Sentry告警规则
阈值一旦越过，规则就会通知团队。用来发现问题很有用，但关联日志、给报错去重、建GitHub issue、指派负责人，还是得团队自己来。
Okou的Sentry工作流自动化
Okou把这套Sentry自动化从头跑到尾：查询、跨来源去重、阈值过滤、建issue、附上堆栈、指派代码负责人。随时触发和发布后运行，用的都是同一条工作流。
让效果更好的几个建议
常见问题
怎么把Sentry的报错分诊成GitHub issue？
想从Sentry自动生成GitHub issue，先把Sentry和GitHub连到Okou，再给它一个定时任务或者一条随时触发的提示词。Okou会查询未解决的报错，按出现次数和环境过滤，为每条符合条件的报错建一个issue，附上堆栈和时间，并指派代码负责人。
怎么跨Sentry和Axiom给报错去重？
可以。Okou会跨Sentry和Axiom比对报错特征、堆栈、消息内容和发生时间，再把匹配上的事件合并成一条分诊记录。每个原始来源都仍然保留链接，方便继续排查。
怎么减轻报错监控带来的告警疲劳？
把分诊限定在生产环境，设一个出现次数阈值，跨工具给同一个报错去重，量少的报错只进汇总、不单独建issue。这样队列里留下的，就都是真正需要动手的报错。
每次发布之后能让Okou跑一次报错分诊吗？
可以。建一条自动化，在发布或者代码合入main之后启动报错分诊工作流，需要的话先留一小段观察时间，然后检查Sentry里生产环境的新报错，并为符合条件的建issue。
这套报错分诊自动化需要哪些工具？
Sentry和GitHub是必需的：Sentry提供报错数据，GitHub接收指派好的issue。Axiom可选，但它能补上日志上下文，也让跨来源去重更准。
Sentry与GitHub的集成需要哪些权限？
Sentry需要你所分诊项目里issue和事件的读取权限。GitHub需要接收issue的那些仓库的issue写入权限。如果你用Axiom，它需要你指定数据集的查询权限。每个连接器都在Okou里单独授权，撤销其中一个不影响其他。
Okou能把issue建到多个GitHub仓库吗？
可以。告诉Okou哪个服务或项目对应哪个仓库，它就会照着分流，前端报错进web仓库，API报错进后端仓库。这套对应关系写在提示词里，要改的时候不用重新配置GitHub连接器。
Okou会改动Sentry里的东西吗？
不会。这里的Sentry集成是只读的：Okou只查询issue和事件，不写回任何内容。你的issue状态、指派和处理记录，都保持团队原来的样子。Okou唯一创建的，是GitHub issue。
跑一次你的Sentry分诊
连上Sentry和GitHub，需要的话再加上Axiom。直接用同一条每日分诊提示词，不必手动搭一遍，就能看到工作流跑起来。
