Синхронизация времени и дрейф

1) Почему время — архитектурный компонент

• ломать Kerberos/OAuth/JWT (поля `iat/nbf/exp`);
• искажать метрики/трейсы и алерты;
• ронять брокеры/клиентов (таймауты, ретраи, экспоненциальный backoff);
• нарушать порядок и идемпотентность в распределенных сценариях.

• Offset (смещение) — разница локального времени от эталона.
• Skew (разъезд) — разность оффсетов между узлами.
• Drift (дрейф) — скорость ухода часов (ppm) при отсутствии коррекции.
• Jitter — вариативность задержек/измерений.

2) Источники и протоколы времени

2.1 NTP (Network Time Protocol)

Страты (Stratum 1 — напрямую от GNSS/радио, Stratum 2 — от Stratum 1, и т.д.).

• slew (плавная подстройка частоты, безопасно для приложений);
• step (скачок времени; нежелателен на проде).
• Реализации: chrony, ntpd, systemd-timesyncd. Для серверов — предпочтительно chrony.

2.2 NTS (NTP over TLS)

Аутентифицированная синхронизация (защита от MITM и подмены времени).
Рекомендуется для внешних серверов времени.

2.3 PTP / IEEE 1588

Аппаратные метки времени (hardware timestamping) в NIC/ToR, милли- и микросекундная точность.
Режимы: boundary/transparent clock, профили телеком/энтерпрайз.
Использовать при жестких SLO на p99-порядок, HFT/телеком/индустрия.

2.4 GNSS (GPS/ГЛОНАСС) и PPS

Локальные приемники дают PPS (pulse-per-second) эталон для Stratum 1.
Важно учитывать спуфинг/глушение — ставить антенны и мониторить целостность.

2.5 Облака

Облачные источники (внутренние stratum-пулы) уменьшают оффсет и джиттер внутри VPC.
Для гибридных сред — комбинируйте локальные и облачные референсы.

3) Время в ОС и железе

TSC/HPET/RTC: современные CPU держат TSC как быстрый монотонный счетчик; закрепляйте частоту (invariant TSC).
Виртуализация/контейнеры: дрейф и «прыжки» чаще. На гипервизоре — строгий тайм-сервис; в гостях — chrony.
Энергосбережение может мешать монотонии таймеров — проверяйте BIOS/UEFI опции.

4) Монотонные и «стенные» часы

Wall-clock (реальное время, TZ/UTC) — для логов, меток событий, людей.
Monotonic clock — для измерения интервалов/таймаутов.

• Linux: `CLOCK_MONOTONIC`.
• C++: `std::chrono::steady_clock`.
• Go: встроенные монотонные части `time.Time` в интервалах.
• Java: `System.nanoTime()` для длительностей, не для календаря.

Правило: дедлайны и ретраи — на монотонных часах; сериализация/логирование — на UTC.

5) Leap second/«leap smear» и календарные ловушки

Leap second может вызвать «00:59:60» или повтор секунды → петли в таймерах/метриках.

• Smear (плавная «размазка» секунды за N часов).
• Шаг (нежелателен).
• Никогда не полагайтесь на локальные TZ/летнее время для логики; храните UTC, показывайте в TZ пользователя.
• Обновляйте TZDB (база часовых поясов) — политические изменения случаются.

6) Согласование порядка без доверия к «стене»

Lamport clocks и Vector clocks — причинно-следственные отношения без физических часов.
Hybrid Logical Clocks (HLC) — объединяют физическое время и счетчик, устойчивы к небольшому skew.
TrueTime-подобные модели — возвращают интервал `[earliest, latest]` и требуют commit-wait для сериализации.

7) Влияние времени на протоколы и системы

Безопасность: Kerberos допускает небольшой skew (обычно ±5 минут), TLS/сертификаты чувствительны к `notBefore/notAfter`, JWT к `exp/nbf/iat`.
Брокеры/очереди: дедлайны задач/visibility timeout зависят от правильного времени.
СУБД/кластеры: конфликт версий по `updated_at`/ts — вводите HLC/версии, а не сравнивайте «сырые» wall-timestamps.
Стриминг: различайте event time и processing time; настраивайте watermarks и lateness.
Крон/планировщики: дрейф ведет к «залипанию»/двойным запускам. Используйте монотонные интервалы и дедуп ключи.

8) Наблюдаемость и SLO времени

8.1 Метрики

`time.offset_ms` (оффсет к референсу), `time.jitter_ms`, `stratum`, `root_delay`, `root_dispersion`.
Для PTP: `path_delay`, `grandmaster_offset`, `gm_identity`, `clock_class`.
Алерты: оффсет > порога (например, 100–500 мс), потеря источника, step-коррекции.

8.2 Диагностика

`chronyc tracking/sources/sourcestats`

`ntpq -p`, `ntpstat`

PTP: `pmc`, вендорные утилиты NIC/ToR.

8.3 SLO/ошибочный бюджет

Пример SLO: «median offset ≤ 1 ms, p99 offset ≤ 25 ms, no step на прод-узлах; PTP grandmaster failover ≤ 2 s».

9) Практики конфигурации (Linux/containers/K8s)

9.1 chrony (рекомендуется)

pool time. example. org iburst maxsamples 9 nts makestep 0. 5 1 # one step at big error at start rtcsync # synchronize hardware clock leapsectz right/UTC # leap seconds from tzdata driftfile/var/lib/chrony/drift

• `maxsources`, `minsamples/maxsamples`, `maxslewrate`.
• Для изолированных DC — локальный референс + GPS/PPS.

9.2 Контейнеры и узлы

Синхронизацию делайте на хосте; контейнеры используют ядро.
В K8s — DaemonSet с chrony или node-level тайм-агент; запретите привнесение времени приложениями.

9.3 PTP стек

NIC с аппаратным timestamping, PTP-демон, boundary clocks на ToR.
Разнесение доменов PTP (профили), защита от «плохих» grandmaster.

10) Безопасность времени

NTS/аутентифицированный NTP, фильтры и rate-limit (NTP-усиление — вектор DDoS).
PTP security: изоляция L2, ACL на мультикаст, мониторинг GM spoofing.
GNSS: антенны с хорошим обзором, детект спуфинга/джамминга, fallback-источники.

11) Инженерные паттерны и код

11.1 Дедлайны/таймауты

Храните дедлайны как «монотонный старт + дельта», а не абсолютный wall-timestamp.
Всегда добавляйте запас на skew (например, 2× ожидаемого p99-skew к TTL токена).

11.2 Сравнение версий

• версионирование/ETag;
• HLC/seq;
• оптимистические блокировки.

11.3 Логи и трассировки

Всегда UTC; включайте поле `time_offset_ms` узла в логи агента.
Проклеивайте event-time в событиях трассировки.

11.4 Обработка leap second

Выберите политику (smear/step) единообразно по всем узлам.
Тестируйте: метрики не должны «ломаться» на повторной секунде.

12) Влияние на домены

Auth: токены — учитывайте «clock skew allowance» (например, ±2–5 минут).
Payments/отрезки времени: округляйте интервалы, а не абсолютное время.
Брокеры: расписания ретраев — на монотонных часах.
БД/TTL: TTL в Redis/DB — опирается на локальные часы: закладывайте запас.
Аналитика: агрегации по времени — используйте единый UTC и синхронизацию ingestion.

13) Тест-плейбуки (Game Days)

Drift injection: искусственно увести часы на +/−Δ; проверить auth, брокеры, SLO.
NTP outage: отключить источники, проследить drift и автопереключение.
Leap second/smear: имитация наступления leap, оценка графиков/таймеров.
PTP GM failover: проверить время переключения и оффсет после.
VM suspend/resume: убедиться в отсутствии «скачков» и step на гостях.

14) Анти-паттерны

Сравнивать события разных узлов по wall-времени без HLC/seq.
Класть «строковые локали» времени (с TZ) в БД вместо UTC.
Разрешать приложениям делать `date -s`/`timedatectl set-time`.
Включать step-коррекции на проде без планирования.
Игнорировать TZDB-обновления и правила перехода на летнее время.
Использовать wall-clock для backoff/таймаутов/токен-TTL без запаса на skew.
Пытаться «лечить порядок» физическим временем вместо логических часов.

15) Чек-лист внедрения

• Единая политика: NTP (с NTS) или PTP; список доверенных источников.
• Узлы настроены на slew, step только на старте.
• Единая политика leap second (smear/step) по всем кластерам.
• Мониторинг оффсета, джиттера, stratum/PTP показателей; алерты.
• Приложения используют монотонные часы для интервалов/дедлайнов.
• Для порядка/конфликтов — HLC/версии, не wall-timestamps.
• Запасы на skew в TTL токенов, сертификатах, расписаниях.
• K8s/VM: синхронизация на хостах, контейнеры без прав менять время.
• Документация и runbooks по отказам времени, game days в CI/CD календаре.
• Регулярные обновления TZDB, проверка поведения при DST/leap событиях.

16) FAQ

Q: Когда нужен PTP вместо NTP?
A: Когда SLO требует микросекунд–десятков микросекунд (телеком/HFT/индустрия) и есть поддержка аппаратных меток в сети/картах.

Q: Сколько закладывать на clock skew?
A: Для типичного NTP в DC — десятки–сотни мс (p99); закладывайте 2× запаса. С PTP — единицы–десятки мкс.

Q: Как пережить leap second?
A: Использовать smear и одинаковую политику везде; протестировать графики/агрегаторы и таймеры.

Q: Можно ли полагаться на wall-clock для дедлайнов?
A: Нет. Только монотонные часы + запас на skew.

Q: Как хранить «время» в БД?
A: В UTC (`timestamptz`), плюс версии/HLC для разрешения конфликтов; не храните локальные зоны в данных.

17) Итоги

Надежное время — это протокол + политика + дисциплина в коде. Синхронизируйте узлы (NTP/NTS или PTP), используйте moнотонные часы для интервалов, UTC для данных, HLC/версии для порядка, закладывайте запасы на skew, мониторьте оффсет и регулярно проводите game days. Так вы избежите «мистических» багов аутентификации, расхождений в событиях и нестабильных SLO.