Go製アプリが32bit ARM組み込みLinuxで断続的にクラッシュする問題を調査した記事。原因はGoランタイムのnetpollがeventfdとソケットfdを区別する際に使うev.Dataフィールドで、生ポインタとタグ付きポインタが混在し32bitリトルエンディアン環境でfdseqカウンタとアドレスがエイリアスしてしまうこと。長時間稼働しfdseqが数百万に達すると発生し、著者はテストケースを作成してGo本体に修正パッチを提案・マージされた。
AIによるバグ調査は見立てが外れやすいため、使い捨てのPlaywright再現テストで原因を確定させる手法を紹介。①症状把握→②AIと原因を言語化（実装させない・丸めさせない・推測を事実化させない）→③実装セッションと切り離して再現コードを書かせる→④修正前に「落ちる」ことを確認して資料を事実化→⑤新セッションに資料だけ渡して修正→⑥確認後は再現コードを捨てスクショのみ残す、という6工程。再現条件が確定すると「このバグ直して」という指示の精度が飛躍的に上がる。最大の敵はflaky挙動で、踏んだ穴をAIに記録させ蓄積することで対処。画面に出ないロジック層のバグには適用できないという限界もある。
nginxで散発的に発生する502 Bad Gatewayの原因はkeepaliveで再利用される接続にある。バックエンド停止時にFINが届いても、処理中のworkerはイベントループが埋まっておりすぐには気づかず、プールから閉じかけの接続を取り出して書き込むためRSTやconnection resetが発生する。GETは既定のリトライで隠れるがPOSTは502として返る。GitHub Actionsでの検証では、再起動なしで502が0件、再起動ありで98件発生した。対策としてはバックエンド停止前にupstreamから切り離してreloadするのが最も有効で、non_idempotentによるPOST再送は二重実行のリスクがあり、keepalive_timeoutの短縮は競合のタイムスケールが合わず効果がなかった。
本番障害デバッグを1仮説先行から5仮説並列（データ層/通信層/タイミング/依存関係/環境差）に変えたところ、30日12件の平均解決時間が47分から15分に短縮した実践記録。確証バイアス（Wason 1960）や5 Whysの限界を根拠に、初動3分で仮説を書き出し反証テストを添える手法と、Resolve AI・Sentry等のAIデバッグツールの多仮説並列アプローチも紹介している。