ランチ中のXで自社インシデントを検知した話(2026年7月24日唐揚げ会)

第五回 唐揚げ会で登壇した資料です。
テーマは「今だから言える開発現場の失敗談」
https://karaage.connpass.com/event/396922/

Transcript

1. ランチ中のXで自社インシデントを検知した話 〜悪夢の誤デプロイから、日次リリースの完全自動化へ〜 株式会社 プロダクトエンジニア 河村康治 HITOTSU 2026.07.24 第五回 唐揚げ会 1
2. 自己紹介 経歴: 2017年4月 保険系SIer 4年 2021年9月 フリーランス 2023年5月 HITOTSU株式会社 入社 得意言語: Go、React、関西型言語 2
3. 今日話すこと ① 悪夢は突然に〜本番誤デプロイの一部始終〜 ② なぜ起きたのか？ 仕組みの問題 ③ 再発防止策：暫定対応 → 恒久対応 ④ 発展編：日次リリースの全自動化へ 3
4. ① 事件 悪夢は突然に 4
5. いつもの風景：STG環境にデプロイ 社内QAのため、STG環境にプログラムをリリース デプロイには 約10分 かかる 「回している間にお昼を買いに行こう」 ランチを買いに近所のスーパーへ 👆 この「10分の隙間」が悪夢の入口だった… 5
6. お昼にXを開いたら… 「あれ？ サービス落ちてない？💦」 「ログイン画面に戻される…」 6
7. 本番障害をXで検知 「心当たりがある」— プルダウンで「本番」を選んだ記憶がフラッシュ バック 全身の毛穴から冷や汗が噴き出す 💦 7
8. お昼の買い物をとり止め、全力疾走で職場へ お昼のお弁当の購入を取りやめ家へ全力疾走 まずは本番環境にアクセスし、本番障害を確 認。 エンジニアを集めて状況を共有 BizサイドやCSチームへインシデントを報告 8
9. 暫定対応：ロールバック 本番環境へ正しいプログラムを再デプロイ（ロールバック）開始 待っている間が永遠に感じた 11分間… 12:52 復旧完了 12:41 🛡️ 不幸中の幸い ログイン後に初回APIが即コケる → 白画面でログアウト データの不整合・DB汚染は 一切発生せず 9
10. インシデントの結果：時系列 12:09 STGへのデプロイを実行（実際は本番環境に） 12:20 デプロイ完了 → お昼を買いに外出 🍱 12:30 Xのユーザーツイートで本番障害を検知 😱 12:41 本番環境へのロールバック開始 12:52 復旧完了 ✅ （障害時間：32分間） 10
11. 業務影響 影響範囲: 全ユーザー 停止時間: 12:20 〜 12:52（32分間） 影響内容: ログイン後、白画面になりログイン画面に戻る ログイン中のユーザーも強制ログアウト 🍀 幸いお昼時、業務利用は少なく影響は極少 ログイン直後にエラー → データの不整合は発生せず 11
12. ② 原因 なぜ起きたのか？ 12
13. 問題の仕組み：同じ手法でSTGも本番もデプロイ の手動トリガーでデプロイ ブランチ と デプロイ先環境 をプルダウンで 選ぶだけ Branch: develop なのに environment: production が選べてしまう GitHub Actions 13
14. なぜそもそも、こんな仕組みだったのか？ 構築当初： ユーザーがいなかった 本番でミスが起きても誰にも迷惑をかけない状況 「シンプルに使い回せる」方が効率的だった 時が経ち： 有償ユーザーが増えてきた 「いつかこれ、誰かやらかすよね」という話は出ていた でも、開発の優先順位で後回しになっていた ⏰ 「重要だけど緊急じゃない」が1年以上放置された 14
15. 根本原因：仕組みが悪かった 自分で起こしておきながら… 誰がいつやっても起きてもおかしくない仕組みだった。 「お腹すいたな。早く食べたいな」という ほんのわずかな雑念が引き金になっただけ。 15
16. ③ 対策 再発防止策 16
17. 暫定対応：本番へのデプロイ制限 環境には masterブランチ以外デプロイ不可に設定 production ブランチから production を選んでも エラーで弾く まずは「物理的に誤操作できない」状態を作る develop 17
18. 恒久対応：デプロイの仕組みを抜本改修 そもそも 本番とSTGを同じ仕組みでデプロイすること自体が問題 インフラをpulumi → Terraformへ書き換えのタイミングに合わせ、 デプロイフローも1から設計しなおした 旧 新 手動でプルダウン選択 develop マージで自動デプロイ STG環境 本番環境 手動でプルダウン選択 master マージで自動デプロイ 誤操作リスク 常にある 物理的にゼロ 18
19. 「お昼休みのプルダウン誤爆」 は二度と起きなくなった 19
20. ④ 発展 怪我の功名！ 日次リリースの全自動化へ 20
21. 日次リリース自動化の背景 週次リリース → 日次リリース へ切り替えたいという要望 でも毎日手動でやるのは負荷が限界 リリースの流れ（手動時代）： ① フリーズ・PR作成 → ② 検証環境の構築 → ③ 検証の実施 → ④ PRマージ → 本番デプロイ → 本番後検証 これを毎日やるのは無理… 21
22. GitHub Actions で全工程をオーケストレーション ① リリースブランチ自動生成 → ② 検証環境自動生成 → ③ E2E自動 テスト → ④ 自動デプロイ ステップ 内容 ① develop/master差分をフリーズしPR自動作成 ② deploy/demo3 Pushを検知して環境自動構築 ③ Playwrightでブラウザ検証 → Slackへ結果通知 ④ 午前中に検証完了 → 午後に本番へ自動デプロイ 22
23. 作業負荷ゼロの 日次リリース基盤が完成！ 失敗が、最高の自動化パイプラインを 作る原動力になった。 23
24. まとめ まとめ 24
25. 「重要だけど緊急じゃない」は 放置するとある日突然インシデントになる 2. ミスをしない人間はいない 「気を付ける」より「安全な仕組み」を作ろう 3. 失敗を成長エンジンに！ トラブルが最高の自動化パイプラインを生む 1. 25