寄稿記事

巻頭言：Think ITでのインシデントレスポンスの連載企画が始まりました

書いた人：しょっさん（ @syossan27 ）

Think ITさんとSRE Kaigiのコラボ企画として始まった、インシデントレスポンスの連載のお知らせです。

初めてのKubernetes本番運用でハマった話 ── 503をログから追いかけて

書いた人：Ryunosuke（ @Kobujee_53 ）

専任SREのいない体制・監視基盤ほぼゼロの状態で GKE Autopilot の本番運用を始め、503 が止まらなくなった障害の調査記録です。ログだけを頼りに原因を追いかけて見つけた5つの落とし穴を通して、リリース初期からオブザーバビリティが必要な理由を書いています。

ArgoWorkflow + Events を導入して撤退した話 - SRE的振り返り

書いた人：saorio（ @sao_rio ）

Argo Workflow + Argo Events を PubSub 起点の GKE Job 基盤で運用した実体験をもとに、Cluster Autoscaler の 0 -> 1 起動遅延、retryStrategy の限界、通知の観測性不足、NATS 由来の運用課題を整理し、最終的に Kubernetes Job へ撤退した意思決定と SRE 的教訓を振り返る記事です。

国内外のSRE記事

Incident Report: July 2, 2026 — US East Services Outage

アプリケーションデプロイ基盤を提供するRailway社のRay Chen氏による7月2日に発生した障害の報告記事です。 上流ISPの劣化に対応する過程で経路が一時的に不安定になり、その間にサーバーが管理用ネットワークへフォールバックしたまま、復旧後もコネクションが貼り直されなかったことが原因として説明されています。ルーティングテーブルは正常でストレージも問題なし、しかしスループットだけが3分の1に落ちるという状態が続いたそうです。「復旧後、何一つ正しい状態を再主張しなかった」という自己分析が印象に残る記事です。

Runbooks That Run Themselves

アラートはランブックを指すが、ランブックは何をすべきか説明するだけで実行はしてくれない、という問題意識から書かれた記事です。 そこにもう一手を足し、アラート -> ランブック -> スキルという連鎖を作ることが提案されています。スキルはチャットプロンプトではなく、リポジトリに置かれコードと同じくレビューされる、SKILL.mdとreferences/のフォルダです。方法論とデータを分けることで、新しいバージョンへの対応がリファレンスへの1行追加で済み、手順が腐らずに育っていく設計になっています。ランブックを読むものから呼び出すものへと変える具体案として参考になります。

AI Reliability Engineering

Alex Ewerlöf氏による記事です。 SREのツールボックスは他人が書いたコードを確実に運用するために進化してきたのだから、AIが生成したブラックボックスにも同じ道具が効くはずだ、という主張が展開されています。Ralphループはリトライパターンの簡易版、RAGは文脈窓という制約下での関心の分離、というようにAI界隈の言葉が既存のSREの言葉に翻訳し直されていく点が面白いです。

The curious case of Google’s AlloyDB

PostgreSQLの内部構造を掘り下げているboringSQLのRadim Marek氏による、12ヶ月にわたるAlloyDBの評価記事です。 「PostgreSQL完全互換」はワイヤプロトコルの層では真実だが、その下は別物である、という切り分けから始まります。特に興味深いのは、adaptive autovacuumはvacuumの作業をなくしたのではなく、スケジューラを置き換えただけだと実測で示され、コミュニティ版に合わせて調整した監視閾値が意味を変えてしまうという指摘です。TPC-H やコスト試算を含む検証がリポジトリごと公開されており、マネージドサービスの採用を性能の数字だけでなく、どこまでをベンダーに委ねるかという観点で考えるための材料になります。

コアダンプの疫学：18年間見過ごされていたバグを修正

OpenAIのNathan Bronson氏による、原因不明のクラッシュを追った調査記事です。 1件ずつコアダンプを精読する進め方から、1年分をまとめて解析して母集団のパターンを見る進め方へ切り替えたところ、それが無関係な2つのバグだったことが判明します。片方はハードウェア障害、もう片方はGNU libunwindに18年間存在していた競合状態でした。最も重要だったのは高品質なデータセットを作ることだった、という結論はオブザーバビリティの設計論としても読める内容です。

AI SREの現在地とその可能性

スリーシェイク社のSreakeチームに所属するKato Yasutaka氏による、AI SREの現在地を確かめた検証記事です。AWS上に用意した同一の障害シナリオを、AWS DevOps Agent・Datadog Bits AI・OpenSRE・Claude Codeの4つに調査させ、根本原因への到達度と調査時間を比較しています。過去の操作履歴やアラートをノイズとして拾うと推論が逸れる一方、トリガーを人間が指定するとノイズが減って根本原因に近づく、という差が出た点が読みどころです。各ツールの実際の出力ログと末尾の比較表を見ると全体像が掴みやすいと思います。「SREは障害対応だけの仕事ではない」という締めも含め、AI SREの現在地を確認できる記事となっています。

Kubernetes上の通信がなぜか15分で途切れてしまう謎を解明した話

ユーザベース社スピーダ事業の清水氏による、Kubernetes上の通信が15分で途切れる現象を追った調査記事です。 エージェント側は200を返しているのにクライアント側にレスポンスが返ってこない、という現象の原因がkube-proxyのIPVSモードにあり、無通信のTCPコネクションが管理テーブルから削除されていたことが突き止められています。RSTもFINも送出されないため、双方がコネクションは生きていると誤認し続けるという状態だったとのことです。対処はクライアント側でTCP keepaliveを有効にするということでした。AIアプリの増加でレスポンスの長いケースが増える今、読んでおきたい記事です。