サーバーの時刻ずれが起こす障害｜NTP同期の確認と直し方
ログを見比べていたら、サーバーAとサーバーBで、同じ処理の時刻が数分ずれている。 あるいは、昨日まで普通だったのに、急に「証明書が有効ではありません」と言われる。バッチが動くはずのない時間に走っていた——。
そんなとき、アプリのバグやネットワークを先に疑ってしまいがちですが、犯人がサーバーの時刻ずれだった、というのは現場でよくある話です。時刻はふだん意識しないぶん、いざズレると原因にたどり着くまで遠回りしやすい。ここは、経験のある人でも見落としやすいところです。
この記事では、時刻ずれが引き起こす障害の見つけ方と、NTP同期の確認・直し方を、一人運用の目線で一緒に整理します。まずは今の状態を1コマンドで確かめるところから。全部を一度に直さなくて大丈夫です。
用語：NTP（Network Time Protocol）は、サーバーの時計を正確な基準時刻に自動で合わせ続ける仕組みのことです。ふだんは裏で静かに動いていて、これが止まると時計が少しずつずれていきます。
結論：やることは3つです。①今ずれているか・同期しているかを確認する（timedatectlとdateで状態を見る）、②同期が止まっていたら、時刻合わせのサービス（chrony など）を動かして直す、③二度と静かにずれないよう、同期状態を監視に入れる。この順で、まず「今どうなっているか」を1コマンドで確かめるところから始めます。
コマンドやサービス名は、OSやバージョンで少しずつ違います（後述します）。この記事の流れを出発点に、自分の環境に読み替えて進めてください。
なぜ時刻ずれは「気づきにくい障害」なのか
時刻が少しずれても、サーバーはエラーを出さずに動き続けます。だから、ずれ自体には気づけません。困るのは、その時刻を別の何かが信用しているときです。
- ログの時刻が信用できなくなる：複数サーバーでログを突き合わせるとき、時刻がずれていると出来事の前後関係が狂います。「原因→結果」の順番が逆に見えて、障害調査が一気に難しくなります。
- 証明書やTLSでエラーが出る：SSL/TLS証明書には「いつからいつまで有効」という期間があります。サーバーの時計が大きくずれると、まだ有効な証明書を「有効期限外」と誤判定して、通信が急につながらなくなることがあります。
- バッチ・cronが変な時間に動く／動かない：スケジュール実行は時計を頼りにしています。時刻がずれれば、意図しない時間に走ったり、想定の時間に走らなかったりします。
- 認証・トークンがはじかれる：ワンタイムパスワード（時刻ベースの2段階認証）や、APIの署名・トークンの有効期限（時刻で判定するもの）は、時計がずれるとサーバー間で食い違い、正しいのに「無効」と扱われることがあります。
つまり時刻ずれは、それ単体ではなく、あちこちの別々の不具合として現れる。だから原因が見えにくいのです。逆に言えば、原因不明のトラブルに当たったとき「時刻は合っているか？」を早めに1回確かめる癖があるだけで、遠回りをかなり減らせます。
手順1：今ずれているか・同期しているかを確認する
まず、犯人かどうかを確かめます。ここは1〜2コマンドで済みます。
（1）今の時刻と同期状態をまとめて見る
多くのLinux（systemd系）では、次のコマンドで時刻と同期状態を一度に確認できます。
timedatectl出力の中の次の2行に注目します。
System clock synchronized: yes… 同期できていればyes。noならずれている可能性が高いサインです。NTP service: active… 時刻合わせのサービスが動いていればactive。inactiveなら同期が止まっています。
（2）基準の時刻とどれくらいずれているか見る
date で今のサーバー時刻を表示し、手元のスマホや、社内で信頼できる別サーバーと見比べます。数秒のずれは許容範囲のことが多いですが、分〜時間の単位でずれていたら要対応です。
date（3）時刻合わせサービスの詳しい状態を見る（使っているものだけ）
環境で使われている仕組みに合わせて、どちらかを実行します（両方は入っていないのが普通です）。
- chrony を使っている場合：
chronyc tracking（Last offsetが実際のずれ幅、Leap statusがNormalなら正常）／どこに同期しているかはchronyc sources - systemd-timesyncd を使っている場合：
timedatectl show-timesync --all（同期先や状態が見えます）
メモ：昔からあるntpd（ntpq -p で見るタイプ）で運用している環境もまだあります。その場合はntpq -pで同期先と offset を確認します。ただし新しめのOSでは、より軽量な chrony や systemd-timesyncd が標準になっているので、まずは自分の環境で「どれが動いているか」を確かめるのが先です。
手順2：同期が止まっていたら直す
同期が止まっていた（no / inactive だった）ときの直し方です。いきなり手で時刻を書き換えず、まず自動同期を復活させるのが安全です。
（1）自動同期をオンにする
sudo timedatectl set-ntp trueこれで時刻合わせサービスが起動し、しばらくすると自動で合っていきます。数十秒〜数分待って、もう一度 timedatectl を見て synchronized: yes になるか確認します。
（2）サービス自体が入っていない・動かないとき
set-ntp true にしても同期しない場合、時刻合わせサービス（chrony など）が入っていない、または止まっていることがあります。多くの環境では chrony を入れて動かすのが手軽です。
- インストール：
sudo apt install chrony（Debian/Ubuntu系）またはsudo dnf install chrony（RHEL系） - 起動と自動起動：
sudo systemctl enable --now chronyd - 確認：
chronyc tracking
（3）それでも同期しない・時刻取得ができないとき
NTPは通信で基準時刻を取りに行きます。ここがふさがれていると、いつまでも合いません。次を疑います。
- 外向きのNTP通信がブロックされていないか：NTPは UDP の 123 番ポートを使います。ファイアウォールや社内ネットワークで外向きの UDP/123 が閉じられていると同期できません。閉じている環境では、社内に置いた基準サーバー（内部NTP）を同期先に指定します。
- 同期先が生きているか：
chronyc sources（またはtimedatectl show-timesync）で、参照先にちゃんとつながっているかを見ます。
（4）ずれが大きくて、すぐ合わせたいとき
自動同期は、急に時計を飛ばさず少しずつ寄せる（スルー）ことがあり、大きなずれだと戻るのに時間がかかります。すぐ合わせたいときは、chrony なら次で一気に合わせられます。
sudo chronyc makestep注意：稼働中のデータベースやクラスタで、時刻を大きく・急に飛ばすと、内部の整合性やレプリケーションに影響が出ることがあります。本番でのステップ調整は、影響範囲を確認できるとき（できれば計画停止やメンテナンス時間帯）に行い、心配なときは一次情報とベンダー資料で挙動を確認してから実施してください。ふだんは自動同期に任せ、ずれを未然に防ぐのがいちばん安全です。
手順3：二度と静かにずれないように監視へ入れる
いちど直しても、また同期が止まればじわじわずれます。時刻ずれは「静かに進む」障害なので、気づける仕組みを1つ入れておくと安心です。
- 監視に「同期状態」を加える：
timedatectlのSystem clock synchronizedがnoになったら気づけるようにする、あるいは chrony の offset が一定を超えたら通知する。 - 監視サーバー自身の時刻も確認する：監視する側がずれていると、そもそも判定がおかしくなります。ここは見落としがちです。
- サーバー構成の資料に「同期先NTP」を1行残す：内部NTPを使っているなら、そのアドレスをドキュメントに書いておくと、次に触る人（未来の自分）が迷いません。
一度に全部やらなくて大丈夫です。まずは「同期が切れたら気づける」1点だけでも入れておけば、静かなずれの再発をかなり防げます。
そのまま使えるチェックリスト
原因不明のトラブルや、時刻がからむ不具合に当たったときに、上から順に確認してください。
-
timedatectlでSystem clock synchronized: yesになっているか -
timedatectlでNTP service: activeになっているか -
dateの時刻が、信頼できる時計（スマホ・別サーバー）と大きくずれていないか - 複数台あるなら、サーバー間で時刻がそろっているか（ログの突き合わせ前に確認）
- chrony / timesyncd / ntpd のうち、どれで時刻を合わせているか把握しているか
- 同期が止まっていたら
set-ntp true、それでもダメなら chrony の導入・起動を試したか - 外向き UDP/123、または内部NTPへの通信が通っているか
- 「同期が切れたら気づける」監視を1つ入れたか
- 監視サーバー自身の時刻も合っているか確認したか
- 構成資料に、同期先NTPを1行残したか
全部に○が付かなくても大丈夫です。まずは timedatectl を1回打って、今の状態を知るところからで十分です。それだけで、次に「原因が見えない不具合」に出会ったとき、時刻という切り口をひとつ多く持てます。
よければ、こちらも
時刻ずれは、ログ調査・バッチ・証明書といった別の作業とつながっています。前後の段取りもあわせて1枚にしておくと、いざという時に落ち着けます。
- cron・バッチの失敗を検知する｜黙って止まる処理に気づく仕組み：時刻がからむバッチが、意図せず動かない・変な時間に動くのを見つける入口です。
- 500エラーが出たら最初に見る5つのログ｜場所と確認の順番：時刻がそろっていれば、複数ログの突き合わせがぐっと楽になります。
- SSL証明書の期限切れを監視する｜切れる前に気づく仕組み：時刻ずれで急に出る証明書エラーと、期限切れそのものを切り分けるのに。
時刻ずれは、原因が見えにくいぶん、当たりをつけられると調査がぐっと楽になるテーマです。犯人が時刻だとわかった瞬間、遠回りしていたトラブルが一気にほどけることも珍しくありません。 今日はまず timedatectl を1回打って、今の同期状態を知るだけで十分です。その小さな確認の習慣が、「原因の見えない不具合」に強い運用へと、少しずつ近づけてくれます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。