Лишняя секунда, к которой компьютеры никогда не были готовы
Атомные часы, основа современного хронометража, тикают с неизменной точностью. Однако вращение Земли далеко от постоянства: оно непредсказуемо замедляется и ускоряется. Чтобы устранить это несоответствие, в Coordinated Universal Time (UTC) исторически добавлялись високосные секунды (leap seconds), удерживающие время в пределах 0,9 секунды от небесного ритма планеты.
С момента их введения в 1972 году было добавлено 27 положительных високосных секунд. В эти редкие моменты часы переходят с 23:59:59 на беспрецедентные 23:59:60, прежде чем наступит полночь. Эта дополнительная секунда создает уникальную проблему для компьютерных систем.
Unix time, фундаментальная мера времени, исходит из того, что в каждом дне ровно 86 400 секунд, и не имеет встроенного представления для 23:59:60. Операционные системы, такие как Linux, традиционно решают эту проблему путем повторения секунды, фактически возвращая часы назад, чтобы проиграть 23:59:59 дважды.
Эта «немонотонная» корректировка времени, при которой часы на мгновение кажутся идущими назад, нарушает ключевое допущение во множестве программных приложений. Подобные сбои неоднократно приводили к критическим отказам, включая печально известный инцидент с Reddit в 2012 году, что подчеркивает хрупкость систем, построенных на секунде, к которой компьютеры никогда не были приспособлены.
Как одна повторенная секунда поставила Reddit на колени
Яркий пример такого каскадного сбоя произошел 30 июня 2012 года. В тот день вставка високосной секунды вызвала критическую ошибку в ядре Linux. Вместо корректной настройки код hrtimer в ядре, взаимодействуя с таймерами futex, заставил процессы постоянно и мгновенно просыпаться. Это привело к загрузке CPU до 100%, фактически вызвав взаимную блокировку систем.
Reddit, крупная онлайн-платформа, приняла на себя основной удар этой тонкой корректировки времени. Сервисы были недоступны примерно 30–40 минут, что продемонстрировало, как одна повторенная секунда может распространиться по производственной инфраструктуре и вывести из строя широко используемое приложение.
Этот и другие подобные инциденты преподали фундаментальный инженерный урок: wall-clock time не всегда монотонно. Оно может прыгать вперед, отступать назад или повторяться, опровергая неявное допущение во многих программах о том, что время всегда движется линейно.
Для создания надежных систем разработчики должны проектировать логику измерения прошедшего времени и упорядочивания событий так, чтобы она не зависела слепо от time.Now(). Вместо этого следует учитывать возможные разрывы. Это включает использование monotonic clocks для измерения длительности и тщательное управление последовательностью событий там, где время может казаться идущим назад.
Паника из-за отрицательного времени в Cloudflare и обходное решение со «смазыванием» (smear)
Другая високосная секунда, в первый день 2017 года, вывела из строя DNS компании Cloudflare. Их код на Go вычислял длительность DNS-запроса, вычитая начальную временную метку из конечной. Когда часы отступили назад, вычисление выдало отрицательную длительность, которая попала в функцию, ожидающую неотрицательный аргумент, что вызвало фатальную ошибку (panic).
Этот инцидент выявил фундаментальный недостаток: многие программные системы предполагают, что время всегда движется вперед, — предположение, которое нарушается стандартной корректировкой високосной секунды. Как объяснили в Cloudflare, «воспринимаемое время разрешения будет отрицательным», что приводит к неожиданным сбоям. Подробнее см. Как и почему високосная секунда повлияла на DNS Cloudflare.
Чтобы избежать таких резких скачков времени, крупные операторы, такие как Google и Meta, используют метод под названием leap smearing (размазывание високосной секунды). Вместо того чтобы добавлять целую секунду сразу, они постепенно замедляют системные часы в течение нескольких часов, распределяя дополнительную секунду. Это гарантирует, что для их внутренних систем время никогда не будет казаться идущим назад.
Метод smearing позволяет избежать резкого разрыва, который приводит к сбоям в программном обеспечении, но создает новую проблему. Разные организации могут использовать разные графики «размазывания», из-за чего показания часов в их системах могут временно расходиться. Это требует тщательной координации источников времени для поддержания согласованности в распределенной инфраструктуре.
Нравится статья? Получайте такие каждое утро на почту.
одно письмо в день · отписка в два клика · без сторонних трекеров
Високосные секунды уходят в прошлое, но время все еще требует внимания
Международные метрологические организации приняли решение отказаться от високосной секунды, при этом изменения должны вступить в полную силу к 2035 году или ранее. Этот монументальный сдвиг допускает большее расхождение между Coordinated Universal Time (UTC) и временем вращения Земли, завершая полувековую историю этих разрушительных корректировок. Решение отражает растущий консенсус в том, что риски перевешивают выгоды.
Ключевым фактором для этого изменения стало недавнее, слегка ускоренное вращение Земли. Это породило беспрецедентную перспективу отрицательной високосной секунды, когда одну секунду пришлось бы удалить из UTC. Такая корректировка, которая никогда ранее не применялась, создала бы еще большие проблемы для программного обеспечения, которое исторически с трудом справлялось с добавлением секунды.
Для разработчиков это означает, что непосредственная угроза високосных секунд со временем исчезнет, но фундаментальные принципы надежного отсчета времени останутся. Всегда используйте monotonic clocks (монотонные часы) для измерения длительности и тайм-аутов, которые гарантируют, что время движется только вперед. Храните гражданские метки времени, часто привязанные к UTC, отдельно от измерений прошедшего времени.
Наконец, тщательно проверяйте все предположения о поведении часов. Даже без високосных секунд системы все равно могут столкнуться с:
- Сбоями синхронизации времени
- Сетевыми задержками
- Ручными корректировками часов
Тщательное проектирование и проверка остаются первостепенными для надежных распределенных систем.
Часто задаваемые вопросы
Что такое високосная секунда?
Високосная секунда — это дополнительная секунда, которая периодически добавляется к UTC, чтобы поддерживать его примерное соответствие неравномерному вращению Земли.
Почему високосная секунда может привести к сбою программного обеспечения?
Некоторые системы повторяют или корректируют секунду на часах, нарушая работу программного обеспечения, которое предполагает, что время всегда движется вперед или что в каждом дне ровно 86 400 секунд.
Что стало причиной проблемы с DNS в Cloudflare в 2017 году?
Корректировка часов назад привела к появлению отрицательной длительности в коде, который ожидал неотрицательное значение, что вызвало критическую ошибку в функции генерации случайных чисел.
Должны ли разработчики по-прежнему использовать монотонные часы?
Да. Используйте монотонные часы для измерения прошедшего времени; обычные часы (wall clocks) все еще могут быть скорректированы и лучше подходят для меток времени и календарного времени.