Вообще я сегодня про другое хотел написать, но невозможно пройти мимо актуальной темы: буквально на наших глазах развернулась поучительная история: как Яндекс почти положил службу точного времени в Рунете.

Краткое содержание: с середины октября российские сервера точного времени (NTP) второго уровня, поддерживаемые сообществом (то есть, люди по собственной инициативе у себя их развернули на роутерах, на своих серверах), испытали практически DDoS-атаку — трафик на них катастрофически вырос, и люди стали их отключать. Из 140 серверов осталось 5. Оказалось, этот трафик посылают умные колонки от Яндекса, в которые с очередным обновлением прошивки приехал баг, заставляющий их слать запросы на синхронизацию времени каждые 5 секунд.

Обнаружил это один из участников пула NTP, и опубликовал 24 ноября статью на Хабре, чтобы привлечь внимание к проблеме. Сейчас Яндекс баг уже признал и исправил, и пообещал установить собственные сервера точного времени, а не полагаться на общественные.

Вопрос методический: чья эта область ответственности?

Кажется, аналитики вообще не очень часто думают об инфраструктурных вещах, таких как DNS или NTP-сервера; на курсах по проектированию интеграций я, кажется, ни у кого не слышал даже упоминания про синхронизацию времени и протокол NTP, хотя это критически важно для журналирования и для разбора событий безопасности. Почти все стандарты безопасности указывают на необходимость установки единого времени на всех системах, входящих в защищенный контур.

Яндексу в колонке точное время нужно для будильников, таймеров и календаря, а также для некоторых технических вещей.

И когда это устройство было экспериментальным — никто особенно не задумывался над серьезностью такого взаимодействия. Ну, сели на общий pool.ntp.org, который используется всеми линуксами и большинством устройств. Оно работает, и ладно.

Когда колонки стали продавать миллионами в год, это уже совсем другой уровень ответственности (ещё один вопрос из курса по интеграциям — с какой скоростью вы собираетесь масштабироваться?). Один непротестированный апдейт — и вся инфраструктура легла.

На мой взгляд, здесь есть три момента, которые относятся к задачам системного аналитика:

1. Анализ эффектов при масштабировании (рост нагрузки на смежные системы, превышение лимитов внешних API);
2. Анализ условий использования внешних систем (у проекта NTPPool есть гайдлайны для вендоров оборудования, им нужно следовать);
3. Контроль и учет всех входов и выходов системы (Сергей Нужненко рассказывал об этом упражнении на Flow).