把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。直接用同一條每日分診提示詞，不必手動搭一遍，就能看到工作流跑起來。
