なぜそう壊れるのか「障害を切り分ける技術」を書きました

1. なぜそう壊れるのか ? 「障害を切り分ける技術」を書きました tamachi.sre#7 渡部 龍一
2. 自己紹介 • 渡部龍一(@ryuichi_1208) • IVRyのSRE • 『SREの知識地図』の著者の一人 • tamachi.sreの運営の一人
3. 11月18日発売です Software Design 12月号
4. 障害調査あるある
5. 障害発生時 😫「リトライを入れたのに障害が悪化した」 😫「タイムアウトを設定したのに接続が切れない」 😫「メモリは余っているのに OOM で殺された」
6. 障害調査中 😫「ログを1時間眺めても、どこを見ればいいかわからん」 😫「CPU は余っているのに p99 だけ悪い」
7. 障害対応後 😫「再起動したら直った。原因は不明です」 😫「これ、また深夜に起こされるやつでは…？」
8. 障害を切り分ける技術
9. どんな特集？ 「なぜそう壊れるのか」を一段下の仕組みから解説 • 11月18日発売の Software Design 12月号 第1特集 • 全6章、40ページ強 • 観察コマンドと小さなコード例で解説
10. 障害は抽象化の破れ目で起きる フレームワークやマネージドサービスが隠している層の話 • 平常時は、その層を意識しなくて済む • 壊れたときは、その下を知らないと仮説すら立たない 仮説の引き出しを増やすための特集です
11. 章構成 ① 障害調査はなぜ迷子になるのか — 仮説駆動の調査ループ ② プロセスの死を切り分ける — SIGTERM、OOM Killer、FD 枯渇 ③ 「返事が来ない」を切り分ける — タイムアウト、リトライの増幅 ④ ダッシュボードの数字を正しく疑う — CPU スロットリング ⑤ 本番デバッグ演習 — p99 の悪化とメモリ増加を通しで調査 ⑥ まとめ — 症状から最初の一手を引けるチェックリスト
12. 特集を読むと「あるある」はこう変わる 😫「リトライを入れたのに障害が悪化した」 → 第3章：タイムアウトの階層と、リトライによる障害の増幅 😫「メモリは余っているのに OOM で殺された」 → 第2章：cgroup の OOM Killer と、プロセスの終了理由 😫「CPU は余っているのに p99 だけ悪い」 → 第4章：CPU スロットリングと、数字の出どころ
13. 書いてみて
14. 書いてみて 💡 削るほうが難しかった（200ページ → 43〜44ページ） 💡 人に読んでもらうと、説明の抜けが見える
15. https://ryuichi1208.hateblo.jp/entry/2026/11/11/133847
16. 11月18日発売です Software Design 12月号