新生活の「要件」を盛りすぎて リリース1ヶ月でシステムダウンした件

Transcript

1. 2026/2/6 【障害報告】 新生活の「要件」を盛りすぎて リリース1ヶ月でシステムダウンした件 u-Hoshi(ゆーほし)
2. 障害内容：リソース枯渇によるシステムダウン 症状：39度の発熱 影響範囲：業務・生活パフォーマンス低下 原因：要件定義の盛り込みすぎ 概要
3. 　・ 「まだいける」と言い続けている人 　・最初から全部入り設計をする人 　・疲れているのに仕様を下げない人 共有対象者
4. 1.システム紹介 2.タイムライン 3.3つの原因分析 4.教訓 5.再発防止策 6.まとめ アジェンダ
5. システム紹介
6. タイムライン 8月 9月 10月前半 11月 10月後半 大型リリース 高負荷状態 障害発生 暫定復旧 完全復旧 新環境(同棲) へ移行完了 外部リクエスト急増 （合宿・イベント・ 飲み会） 警告ログ（ダルい） を無視して運用継続 昼12時ダウン レイテンシ増大 （微熱・咳） デグレ解消
7. 1.システム紹介 2.タイムライン 3.3つの原因分析 4.教訓 5.再発防止策 6.まとめ アジェンダ
8. 工数見積もりの甘さ 原因① 計画 実家と変わらない生活レベルを維持 非同期処理で終わる見込み
9. 工数見積もりの甘さ 原因① 計画 実績 実家と変わらない生活レベルを維持 非同期処理で終わる想定 同期処理の連続 献立を考える→ 材料調達→ 料理→ 皿洗い 待ち時間の発生 皿を洗わないと料理が作れない 洗濯が終わるまで外出不可
10. ▪ 高すぎる目標を「勝手」に設定 オーバースペックな要件定義 原因② 「丁寧な暮らし」という謎の仕様書を作成 非機能要件が異常に高い 根拠はプライド
11. ▪ 要件 オーバースペックな要件定義 原因② 「毎日自炊」 → 誰にも依頼されていない必須要件 「完璧な家事」 → 非機能要件を過剰に設定 「業務外のタスク量を維持」 → 既存ワークロードを削減しない
12. アラート無視と誤ったスケーリング 原因③ アラートのミュート 「楽しいから大丈夫」と疲労のアラートを無視 誤ったスケーリング戦略 回復ではなく稼働時間でスケール 技術的負債の放置 回復コストを未払いのまま稼働継続
13. その結果... 甘い見積もり 盛りすぎな要件 アラート無視 　→エラーバジェットが0に
14. 1.システム紹介 2.タイムライン 3.3つの原因分析 4.教訓 5.再発防止策 6.まとめ アジェンダ
15. 「運用体制に見合わない要件は破綻する」 MVPフェーズの運用に エンタープライズ級の品質（＝ 実家レベル）を求めてはいけない 「バッファはコストではなく可用性」 予備リソースゼロ運用は突発イベントで即障害化する 教訓
16. 要件定義の見直し 運用可能なSLOへ再設定 非コア機能の外部化 内製範囲を限定し負荷を削減 可観測性の導入 主観ではなくメトリクスを評価 再発防止策
17. 高すぎる目標より 落ちない運用が正義 まとめ
18. 2026/2/6 【障害報告】 新生活の「要件」を盛りすぎて リリース1ヶ月でシステムダウンした件 u-Hoshi(ゆーほし)