#ops (1)
計画フェーズ: TTL事前短縮
TTL（Time To Live）とは
DNSレコードが世界中のDNSサーバーにキャッシュされる秒数。
- TTL 3600秒: 1時間キャッシュ保持
- TTL 300秒: 5分キャッシュ保持
なぜ事前に下げるか
問題発生時のロールバック速度を確保するため。
旧TTL（3600秒）のままIP切替すると、問題発生→即戻しでもキャッシュ有効期間中はユーザーが新サーバーにアクセスし続ける。最大1時間のエラー継続リスク。
ベストプラクティス
- DNS切替の24〜48時間前にTTLを300秒に短縮
- 切替後、安定稼働を確認したら元のTTL値（3600以上）に戻す
TTL短縮を忘れた場合
- 最も安全: TTLを300に変更→1時間待機（旧キャッシュ完全消滅）→作業開始
- 妥協案: TTLを300に変更→すぐ作業開始（大半は5分で浸透、一部残留リスク）
- リスク高: TTL 3600のまま作業開始（ロールバック時に最大1時間の影響）
実行フェーズ: DNS切替
DNSレコードを新サーバーのIPアドレスに変更する。浸透には最大48時間かかるため、初期段階でのトラフィック不足は正常。
監視フェーズ: 切替後のダッシュボード確認
正常な状態
- 5xx: 0 / 4xx: 少数（正常範囲） / CPU: 低い（2%程度） / メモリ: 低い（24%程度） / 2xx: トラフィックに応じて増加
問題ありの兆候
| 指標 | 状態 | 対応 |
|---|---|---|
| 5xx ≥ 1 | SSR/APIに問題 | ログ確認、深刻ならロールバック |
| 4xx 急増 | ルーティング/リダイレクト設定ミス | 旧パスの404を調査 |
| CPU > 50% | SSR過負荷 | ページ最適化/スケール調整 |
| メモリ > 80% | メモリリーク等 | プロセス調査 |
| 2xx = 0 | DNS未浸透 or SSL未発行 | dig domain.com A で確認 |
監視フロー
- 切替後30分〜1時間: 継続的にダッシュボード監視
- 最初1〜2日間: TTLを300秒のまま維持（即ロールバック可能に）
- 安定確認後: TTLを3600に戻す