年末に一度は確認したいサーバー設定10項目
(何も起こらないようにするため)
「年末だから特に点検しなければならないものはあるのか?」 結論から言うと、あります。
年末だからサーバーが特別になるわけではありません。 代わりに、運用する側の状況が普段と変わるということです。
- 休暇・連休で運用スタッフが減る
- トラフィックパターンが乱れる
- 緊張感が緩む
そのため年末は、起きる確率以上に被害が大きくなりやすい時期です。 この文は「年末だから必ずやるべき」という強迫的なチェックリストではなく、 連休中に何も起こらないようにするための現実的な点検項目 です。
1. ディスク使用量とログ増加速度
年末だからログが減るわけではありません。
特に次の項目は必ず確認しておきましょう。
/var/logの使用量- アプリケーションログローテーション設定
- Docker コンテナログのサイズ(JSONログが無限増加していないか)
ディスクがいっぱいになると 予告なしに停止します。 普段は「少し耐えればいい」状況も、連休中はそのまま障害に発展しやすいです。
2. バックアップが「ある」かではなく「復旧できる」か
バックアップファイルがあることより重要なのは、
「これで本当に復旧できるか?」
年末前に最低でも一度以下を試してみましょう。
- 最新バックアップファイルの存在確認
- 圧縮ファイルが壊れていないか簡易検証
- テスト環境に直接リストアしてみる
新年最初の業務が「バックアップが壊れていた」と知るのを防ぐためです。
3. SSL/TLS証明書の有効期限
年末・年始は証明書失効事故が特に多発します。
- Let’s Encrypt の自動更新が実際に動いているか
cronやsystemd timerが無効化されていないか- 最近の更新ログにエラーがないか
「自動更新だから大丈夫」という思いが 年末の代表的な障害トリガー です。
4. ファイアウォールルールと「一時的に」開放している設定
1年間サーバーを運用しているとこうしたものが蓄積します。
- テスト用に開放しているポート
- 特定の状況で一時的に開放していたIP
- もう使っていないサービスポート
こうした一時設定は時間が経つと 存在理由を誰も覚えていないセキュリティホール になります。 年末はこれらを整理するのに最適な時期です。
5. SSHアクセス方式とキー管理
連休中に試みられる侵入は 発見が遅れやすい です。
そのため SSH 設定は特に保守的に行うのが安全です。
- パスワードログインの無効化
- 使っていない SSH キーの削除
- 退職者・外注先のキー削除
- 管理者アカウントが最小権限のみを持っているか
「結局誰も関心を持たないだろう」という楽観は セキュリティ面ではほぼ常に誤りです。
6. cron/スケジューラの静かな失敗
cron や systemd timer、ジョブスケジューラは 失敗しても気づきにくいものです。
- 最近の実行ログにエラーがないか
- 長期間失敗しているジョブがないか
- もう不要なジョブが継続して動いていないか
年末に壊れたスケジューラは 新年も同じ状態で残ります。
7. リソース使用量は「平均」ではなく「ピーク」基準で
年末トラフィックは普段より変動が大きいです。
- 特定期間だけトラフィックが急増
- ボット/クローラの異常アクセス
- 特定国の休日パターン
そのためモニタリングも 平均値ではなくピーク を一度は確認しておく必要があります。
- CPU・メモリピーク使用量
- DB接続数、キュー長
- 同時接続者数、セッション数
「普段は大丈夫」という言葉は 年末にはあまり慰めになりません。
8. アプリケーションの依存サービス状態
サーバーが健全でも、依存サービスが落ちていればサービスは同じように停止 します。
例:
- Redis / Memcached
- メッセージブローカー(Kafka, RabbitMQ, SQS 等)
- 外部 API(決済、認証、通知 等)
- ファイル/画像ストレージ
年末はこれらのサービスも 点検・デプロイ・定期作業 が多いです。 障害が起きても「ログに異常が見えない」という状況が頻繁に起こります。 依存サービスのステータスページや障害通知チャネルも併せて確認しておくと良いです。
9. エラー通知が本当に「届く」かテスト
エラー通知システムがあることと 通知が実際に届くこと は全く別問題です。
- エラーを意図的に一度発生させてみる
- メール/Slack/Webhook 通知が実際に届くか確認
- 重大度(Severity)フィルタで無視されていないか
年末障害の最大の問題はしばしばこれです。
「障害が起きたことに誰も気づかなかった」
10. 「問題が起きたらどこから見るか」を整理したドキュメント一枚
最後の項目は設定ではなく ドキュメント です。
- 主要サービス一覧
- サーバー/コンテナへの接続方法
- ログ位置(nginx, app, DB, キュー 等)
- 再起動/ロールバック方法
- 緊急対応順序
このドキュメント一枚があるかないかで 年末障害対応の難易度が ハードモード ↔ ノーマルモード に変わります。
年末サーバー点検チェックリスト
実際に隣に置いてチェックできるよう、要点だけをまとめた簡易表です。
| 項目 | チェック内容 | 確認方法例 | 推奨状態 |
|---|---|---|---|
| ディスク使用量 | ログ/データでディスク余裕を確認 | df -h, /var/log サイズ確認 |
余裕 20% 以上 |
| ログローテーション | 主要ログファイルの循環/削除 | logrotate・Dockerログ設定 |
定期的ローテーション設定 |
| バックアップ・復旧 | 最新バックアップ生成・復旧可否 | テスト環境に直接リストア | 24〜48時間以内に成功 |
| SSL証明書 | 失効日近接・自動更新動作 | certbot/更新ログ確認 | 失効まで 30 日以上余裕 |
| ファイアウォール・ポート | テスト用・一時開放ポート/例外整理 | ufw/iptables 設定確認 |
最小権限、不要ポート除去 |
| SSHアクセス | 認証方式・キー管理 | sshd_config, キー一覧確認 |
キーベースログイン、不要キー除去 |
| スケジューラ(cron 等) | 定期作業失敗可否 | cron/systemd ログ確認 | 最近実行エラーなし |
| リソースピーク | CPU/メモリ/接続ピーク | モニタリングダッシュボード, htop 等 |
ピークでも余裕確保 |
| 依存サービス | Redis/DB/外部API 等の状態・障害通知 | ステータスページ・ログ・通知チャネル確認 | 障害時即時検知可能 |
実際にこの程度をチェックしておけば、連休中は安心して休めるはずです。 …と言いたいところですが、現実は少し違います。
このチェックを終えても、多くのサーバー管理者は年末休暇に出る際に サーバーへ SSH 接続できるタブレットやノートパソコン を旅行カバンの片隅に必ず入れます。 「何かあったら…本当に何も起こらないといい」 という気持ちで。 (私も含めて 🙃)
私たちにできるのは 事故が起きる確率を最大限に減らし、 もし何かが起きても 最低限どう対処するかを知った状態で休む ことだけです。
だから今年もバッグの片隅に小さなノートパソコンを入れつつ、 「突然サーバーが壊れたらどうしよう?」よりも 「これくらいなら大丈夫だろう」という軽い気持ちで 年末を迎えてほしいと思います。

コメントはありません。