TGViewer
Патчкорд Патчкорд @patchcord · 2.91K subscribers
Post #3099 1.03K

Forwarded from Технологический Болт Генона

Яндекс признал и осознал, что не может не радовать

15 октября мы раскатили прошивку на 10% устройств. Поэтапная раскатка обновления — это стандартная практика. Она предназначена в том числе для того, чтобы выявлять проблемы новых версий на ранней стадии. И прежде чем увеличивать процент раскатки, мы отсматриваем метрики всех ключевых пользовательских сценариев. Но число генерируемых нами NTP‑запросов исторически никогда не входило в метрики, требующие валидации, потому что NTP‑клиент годами существовал практически без изменений и не приводил к проблемам.

К 24 октября новая прошивка докатилась до 100% колонок. Опять же, критичные для пользователей сценарии покрыты автоматическим мониторингом. Если что‑то важное ломается, мы получаем уведомление. Но, как вы уже догадались, для NTP‑клиента таких уведомлений настроено не было.
. . .
Жалоб было мало, действующий регламент поддержки не был рассчитан на подобные ситуации, поэтому обращения рассматривали не в самом высоком приоритете. К 20 ноября мы нашли ошибку, внесли исправление в код и начали готовить новый релиз.

В выходные 23–24 ноября ситуация с NTP‑серверами обостряется: доступными остаются лишь четыре сервера. К этому моменту мы уже начали раскатывать релиз с исправлением на 10% устройств.
. . .
В воскресенье мы выпустили хотфикс в виде новой рантайм‑конфигурации для NTP‑клиента, который увеличивал период перезапроса с 5 до 600 секунд, уменьшая нагрузку на серверы в 120 раз. Хотфикс не исправлял проблему полностью, но был единственным быстрым способом снять чрезмерную нагрузку с NTP-серверов.
. . .
мы запланировали выделить ресурсы в общий пул NTP‑серверов. Это займёт некоторое время, потому что наши дата‑центры удалены от основных точек обмена трафиком, а для NTP‑серверов RTT (Round Trip Time) это — ключевой фактор качества. Мы установим и запустим мощности на основных точках обмена трафиком.

Для наших устройств мы заведём именную зону в соответствии с гайдлайнами проекта NTPPool.org для бо́льшей прозрачности. Генерируемый ими трафик будет локализован на наших NTP‑серверах, если мы продолжим полагаться на публичную инфраструктуру проекта.

Ещё мы добавим метрики, связанные с NTP, на этап валидации A/Б‑экспериментов, а также реалтайм‑уведомления о неполадках в этом компоненте. В том числе расширим сценарии мониторинга исходящего и входящего служебного трафика устройства в целом. Также поработаем над каналами коммуникаций и поддержкой, чтобы подобные проблемы быстрее до нас эскалировались.


Об инциденте с NTP-серверами
https://habr.com/ru/companies/yandex/articles/861538/

Спасибо подписчику за ссылку
  • 👍 10
More from @patchcord
  1. Oct 5, 2026Мониторинг всех IPv4 адресов в Интернет watchthenet.com за каждые 3,5 часа. Не обновления…
  2. Sep 30, 2026https://dns.museum/
  3. Sep 22, 2026В Cisco OSPF может подниматься в нескольких экземплярах на одном устройстве через конструк…
  4. Sep 21, 2026Никто не хочет TCP в датацентрах, потому что его избыточный контроль сильно замедляет все…
  5. Sep 21, 2026CAIDA какие-то очевидные вещи пишет: если сделать фильтр BGP дампов на стороне коллектора…
  6. Sep 18, 2026Давно не замечал никаких изменений в блокировках у своего провайдера, схема оставалась пон…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →