Високосная секунда: как одна лишняя секунда роняла дата-центры

MAATRIX

Раз в несколько лет координаторы точного времени решают, что в очередном полугодии в одну из минут добавится лишняя, 61-я секунда. Для человека это незаметная деталь — разве что часы на телефоне на мгновение покажут что-то странное. Для программ, которые годами исходили из того, что в минуте ровно 60 секунд, это событие может обернуться зависшими процессами и всплеском нагрузки на серверах по всему миру. Разберём, откуда берётся високосная секунда, почему она в принципе способна что-то сломать и как индустрия научилась переживать её без резких скачков часов.

Что такое високосная секунда и зачем она нужна

У человечества есть два способа мерить время. Первый — астрономическое, солнечное время: сутки определяются вращением Земли вокруг своей оси. Второй — атомное время: секунда определяется как строго фиксированное число колебаний атома цезия-133 и не зависит вообще ни от чего астрономического. Атомные часы невероятно стабильны, но у них есть неудобное свойство — они текут ровно, а вращение Земли ровным не является.

Всемирное координированное время, UTC, — компромисс между этими двумя системами. Его секунда — атомная, предельно точная. Но UTC обязан оставаться привязанным к реальному вращению Земли, чтобы полночь по UTC продолжала совпадать с полночью в Гринвиче, а не постепенно уезжала на дневное время через несколько тысяч лет. Расхождение между атомной шкалой (TAI) и астрономической компенсируют именно високосными секундами: время от времени в UTC вставляют дополнительную секунду, чтобы шкала «подождала» немного замедлившуюся Землю.

Технически это выглядит как минута с 61 секундой вместо привычных 60. Вместо перехода 23:59:59 → 00:00:00 часы на мгновение показывают 23:59:60, и только после неё наступает полночь следующих суток. Такая минута случалась не в каждом году — интервалы между добавлением секунд бывали от полугода до нескольких лет. Направление теоретически может быть и обратным — отрицательная секунда, когда одну секунду из минуты убирают, — но на практике за всю историю наблюдений такое ни разу официально не применялось: Земля пока стабильно отстаёт от атомных часов, а не опережает их.

Почему замедление Земли — не курьёз, а измеримая физика

Причина, по которой вообще приходится городить эту конструкцию, вполне реальная: вращение Земли постепенно замедляется, и главный виновник — приливное трение. Луна тянет океаны, трение воды о дно и берега забирает энергию вращения планеты, а та энергия постепенно передаётся орбитальному движению Луны. В масштабе десятилетий эффект крошечный — речь о миллисекундах на сутки, — но он накапливается, и атомные часы, которые не замедляются вместе с планетой, со временем расходятся с астрономическими сутками на заметную величину.

Важный нюанс: замедление не линейное и не идеально предсказуемое. На скорость вращения влияет не только приливное трение, но и перераспределение массы внутри планеты — таяние ледников, движение вещества в мантии и ядре, даже крупные землетрясения способны сдвинуть скорость вращения на микроскопическую долю секунды. Поэтому нельзя заранее, на годы вперёд, расписать график добавления секунд по формуле — решение каждый раз принимается по факту наблюдений, а не по календарю.

Стоит развеять частое заблуждение: високосная секунда — не то же самое, что високосный год. Високосный год (29 февраля) компенсирует то, что орбитальный период Земли вокруг Солнца не равен ровно 365 суткам, — это полностью предсказуемый календарный механизм. Високосная секунда компенсирует непредсказуемое замедление вращения Земли вокруг своей оси и объявляется заранее лишь на несколько месяцев.

Кто и как решает, когда добавлять секунду

Решение о добавлении секунды принимает международная организация, отвечающая за службу вращения Земли и системы отсчёта. Она отслеживает фактическое расхождение между UTC и астрономическим временем UT1 (шкалой, основанной на реальном угле поворота Земли) и, когда расхождение приближается к порогу около половины секунды, объявляет о добавлении секунды заранее — обычно за несколько месяцев, с окном для добавления в конце июня или конце декабря по UTC.

Именно это заблаговременное объявление — источник значительной части проблем. Административно всё просто: вышел бюллетень, дата известна. Технически же это означает, что тысячи независимых систем — операционные системы, СУБД, сетевое оборудование, встроенное ПО — должны заранее узнать об этом решении и корректно его обработать. Механизм распространения информации — файл базы часовых поясов (tzdata) и бюллетени, которые ОС и NTP-инфраструктура подтягивают через обновления. Получил сервер актуальные данные вовремя — он готов; не получил — обработает 61-секундную минуту так, как «умеет» его текущий код, а это «умеет» может оказаться некорректным.

Отдельно стоит знать: крупнейшие метрологические организации договорились, что после 2035 года практику добавления секунд прекратят — расхождение станут компенсировать значительно реже и другим способом. Но до этой даты действующий механизм остаётся прежним.

Минута из 61 секунды: почему это ломает системные допущения о времени

Здесь и кроется суть технической проблемы. Огромное количество программного обеспечения — от низкоуровневых библиотек до прикладного кода — опирается на негласное предположение: в одной минуте ровно 60 секунд, в одном часе ровно 3600 секунд, в одних сутках ровно 86400 секунд. Это предположение зашито не только в явную логику вроде if seconds == 60: minutes += 1, но и гораздо глубже — в способ, которым время представляется внутри системы.

Классический пример — временные метки Unix (Unix time): число секунд, прошедших с полуночи 1 января 1970 года по UTC. Формально стандарт POSIX требует, чтобы Unix-время игнорировало високосные секунды — то есть в сутки, когда добавляется 61-я секунда, Unix-время либо «застывает» на месте на одну секунду, либо один и тот же числовой штамп соответствует двум разным физическим моментам. Иначе говоря, монотонность времени в наивном понимании локально нарушается: секунда, наступившая физически позже предыдущей, может получить метку, которая не больше предыдущей, а равна ей.

Для кода, который просто выводит время, это не страшно. Но для кода, завязанного на арифметику времени, — секунда с неоднозначной меткой становится ловушкой:

• Циклы и таймеры, которые не завершаются. Код, ожидающий, что now() - start_time рано или поздно станет большим положительным числом, может увидеть на границе секунды нулевую или отрицательную разницу — и уйти в busy-loop, потребляя CPU без пользы.
• Нарушение упорядочивания событий. Распределённые системы, где узлы сравнивают метки для определения порядка (кто первый записал, какая версия свежее), могут получить неоднозначные или «одинаковые» метки от событий, физически произошедших в разном порядке.
• Некорректная работа планировщиков и таймаутов. Механизмы, реализованные через разницу таймстампов, а не через монотонные часы ядра, могут посчитать, что прошло больше или меньше времени, чем на самом деле, и сработать не вовремя.
• Аварийные остановки при недопустимых значениях. Некоторые низкоуровневые компоненты в отдельных реализациях попросту не ожидают значения секунды, равного 60, и обрабатывают его как ошибку данных.

Проблема не в масштабе события — сама лишняя секунда ничтожно мала. Она в том, что это исключение из правила, которое код почти никогда не тестирует: достаточно редкое, чтобы про него забыть, и достаточно системное, чтобы задеть множество независимых сервисов одновременно — все они получают эту секунду в один момент по всему миру.

Известные проблемы в индустрии: что происходило на практике

Реакция индустрии на високосные секунды — не гипотетическая, а вполне выстраданная история. За те десятилетия, что этот механизм действует, известны случаи в индустрии, когда добавление секунды приводило к заметным сбоям — вплоть до массовых зависаний серверов, аварийных перезагрузок и скачков нагрузки на процессор у облачных и веб-сервисов в момент прохождения 61-й секунды. Подробности каждого случая — предмет постмортемов конкретных компаний, и разбирать версии и даты здесь не будем, чтобы не гадать там, где не уверены в деталях.

Закономерность в этих историях примерно одна: проблема почти никогда не была в самой секунде как таковой, а в конкретной реализации — в баге таймера ядра, в неверном предположении библиотеки, в редко тестируемом пути кода. То есть не «системы времени плохо спроектированы», а «граничный случай, который проверяют раз в несколько лет, стабильно оказывается недотестированным». После заметного инцидента компоненты чинили, и следующая секунда проходила спокойнее — до тех пор, пока не всплывал следующий непроверенный угол. Отдельная категория проблем — сбой не в моменте, а в календаре: устаревшая библиотека часовых поясов может неправильно посчитать дату следующей секунды. Про то, как вообще устроена конфигурация времени на сервере и почему её стоит явно проверять после установки ОС, — отдельный разбор в статье настройка NTP и синхронизация времени сервера.

Из этой истории индустрия сделала практический вывод: раз резкий скачок в 61-ю секунду регулярно оказывается тем самым непроверенным граничным случаем, лучше вообще не давать системе увидеть этот скачок явно. Отсюда и появился подход, о котором дальше.

Leap smear: как размазывание секунды решает проблему

Идея leap smear (leap second smearing, «размазывание високосной секунды») в том, чтобы не создавать резкий скачок вида 23:59:59 → 23:59:60 → 00:00:00, а растянуть лишнюю секунду на длительный промежуток — например, на 24 часа вокруг момента коррекции — слегка замедлив ход системных часов. Каждая «обычная» секунда в окне смеара оказывается чуть-чуть длиннее настоящей физической — незаметно для приложений, потому что часы по-прежнему монотонно идут вперёд и никогда не показывают ни повторяющееся, ни несуществующее значение.

Механика по сути та же, на которой строится обычная повседневная синхронизация часов через NTP: когда локальные часы немного разошлись с эталоном, NTP-клиент (например, chrony) не переставляет время скачком, а плавно подстраивает скорость хода часов, пока расхождение не исчезнет — это называется slewing, в противовес резкому «шагу» (stepping). Leap smear — тот же принцип, применённый специально к моменту високосной секунды: система на сутки чуть замедляет каждую секунду настолько, что суммарно набегает недостающая секунда без видимого разрыва или повтора.

Именно последняя строка — главное ограничение подхода. Leap smear не стандартизирован на уровне протокола UTC. Если часть инфраструктуры синхронизируется с источником, применяющим smear, а другая — с источником, отдающим «честную» 61-ю секунду, эти группы серверов на протяжении окна smear будут показывать слегка разное время друг относительно друга (доли секунды). Для большинства приложений это несущественно, но для систем с жёсткими требованиями к синхронности между узлами — источник рассинхрона, который стоит учитывать при выборе NTP-источников.

Практический вывод — держать единообразную конфигурацию времени во всей связанной инфраструктуре: если серверы образуют кластер, стоит убедиться, что все они синхронизируются с источниками одной политики, а не смешивать их по усмотрению. Это же справедливо для репликации баз данных, где согласованность временных меток напрямую влияет на корректность — механика такой чувствительности разобрана в статье про синхронную репликацию и цену этой надёжности, а общий разбор того, как реплики обмениваются состоянием, — в материале как работает репликация и отставание реплики.

Что стоит проверить на своём сервере заранее

Полностью полагаться на то, что «всё само разрулится», не стоит — практическая подготовка сводится к нескольким пунктам:

• Актуальность tzdata и NTP-клиента. Устаревшая база часовых поясов или старая версия демона синхронизации — самый частый источник некорректной обработки коррекции. Обновление пакетов ОС перед объявленной датой снимает большую часть риска.
• Единообразие источников времени внутри кластера. Если несколько серверов образуют логическую группу (реплики БД, узлы очереди сообщений, шардированное хранилище), стоит свести их на общий пул NTP-источников с одинаковой политикой, а не оставлять каждому источники по умолчанию.
• Аудит кода, который меряет длительность через разницу временных меток календарного времени (time.time(), datetime.now()), вместо монотонных часов там, где важна именно продолжительность. Такой код уязвим не только к секундной коррекции, но и к любому ручному переводу часов — та же категория проблем, что разбирается в статье про частые ошибки cron-задач на сервере.
• Мониторинг в день коррекции и запасной план перезапуска. Разумно на сутки усилить наблюдение за нагрузкой CPU и таймаутами — недотестированный участок кода обычно проявляет себя именно в узком окне вокруг коррекции. Для критичных сервисов с уязвимыми таймерами полезно иметь готовый способ быстрого перезапуска.

Ничего из этого не требует экзотических настроек — по сути, это обычная гигиена конфигурации времени на сервере, которая просто становится особенно важной в узком временном окне.

Частые вопросы