新卒3年目の私がやらかしたユーザー影響0件の「隠れた障害」

クラメソふくおかIT勉強会#6〜もう戻れない！AIで変わった仕事のやり方LT会〜
https://classmethod.connpass.com/event/401637/

LT登壇資料

Transcript

1. 新卒3年目の私がやらかしたユーザー影響0件の「隠れた障害」 y.satoshi | クラメソふくおかIT勉強会#5〜ヒヤッとしたIT恐怖体験LT会〜 | 2026-07-23 1
2. 自己紹介 名前：吉田悟（y.satoshi） 所属：某クレジットカード会社 経歴：新卒入社4年目 / 決済機能のバックエンド担当（たまにフロントも） 今日の話：昨年（3年目）にやらかした体験談です 技術スタック：Java / AWS / MySQL / Nuxt 個人開発：Kotlin/ Astro / Hono / Cloudflare 2
3. 「ユーザー影響0件」ってどういうこと？？ 3
4. 背景 2025年6月。とあるプロジェクト対応中 システム：Nuxt（フロント） × Java SpringBoot（API/バッチ） × MySQL 担当タスク：ユーザー向けメール通知機能の対象拡張 決済通知テーブルのシャーディングテーブル追加（← 私の担当） バッチ処理・APIの改修（← 他メンバー） 文言等のフロントエンドの改修（← 他メンバー） 既存テーブル：通知ON/OFF機能はすでに存在（今回は触る予定なしだった） 4
5. 設計レビューで降ってきた追加タスク Aさん：「既存の通知ON/OFFテーブルのカラムコメント、古い機能名が残ってるよね。新 テーブル追加するついでに修正しておいて」 私：「わかりましたー！」 → 軽く受けたこの一言が、まさかの事故につながる。 5
6. 本番DB修正当日 やること： シャーディングテーブルの追加（本来の担当タスク） 既存の通知ON/OFFテーブルのカラムコメント修正（追加でお願いされた分） → どちらも同じ日に、まとめて本番へ。 6
7. 実行したALTER TABLE 言われた通り、既存の通知ON/OFFテーブルのカラムコメントを ALTER TABLE で修正。 実はこれが危険だった： MySQLの ALTER TABLE は「変更」ではなく 「再定義」。 コメントだけ変えたつもりが、 DEFAULT 句をまるごと消してしまった。 -- Before status TINYINT NOT NULL DEFAULT 0 COMMENT '旧コメント' -- After（コメント変更のつもりが） ALTER TABLE notifications MODIFY COLUMN status TINYINT NOT NULL COMMENT '新しいコメント'; -- ※ DEFAULT 0 が消えた 7
8. 作業して数分後にアラートで出した 別チームから「ある時間帯からアラートが複数出てる」と周知あり。 「自分たちの作業は関係ないはず…」 と思っていた。 8
9. でも、実は—— 9
10. やらかし発生 「吉田さん。これ、さっきの作業の影響です。」 観点 内容 症状 あるバッチが特定の条件でINSERTが失敗 原因 DEFAULT 消失 → NULL → NOT NULL 制約で弾かれる 影響なしの理由 INSERT失敗＝機能が未開放なだけ NOT NULLがなければ？ NULLのままINSERT → 後続処理でユーザー影響発生 10
11. 気づいた瞬間 別チームからアラート大量発生の周知 DDLを管理しているリポジトリで DEFAULT 句が消えていることを別チームが発見 自分のチームに連絡が来た そのときの感情： 「やってしまったあああああ！！」 11
12. 学んだこと MySQLの ALTER TABLE は再定義に注意！ MODIFY COLUMN は指定した定義で丸ごと再定義される 変更前に現在の定義を確認する： SHOW CREATE TABLE テーブル名; 大事なのは 「差分が見える仕組み」 を持つこと GUIがあればいいわけじゃない 実行前後のDDLを比較できるプロセスがないといけない 退勤後に家で検証して Zenn に投稿しました https://zenn.dev/y_satoshi/articles/article20250620 12
13. 余談 今回の経験を経て、DBに興味を持った アプリは疎結合・変更しやすい設計を目指せる 「DBは変えにくい」 → だからこそテーブル設計は最初が肝心 現在、10億レコード近いテーブルの移行を絶賛進行中（胃をキリキリしながら…） カラム拡張に伴い過去データを削除しようとしたところ、参照している処理が発覚 「最初から更新用と参照用でテーブルを分けておけば…」という典型的な後悔 13
14. まとめ 「ユーザーに気づかれなかった」は「問題なかった」じゃない。 NOT NULL が偶然セーフガードになっただけ。次は防いでくれるとは限らない。 ALTER TABLE は「変更」ではなく「再定義」 SHOW CREATE TABLE で変更前後の差分を確認する 今回の一件も、さっきのテーブル移行の苦労も、根っこは同じ DBは一度作ると変えにくいという前提を忘れない 14
15. ご清聴ありがとうございました 15