はじめに
これは自分が実際にやらかした話です。
障害は復旧できました。でも「なぜ起きたか」は最後まで分かりませんでした。
理由は単純で、ログが無かったからです。
何が起きたか（実体験）
ある日、サービスが突然落ちました。
- ユーザーから「繋がらない」と連絡
- サーバーは生きているがアプリが死んでいる
- 再起動したら復旧した
しかし…
- アプリのログが無い
- ミドルウェアのログが無い
- OSログはローテーションで消えていた
つまり、何が起きたのか誰にも分からない状態でした。
その時の気持ち
復旧はできた。
でも「原因が不明」という状態はずっと不安が残ります。
- また起きたらどうする？
- 次はもっと大きな障害になるのでは？
- 誰かに説明できない
この状態が一番つらかったです。
なぜログが重要か
| 項目 | ログあり | ログなし |
|---|---|---|
| 原因特定 | 可能 | 不可能 |
| 再発防止 | 可能 | ほぼ無理 |
| 説明責任 | 果たせる | 果たせない |
ログは「保険」ではなく「証拠」でした。
学んだ教訓
1. 障害は必ず起きる前提で設計する
障害は例外ではなく、前提条件です。
「起きた後どう調べるか」を最初から設計すべきでした。
2. ログは必ず集約する
各サーバーに散らばるログは実質見れません。
ELK, Loki, Cloud Logging などへの集約が必須です。
3. 保存期間を決める
最低30日、可能なら90日以上。
「必要になった時にはもう無い」が一番多い。
4. ログ出力はレビュー対象にする
機能だけでなく「ログが十分か」もレビューする。
まとめ
障害対応で一番怖いのは「原因不明で終わること」です。
その状態を防ぐ唯一の手段がログでした。
ログは取ろう。必ず。最初から。