![](https://habrastorage.org/webt/fu/ys/bj/fuysbjufw1__edv2c1ipns37_yw.jpeg)
Понятие дополнительной (високосной) секунды (leap second) было введено в 1972 году International Earth Rotation and Reference Systems Service (IERS) для периодического обновления Coordinated Universal Time (UTC) из-за неточности наблюдаемого солнечного времени (UT1) и долгосрочного замедления вращения Земли. Эта периодическая поправка в основном помогает учёным и астрономам, поскольку позволяет им наблюдать за небесными телами, для большинства задач используя UTC. Если бы коррекция UTC отсутствовала, то необходимо было бы внести изменения в старое оборудование и ПО, синхронизируемое для астрономических наблюдений с UTC.
На сегодняшний день с момента введения високосной секунды UTC обновляли 27 раз.
Возможно, високосная секунда была приемлемым решением в 1972 году, когда она удовлетворяла и научное сообщество, и отрасль телекоммуникаций, однако сегодня UTC одинаково мешает и цифровым приложениям, и учёным, которые часто используют вместо него TAI или UT1.
Наша компания Meta* поддерживает стремление отрасли к отказу от дальнейшего использования високосных секунд и желание остановиться на текущем уровне (27). Добавление новых високосных секунд — это рискованная практика, от которой вреда больше, чем пользы, и мы считаем, что настало время внедрять новые технологии, которые её заменят.
![](https://habrastorage.org/webt/td/ly/03/tdly03dxwuo1hrl4h76aqmehcjw.jpeg)
Снежный перевал
Одним из важных факторов, влияющих на неравномерность вращения Земли, является постоянное таяние и затвердевание ледников на вершинах самых высоких гор мира. Это явление можно легко визуализировать, представив вращающуюся фигуристку, поддерживающую свою угловую скорость руками и ладонями. Когда она раздвигает руки, угловая скорость уменьшается, сохраняя импульс фигуристки. Когда она прижимает руки к телу, угловая скорость увеличивается.
![](https://habrastorage.org/webt/ea/rz/me/earzmejnw7spyah_7fjm-em2hmo.gif)
До текущего момента добавлялись только положительные високосные секунды. Поначалу для этого просто прибавляли ещё одну секунду, что приводило к необычной временной метке:
23:59:59 -> 23:59:60 -> 00:00:00
В лучшем случае, такой скачок времени приводил к сбою программ или даже повреждению данных из-за странных временных меток в хранилище данных.
Поскольку паттерн вращения Земли меняется, с большой вероятностью в будущем мы получим отрицательную високосную секунду. Временная метка будет выглядеть так:
23:59:58 -> 00:00:00
Влияние отрицательной високосной секунды в больших масштабах никогда не тестировалось; оно может оказать разрушительный эффект на ПО, зависящее от таймеров или планировщиков.
Как бы то ни было, каждая високосная секунда представляет собой серьёзный источник проблем для людей, обслуживающих аппаратные инфраструктуры.
Размазывание
В последнее время стандартной практикой стало «размазывание» високосной секунды простым замедлением или ускорением часов. Универсальный способ реализации такого способа отсутствует; Meta* размазывает високосную секунду на 17 часов, начиная с 00:00:00 UTC, на основании содержимого пакета данных часовых поясов (tzdata).
![](https://habrastorage.org/webt/fx/nb/yz/fxnbyzqxjblwc0cbmiazte3ayda.jpeg)
Размазывание високосной секунды в Meta*.
Давайте разберём это чуть подробнее.
Мы выбрали интервал в 17 часов в первую очередь потому, что размазывание происходит в Stratum 2, где сотни NTP-серверов выполняют размазывание одновременно. Чтобы разница между ними была допустимой, шаг должен быть минимальным. Если шаг размазывания слишком велик, NTP-клиенты могут посчитать, что некоторые устройства неисправны и исключить их из кворума, что может привести к перебоям в работе.
Момент начала в 00:00:00 UTC тоже не стандартизирован и существует множество возможных вариантов. Например, некоторые компании начинают размазывание в 12:00:00 UTC днём ранее и растягивают его на 24 часа; некоторые начинают за два часа до события, другие начинают прямо в его момент.
Кроме того, существует множество различных алгоритмов размазывания. Есть коррекция високосной секунды ядра, линейное размазывание (когда применяются равные шаги), косинусоидальное и квадратичное (которое использует Meta*). Алгоритмы основаны на разных математических моделях и создают разные графики смещений:
![](https://habrastorage.org/webt/uk/em/yl/ukemyl8o0cv1gvtqtfg5j95g8gq.jpeg)
Размазывание високосной секунды ядра при помощи NTPD
Источник показателя перехода для спутниковых систем навигации (т. е. GPS, ГЛОНАСС, Галилео и Бэйдоу) различается. В некоторых случаях он транслируется спутниками за несколько часов до события. В других случаях время распространяется в UTC с уже добавленной високосной секундой. В разных системах навигации значение високосной секунды различается в зависимости от времени запуска системы.
![](https://habrastorage.org/webt/ow/ie/uv/owieuvtxqy6wr95gtu1c5mfxfzu.jpeg)
Разница значений високосной секунды между разными спутниковыми системами навигации.
Для всего этого требуется нетривиальная логика преобразований внутри источников времени, в том числе и нашего собственного Time Appliance. Утеря сигнала спутниковой системы в такое важное время может привести к утере показателя перехода и конфликту, что может вызывать перебои в работе.
Также событие перехода распространяется за месяцы до события в пакете tzdata, а для фанатов ntpd — в файле високосной секунды, распространяемом через веб-сайт Internet Engineering Taskforce (IETF). Отсутствие свежей копии файла может привести к пропуску високосной секунды и тоже вызвать перебои в работе.
Как уже говорилось, размазывание — очень важный момент. Если в этом интервале NTP-сервер перезагрузится, то с большой вероятностью на нём будет «старое» или «новое» время, которое распространится на клиентов и приведёт к перебоям в работе.
Из-за такой неопределённости публичные NTP-пулы не выполняют размазывание, иногда для решения этой проблемы передавая клиентам показатель перехода. SNTP-обычно пошагово изменяют значения часов и имеют дело с описанными выше последствиями. Более умные клиенты могут выбрать стандартную стратегию для локального размазывания перехода. В конечном итоге это означает, что крупные игроки наподобие Meta*, выполняющие размазывание в публичных сервисах, не могут присоединиться к публичным пулам.
И даже после перехода ситуация остаётся рискованной. ПО NTP должно постоянно применять смещение относительно используемого им источника времени (спутниковой системы навигации, TAI или атомных часов), а ПО PTP должно распространять в оповещениях так называемый флаг смещения UTC.
Отрицательное влияние високосных секунд
Високосная секунда и создаваемое ею смещение вызывает проблемы во всей отрасли. Один из простейших способов вызвать перебой в работе — внедрить допущение о том, что время всегда движется вперёд. Допустим, у нас есть такой код:
start := time.Now()
// выполняем какие-то действия
spent := time.Now().Sub(start)
В некоторых случаях использования
spent
мы можем оказаться в ситуации, когда во время события применения високосной секунды значение должно быть отрицательным. Такие допущения приводили ко множеству перебоев в работе, и они описаны во многих статьях.В 2012 году у сайта Reddit происходили серьёзные перебои в работе из-за високосной секунды; сайт был недоступен 30-40 минут. Это произошло, когда смена времени запутала таймер высокого разрешения (hrtimer), вызвав гиперактивность на серверах, приведшую к блокировке ЦП машин.
В 2017 году Cloudflare опубликовала очень подробную статью о влиянии високосной секунды на публичный DNS компании. Первопричиной бага, повлиявшего на её DNS-сервис, стало допущение о том, что время не может двигаться вспять. Код брал значения времени из апстрима и передавал их функции rand.Int63n() языка Go. Функция rand.Int63n() справедливо запаниковала, поскольку аргумент был отрицательным, что привело к отказу DNS-сервера.
Отказ от високосной секунды
Процесс применения високосных секунд вызывал множество проблем в нашей отрасли и продолжает представлять множество угроз. Вся отрасль в целом сталкивается с проблемами, когда дело касается високосной секунды. А поскольку это такое редкое событие, оно каждый раз разрушительным образом влияет на общество. Требования к точности таймеров становятся всё выше во всех отраслях, и високосная секунда вызывает больше проблем, чем создаёт пользы, приводя к беспорядку и перебоям в работе.
Мы, инженеры Meta*, поддерживаем стремление сообщества к отказу от дальнейшего использования високосных секунд и желание остановиться на текущем уровне (27), которого, как мы считаем, хватит на следующее тысячелетие.
* — признана экстремистской организацией, ее деятельность в России запрещена.