Comments 440
Еее, дело раскрыто. Спасибо, что отписались.
Ну такое. Что-то мне подсказывает, что в воскресенье вечером кто-то из Яндекса, лениво листая комментарии, нашел штук 10 отсылок, решил посмотреть в код, обалдел и быстро на изоленту все примотали :)
Может и так, но кто в этом признается? Главное, что публично сказали "мы накосячили, исправляемся".
Сложно назвать это косяком. Есть сервис, они его использовали. Я бы не сказал что запросы раз в 5 секунд, причем только в случае сбоя обращения к основному серверу, - это что-то прямо нечто. Никто же не оценивал нагрузочную способность вторичных стратум-серверов.
По идее, гарантированность доступности таких вещей вообще должно не сообщество обеспечивать, а это задача государственного и/или корпоративного значения. Яндекс вот правильные выводы сделал)
Я бы не сказал что запросы раз в 5 секунд, причем только в случае сбоя обращения к основному серверу, - это что-то прямо нечто.
А я бы сказал, что это фееричный косяк проектирования, который оправдать можно только в одном случае - если человек, который это писал, вообще не предполагал, что этот код может пойти в прод, а не останется в лабораторных условиях.
Так-то подобная времянка и в лабораторных условиях непонятно зачем нужна. Если только для тестов и отладки. Но устройств и интернете всё равно на порядки больше, чем колонок. И случайно созданный колоночный ботнет, появившийся в результате этого такого кода, выявил узкое место в инфраструктуре синхронизации, часть которой получается держится по сути на энтузиастах.
Запросы раз в пять секунд от десятков (сотен?) тысяч этих станций к stratum 2,3 серверам энтузиастов, собранным из г.на и палок запущенным на роутерах и домашних каналах. Ага-ага.
Есть сервис, они его использовали.
Сервис есть. И правила его использования есть. Сервис использовали, на правила положили.
Хотел расширить вышепрозвучавший тезис от @nevzorofff- в правилах чётко сказано:
не выкидывайте грязных трюков с параметрами burst и minpoll — все, чего вы добьетесь, это гибель нашего проекта, раньше или позже
а интервал опроса в 5 секунд - это явный "грязный трюк с minpool", так что всё-таки "косяк".
Вчера в netflow логах ещё видел сотни пользователей, генерирующих запросы к ntp каждые 5 сек. Сегодня их уже не осталось. Похоже что да, апдейт докатился до всех. УРА! Нагрузка на пул стабилизировалась, это вижу и сам, об этом в телеге мне отписался администратор ещё одного сервера :)
Остались вопросы:
Я.девайсы примерно каждые 20-30 сек ресолвили DNS-записи [0-5].ru.pool.ntp.org (я видел это своими глазами) + люди писали что колонка периодически запрашивает SOA зоны. Зачем ей это? Может тоже баг?
В твоём топике на хабре также были озвучены предложения к Яндексу:
выделить сервера для общего пула
зарегистрировать в пуле свою vendor-зону для своих дейвайсов (см https://www.ntppool.org/ru/vendors.html). Хотя тут есть и плюсы и минусы. Без зоны есть плюс в том что трафик запросов ходит до ближайших серверов (иногда это будет сервер прямо у провайдера) а не в интернеты на сервера Яндекса.
Вопросы по пулу и трафику в целом:
отчего так много icmp port unreachable? Я писал в теме на ntppool что 25% трафика приходящего на мой сервер это icmp. Это спуфинг или ковровые блокировки ntp-протокола? По идее блокировки делались бы drop'ом без отправки icmp.
Вендор-зона требует от коммерческих компаний отчислений пулу - а с этим из РФ, как понимаете, есть некоторые проблемы.
Про SOA записи, возможно клиенты пытаются получить AAAA для IPv6, а ее нет.
Отчего так много icmp port unreachable? Это спуфинг или ковровые блокировки ntp-протокола?
Судя по высокому объёму подобного трафика, это всё-таки результат спуфинга — для DRDoS-атаки на чью-то инфраструктуру. Никакого отношения к умным колонкам не имеет, если только они не взломаны и не являются частью ботнета, генерирующего фейковые запросы от имени чужого IP-адреса.
Про icmp:
Допустим, как вариант, ваш сервер отправляет ответный пакет на ip и порт вопрошающего клиента. Если у клиента истёк тайм-аут ожидания ответа на запрос, то порт закрывается. Пакет на закрытый порт заставит уст-во клиента отправить "icmp port unreachable" в вашу сторону.
отчего так много icmp port unreachable? Я писал в теме на ntppool что 25% трафика приходящего на мой сервер это icmp
Сейчас наблюдаю у себя, что 47% ответов моего ntp-сервера приводят к icmp port unreachable. На спуфинг не особо похоже, вряд ли спуферы стали бы с такой дотошностью имитировать поведение клиента. Так что, скорее "ковровые блокировки ntp-протокола". Когда станции DDoSили, могли на скорую руку, например, наконфигурировать statefull NAT таким образом, что сейчас он просто не знает куда кидать ответ и кидает его кому попало, а тот честно говорит - это не мое (icmp port unreachable)
Читал тот пост, о котором речь. Было интересно, но малопонятно. Но с этим постом стало ясно, почему моя станция лайт выкачала за 4 часа 5,26 гигабайт трафика, в конце октября.
Тайна стиральной машины раскрыта! =)
Мне больше интересно - из месяца с небольшим, который ушел на разбирательства, сколько времени потребовалось на осознание проблемы (фактически - достучаться до кого-то понимающего, что произошло), и сколько на решение.
Добавим второй вопрос, из-за чего не договорились об собсвенном пуле, как у убунты есть свой ubuntu.pool.ntp.org
Третий вопрос, из-за чего не поставили свои NTP сервера? Тогда бы сейчас не было это-го поста и не было кучи вопросов. А так фактически устроенный DDOS на чужую инфру.
Задним числом все умные, но в реальной жизни никто не будет думать о выделении отдельных серверов времени под экспериментальную железку и никто не будет думать о синхронизации времени как о дорогой операции которая может положить сервера.
Это классический щит хэппенс за который тебя будут упрекать люди которые сами сделали бы точно такую же ошибку, но обладая послезнанием считают что всё очевидно и надевают на себя белый фрак.
Где она экспериментальная? Заполонила уже всю Россию.
Не согласен насчёт "никто".
В фирме, занимающейся разработкой промышленной продукции, должен быть отдел метрологии, и он в данном случае плохо выполнил свою работу. Синхронизация времени – недорогая операция, но правильный порядок её выполнения, как и всякого другого измерения, регламентирован федеральным законодательством. Если бы Яндекс правильно выполнял измерение времени, то он не пользовался бы для этого анонимными часами, и до падения общественного пула дело бы не дошло, а Яндекс бы гораздо раньше положил сервер той или иной уполномоченной организации и получил бы от неё по голове, о чём широкие пользователи не узнали бы. Притом, что, как написано в статье, синхронизация времени критически важна для Яндекса, выполнять её абы как – некрасиво.
Я, может, испорчен некоторым профессиональным опытом в этой области, но для меня ваш довод звучит примерно как "кто ж знал, что бензин нельзя разбавлять ослиной мочой". Вот именно этим инженер и отличается от выпускника курсов "Питон за 48 часов". Он должен понимать, что наводнение страны миллионом синхронизирующихся друг с другом коробочек образует новое качество системы.
А Яндексу надо бы задуматься не просто о серверах NTP, а о поддержании у себя вторичных эталонов времени на базе атомных часов. Это на самом деле недорого в таких масштабах, но нужно для выполнения тех функциональных задач, на которые он претендует. Фирма, в которой я работаю, намного меньше Яндекса, но поддерживает собственные атомные эталоны.
Яндекс, у вас есть главный метролог? Он согласовывал ТУ на колонку, имеющую функцию часов?
Но зачем? Зачем для Яндекс-станций отдел метрологии? Вы ещё предложите их на поверку регулярно носить...
Яндекс-станциям не требуется юридически значимое время. Им даже не требуется точное время. Им требуется чтобы их часы не сильно расходились друг с другом (для взаимодействия друг с другом), и хотя бы примерно соответствовали общемировому времени (для работы TLS и всяких будильников).
Использование NTP пула более чем удовлетворяет этим требованиям, нужно было лишь соблюдать правила самого пула.
А Яндексу надо бы задуматься не просто о серверах NTP, а о поддержании у себя вторичных эталонов времени на базе атомных часов.
Не нужно. Вот если ставить у себя атомные часы - то отдел метрологии и правда может потребоваться. А поднять сервер NTP и включить его в пул может любой админ, и это будет вполне рабочим решением.
А поднять сервер NTP и включить его в пул может любой админ, и это будет вполне рабочим решением.
... до тех пор, пока не выяснится, что оказание услуг российским гражданам в виде предоставления времени является предметом санкций правительства США. Уж гораздо более логичная цепочка будет, чем с приёмом коммитов в ядро Linux.
Я уж даже не вспоминаю о том, что вендоры, использующие в своих продуктах ntp.org, вроде как должны платить за это деньги администрации ntp.org.
Учитывая, что услуги предоставляются энтузиастами и безвозмездно, а пул лишь балансирует нагрузку - любые санкции тут будут выглядеть как "назло маме отморожу уши". Но да, политики и правда могут так поступить, особенно когда уши чужие.
Однако, даже если и правда случатся NTP-санкции, держать свой NTP сервер всё ещё проще чем свой отдел метрологии.
Так этот свой сервер всё равно должен где-то брать время предыдущего стратума.
Так у того же пула можно взять время. Пул может отказать в регистрации префикса из-за санкций - но не может ничего поделать с обращением по общему адресу, который pool.ntp.org (потому я и сравниваю ситуацию с отмороженными на зло маме ушами), или с прямым указанием IP адреса.
Да, такое решение поддерживать сложнее чем вендорный префикс, но ничего невозможного.
Ну и всегда можно взять время у тех самых "уполномоченных организаций".
Теоретически ничто не мешает заблокировать pool.ntp.org для запросов с российских ip, по примеру intel.com и других.
Ещё как мешает. У интела свои сервера, и блокировка сделана на стороне серверов. А у pool.ntp.org все сервера - волонтёрские, и управляются они вовсе не пулом.
Единственное что может сделать пул - подкрутить свой geo-dns чтобы запросы из России не резолвились. Однако, обходится такая блокировка настолько просто, что даже не все российские пользователи её заметят. И уж точно она не станет проблемой для опытного админа.
Эту всю историю про волонтёрские серверы мы уже прошли с одним обиженным финном. Оказывается, когда надо, они волонтёрские, а когда надо - это американское юрлицо.
Обиженный финн может сколько угодно настраивать блокировки на своём сервере, но до тех пор, пока так не поступят более половины владельцев серверов - результаты их стараний никто не заметит.
И нет, все волонтёры сразу вот никак не могут оказаться американским юрлицом. Хотя бы потому что многие из них вообще не в Америке.
Если вы не согласитесь с условиями использования ntp.org, на ваш сервер просто не будут форвардить запросы из пула. Т.е. работать-то вы сможете, но в зону DNS ntp.org входить не будете.
Вы имеете в виду, что пул может начать давить на волонтёров, чтобы они блокировали запросы из России на уровне файервола?
Что-то мне подсказывает, что большинство владельцев серверов либо забьют на эти указания, либо со словами "ну, раз не хотите - значит, и не надо" сами выведут сервер из пула.
Ну и вообще даже интересно как эти условия будут проверяться. Пулу же для этого понадобится монитор в России, а сервер для него приобрести не получится из-за тех же санкций...
вчера тоже про это думал. Ask Bjørn Hansen (админ/вледелец пула) по-моему живёт в США.
В связи с инцидентом и самизнаетечем, Яндекс может родить аналогичный проект национального масштаба. Правда смысла в этом немного, если только у операторов потом сделать pool.ntp.org CNAME pool.ntp.рф но хайджекинг записей это невесело
Яндекс не может поднять S1 и брать время с GNSS?
P.S. Такое наверное даже с могу себе позволить
Не удивлюсь если это не просто.
GNSS-приемник в датацентре - чуть сложнее чем дома.
А еще - как минимум в Москве и Питере - есть блуждающие пространственно-временные аномалии (обычно создающие телепорты в ближайший аэропорт) и это тоже придется учитывать.
GNSS-приемник в датацентре - чуть сложнее чем дома.
Масштабы Яндекса и меня в финансовых и технических ресурсов тоже несопоставимы
Но да, я допускаю что в ДЦ это может быть несколько сложнее
Профессиональный приёмник времени все эти тонкости учитывает и не берёт в обработку время, если волшебным образом перенёсся куда-то.
В описании Сервер точного времени Метроном-PTP-1U есть "Антенна ГЛОНАСС/GPS 40дБ (кабель до 150м)", что должно хватить на любую конфигурацию датацентра.
попробуйте согласовать "нарушение электромагнитной целостности машинного зала" - потом прокладку кабеля по трассам ДЦ и вывод Внешнего антенно-фидерного устройства....
Удивительно сколь много нового узнают Люди о том что это оказывается очень зарегулированная и очень даже непростая Область пресечения интересов ФСБ, ФАПСИ и еще нескольких многобуквенных организаций.... и Метрология и ГОСТы и приказы ФСБ, ФСТЭК и еще нескольких столь же милых Абревиатурных контор для вас станут настольными документами на ДЛИТЕЛЬНЫЙ и зело болезненный период времени...
Молчу про ситуацию когда в ЦОДе присутствует соответствие 152ФЗ.... а если там еще и "....вплоть до 1-го класса включительно...." - тут уже проще ЦОД сменить....
Однако - опыт, грабли....
Сервер времени с приемником может находиться вне ЦОД.
"При наличии желания есть тысяча возможностей, при отсутствии желания есть тысяча причин."
Не пугайте, пожалуйста, 152ФЗ - под него любой сервер 1С:Бухгалтерия/1С:ЗУП попадают, и ничего - видел, как стойка с парой серверов стоит в общем (на несколько фирмочек) тамбуре, практически на лестнице, так как "шумит сильно".
конечно - до первой реально проверки или утечки все забивают.... вон счас штрафы в ~1000 раз подняли посмотрим как дёргаться будут...
и да 1c: ЗУП это в пределе 3-ий класс, ну в самом максимуме второй.... хоть и непонятно нафига такой геморрой работодателю...
когда у цода и/или Маш. залов всё сделано под 152-ой фз - никто вам не даст ничего менять в составе, т.к. это опять деньги на замеры, согласования документы итп итд..... тем более ставить столь "чувствительные" штуки как антенно-фидерные устройства.... там одно согласование и сертификация для контроля ПЭМИН - это геморрой на полгодика... особенно если железка не дай-то бог хоть чуть-чуть импортная, а ИС в машзале проходит как часть КИИ.....
по-моему аппаратный сервер типа Meinberg'а стоит условно 100-300тыр (сейчас может и миллион, но есть наши аналоги), он умеет в GNSS (спутники) и содержит TCXO/OCXO который способен продолжительное время поддерживать точный ход, даже если спутники пропали или выдают чушь. Ну в конце концов цезиевые/рубидиевые источники можно купить у того-же ВНИИФТРИ.
Ставим N штук в кластер, на них завязываем уже машины с ntpd/chrony способные держать гигабиты трафика. Поехали.
Я когда отлаживал приложение-трекер, встречал и телепорт в какой-то населённый пункт в юго-восточной Азии - оказалось, некоторые китайские глушилки (уж не знаю, кто ими пользуется, но пользуется явно не один человек, т.к. на автобазе, где я занимался отладкой, полёты к побережью Жёлтого моря случались регулярно) забивают эфир на сотни метров.
О том и речь.
С GPS/ГЛОНАСС можно получить время Stratum1 без проблем.
Вопрос, кстати. по поводу этого:
Вычисления координат сравнительно сложные, требуют хорошего сигнала итд итп. Поэтому чип сравнительно дорогой.
1) А бывают чипы, которые всего этого не считают, а просто тупо выдают наружу то время, что услышали ну с миллисекундной точностью. Для бытовых нужд - вроде бы как вполне достаточно.
Чип дешевле не получится?
2) GPS, как я понимаю, не единственный радиосигнал, что время дает. Альтернативы - аналогично - не дешевле будут?
Если для личных целей, то модули с погрешностью привязки с микросекундной точностью обойдутся по цене одного похода в магазин за продуктами или ещё дешевле если будет только GPS, без ГЛОНАСС и BeiDou. Точно не скажу, покупал года три назад.
Если для целей метрологии, то цены совершенно другие, но и точности на порядки выше.
В серьезных местах ставят рубидиевые или водородные стандарты частоты.
Например, водородный стандарт Ч1-1007 синхронизируется с UTC(SU) с погрешностью не более 50 нс (0,000 000 05 с), а также может подстраиваться автоматически. За год автономного хранения, т.е. без синхронизации, уход его шкалы в худшем случае составит 16 мкс (0,000 016 с). ССхтоит как два китайских автомобиля. Антенна, приемник и кабель 5 в комплекте. Задержка в кабеле также учитывается.
Остальные варианты, в основном, между этими двумя
Если для личных целей, то модули с погрешностью привязки с микросекундной точностью обойдутся по цене одного похода в магазин за продуктами или ещё дешевле если будет только GPS, без ГЛОНАСС и BeiDou.
Не, все равно дорого. Вопрос (праздный, впрочем) о том, что такого можно впаять в дешевые но слишком умные часы (они же - очередная умная колонка) так, чтобы их вообще можно было не подводить. Ни по NTP, ни каким-нибудь другим способом.
так, чтобы их вообще можно было не подводить. Ни по NTP, ни каким-нибудь другим способом.
Зависит от того, какая точность вам нужна. Технически, если вас устраивает погрешность в несколько секунд достаточно обычного кварца и возможности установить время вручную. А вот если вам нужно точнее, и еще чтобы не устанавливать время в ручную, то такого, чтобы работало прямо везде, включая подвалы без окон, где не принять никакой радиосигнал -- ничего не впаяешь.
Вопрос (праздный, впрочем) о том, что такого можно впаять в дешевые но слишком умные часы (они же - очередная умная колонка) так, чтобы их вообще можно было не подводить. Ни по NTP, ни каким-нибудь другим способом/
Любой потребительский GPS-ресивер. Они все умеют получать "условно точное время".
зачем яндексу для потенциального сервера NTP точность выше миллисекунды?) там сетевые пинги больше будут, да и для Алисы точность даже в несколько секунд будет вполне приемлемой
Радиостанция RWM? её вроде не забанили и санкциям не подвергли
Было бы неплохо, но как-то немного информации нашёл по ней и совсем не нашёл устройства для приёма сигнала и подключения к серверу.
Или хотя бы ПО, которое можно установить на сервер и к звуковой карте подключить КВ-приёмник.
Есть отечественные аналоги: РБУ и РТЗ. Хотя, может уже и нет - их до 2024 обещали ликвидировать зачем-то
Это как с Курском. Ликвидировали СВ/ДВ вещание и оказалось что в условиях ЧС оповещать население нечем. И вообще вести иновещание на сопредельное государство.
Правда в 2021 году Росстандарт был против:
Росстандарт выступил против планируемой ликвидации радиостанции, транслирующих сигналы точного времени. Сейчас такие радиостанции находятся в ведении РТРС. К 2024 г. их планируется отключить, хотя их сигналы, в числе прочего, используются для обеспечения безопасности и обороноспособности страны.
Нужны ж и приемники СВ/ДВ.
Я вот вообще не очень понимаю почему нельзя встроенную в мобилки систему которая в США для оповещения используется задействовать в России? Там какая то особая авторизация и любой оператор сотовой связи к которому мобилка подключена - не может ее использовать? Хорошо ну а хотя бы cell broadcast? Ладно если это сложно - активно рекламировать установку приложения МЧС + договорится с ВК и Яндексом чтобы показывали баннер по геотаргетингу (причем НЕ как рекламу, именно отдельного формата чтобы его случайно адблок не накрыл)
ЧС - это электричества нет, мобильных станций нет, ФМ радио не работает. Вот наваливает паника, которая наносит больше ущерба чем само ЧС.
Если бы было СВ/ДВ, то приступов паники не было. Люди бы знали куда эвакуироваться.
СВ приёмник есть практически в каждом автомобиле, в портативных приёмниках этот диапазон также почти всегда есть.
Китайцы выпускают хорошие и доступные всеволновые приёмники (в некоторых даже есть ДВ, но без доработок они почти ничего на ДВ не принимают).
Но "умные" люди посчитали, что ДВ/СВ/КВ вещание - слишком дорого и никому не нужно, вещание прекратили а антенны попилили.
Да кто его слушает?
И в чём сложность в телеэфир пустить оповещение? Всё же на цифре и под одним вещателем по всей стране.
Какой телеэфир ,если передающая станция уничтожена?
Радиус действия современного телепередатчика цифрового ТВ около 20 км.
Какой телеэфир ,если передающая станция уничтожена?
У нас в области 42 района и 103 передатчика. Все 103 уничтожили?
Во многих местах ловятся по два из них.
И сколько ловилось в Судже?
После объявления ЧП с местной вышки ещё неделю ловилось, т.е. один минимум. именно столько времени потребовалось ВСУ, чтобы дойди до центра Суджи.
Я ещё так прикинул — родители АМ приём, наверняка включить не смогут, у тёщи даже машины нет. Жена хз, проверю, но, тоже, думаю, не сможет )
Толку от оповещения на СВ - минимум.
Проработали т.к. не было цели гасить электроподстанции - можно было повлиять на работу газопровода, вокруг денег которого и крутятся эти события.
Погасло быстро электричество как в Крымске, в Крыму или при наводнение на Урале в этом году и никаких работающих станций в округе нет.
Люди живут при ЧС в авто - в каждом авто есть телевизор чтобы получить сообщения?
Карманный АМ/ФМ радиоприемник вполне может найтись. В автомобиле он всегда в штатной магнитоле.
Наконец на дорогах РФ чуть в сторону Урала начинаются зоны неуверенного приема или вообще отсутствие. СВ и КВ в РФ нет. Только Иран, Китай в эфире.
В автомобиле он всегда в штатной магнитоле.
Включить АМ смогут, дай бог, процентов 10
Карманный АМ/ФМ радиоприемник вполне может найтись.
Может найтись, а может и нет. У к компу подключен ресивер, там есть приёмник, а рамочная антенна для АМ попадалась летом или на балконе, или в гараже, и в случае ЧС я её точно искать не буду.
Люди живут при ЧС в авто - в каждом авто есть телевизор чтобы получить сообщения?
Люди не живут в машинах в мирное время, а начинают там жить после того, как узнали о ЧС.
Сигналы точного времени регулярно слышу на 10000кГц и 15000кГц, приём хороший.
Вроде передатчик в Новосибирской области, RTA
Чип дешевле не получится?
Вряд ли, так как надо будет отбить отдельный дизайн и производство этих узконаправленных и мало востребованных чипов, при том, что далеко не факт, что вычисление координат занимает какой-то ощутимый транзисторный бюджет по сравнению с обработкой сигнала необходимой для его приема.
узконаправленных и мало востребованных чипов
Почему, кстати, невостребованных? Нормальных стационарных, не умных, не подключенных ни к каким сетям электронных часов - еще достаточно много выпускаются. В них такой тоже можно ставить.
Если такие часы поставить в спальню или повесить на стенку внутри дома, спутниковый приемник точного времени ловить не будет. Вряд ли такую ограниченную фичу удастся продать. К тому же для этих целей уже существуют модули, принимающие сигналы точного времени от наземных радиостанций. Стоят 170 рублей на Али, в часах стоили бы еще дешевле, но особо их в бытовые часы не ставят.
ринимающие сигналы точного времени от наземных радиостанций.
Во... стоимость чипа, что именно оно ловит и почему бы в условную колонку не поставить чтобы с NTP не связываться? Там у меня в вопросе второй пункт про это был.
и почему бы в условную колонку не поставить чтобы с NTP не связываться?
Колонка в любом случае работает от сети, поэтому ставить туда отдельный приемник, пусть даже за 100 рублей посчитали излишним, ведь в сети есть NTP. То что кто-то может накосячить и положить почти всю инфраструктуру просто не учли, да и косяк максимально на ровном месте, такие часто недооценивают.
GPS/GNSS?
В том числе. Но спутниковое вещание тоже запросто могут отключить, на более или менее продолжительное время, поэтому к приёмнику всё равно нужны автономные часы.
Но спутниковое вещание тоже запросто могут отключить
Его нельзя запросто отключить, а ведь кроме gps, есть и другие gnss, тот же ГЛОНАСС. Тем более что сейчас чистый gps-модуль днем с огнем не сыщешь, все они за сравнительно небольшую цену умеют несколько систем gnss.
Относительно просто его спуфить локально, но это совсем другая проблема, чем отключение gps с той стороны
Я как раз имел в виду спуфинг.
Разницы-то нет, с какой стороны дёрнуть рубильник.
Бей своих, чтобы чужие боялись? Прекрасно
Достаточно потенциальной возможности обстрела (что актуально для любого крупного датацентра) и, как следствие, работы РЭБ.
При таком развитии событий очевидно что не до колонки с Алисой будет дело, там скорее всего ЦОДы будут уже в труху либо страдать от энергетических отключений, либо переориентированы под иные нужды, а без ответной серверной части колонка от Яндекса бесполезна.
Так одно давно уже тогось, развилось. Сейчас по России по официальной статистике МО РФ прилетает несколько десятков БПЛА самолётного типа в сутки, в основном они сбиваются объектовыми ПВО и РЭБ. Поэтому в промзонах в основном сейчас ГНСС не работают. Думаю, что и ЦОДы Яндекса являются одними из фактических целей, и сами по себе, и как часть инфраструктуры, где они стоят.
Так что уже прямо сейчас есть такие большие зоны, где никогда или время от времени нет спутниковой навигации.
Более интересно что будет если будут санкции Российского правительства за предоставлению времени гражданам недружественных стран. У кучи серверов(особенно ру-сегмента) ж российские администраторы.
С учетом как обычно Роскомнадзор работает....
Представляю диалоги с улиц будущего за океаном:
- Вы время не подскажите?
- Паспорт покажите пожалуйста, а то у вас такой акцент, как бы санкции не нарушить
Им даже не требуется точное время. Им требуется чтобы их часы не сильно расходились друг с другом (для взаимодействия друг с другом)
На такой случай можно сделать локальную синхронизацию колонок.
UPD: уже предложили.
Вы выссказываете очень правильные аргументы. Для ситуации завода и промышленного производства.
Но интернет изначально, в своём фундаменте строился на несколько (или существенно :) более анархических принципах. И использование в продакшн КАКОЙ-ТО чужой инфраструктуры и каких-то опен-соурс компонентов - это де-факто общепринятая практика. Это несколько понижает надёжность системы, но критически улучшает параметр time-to-market (время вывода на рынок нового изделия).
Когда заказчик один - государство и он согласен подождать лет 10 готового изделия (и оплачивать все эти 10 лет работы коллективов разработчиков) - то да, надо каждую мелочь продумывать и свою службу метрологии содержать.
А в этих ваших интернетах - либо надо БЫСТРО запустить продажи своей идеи, либо она уже будет не особо кому-либо нужна. Ибо все уже у конкурентов купят. (См историю про Вася и Петю).
И просто дешевле иногда устранять последствия провалов.
Яндекс готов на себя взять устранение всех возможных последствий провалов при использовании своих изделий? Сомневаюсь. И в возможных будущих судебных процессах этот аргумент про time-to-market будет выглядеть бледно.
Всё таки у дедушки Ляо и у компании, претендующей на место где-то около государственной монополии в IT, и на уровне федерального законодательства пропихивающей обязательную установку своих поделий на вычислительную технику, должен быть разный подход к организации работ.
Вы как будто не в России живёте. Какие нафиг судебные процессы?
Вот если бы Яндекс-станции положили не общедоступный пул, а сервера "той или иной уполномоченной организации", как вы предлагали ранее - могли бы и судебные процессы возникнуть. А сейчас-то кто и на кого в суд подаст?
Яндекс готов на себя взять устранение всех возможных последствий провалов
Я же говорю - на более анархичных принципах :)
Если кто-то считает, что эти провалы нанесли лично ему материальный (или моральный) ущерб и готов доказать свою позицию в суде - то он в рамках частного обвинения обращается в суд.
А юристы компании-разработчика - финансово оценивают риски такого развития событий.
А в этих ваших интернетах - либо надо БЫСТРО запустить продажи своей идеи, либо она уже будет не особо кому-либо нужна. Ибо все уже у конкурентов купят. (См историю про Вася и Петю).
В этих наших интернетах есть готовый ntp клиент (аж целых 3 по-моему). Который правильно написан и не создаёт нагрузку. Но Yandex, почему-то, написал свой.
Уточнение: Яндекс написал не NTP-клиента, а SNTP-клиента — примитивную state-less опрашивалку сервера без самостоятельного вычисления коррекции хода часов (позволяющего ограничиваться 4 запросами в час для поддержания миллисекундной точности, или даже 1 запроса раз в несколько часов при менее высоких требованиях к точности).
Пардон, но Интернет изначально строился как раз не на таких принципах, а людьми ответственными. Коммерциализацию и time-to-market в него начали тащить с начала 90-х - и всё и покатилось по наклонной.
Ничего, скоро за вот эти "у конкурентов быстрее купят" стрелять начнут.
Метролог нужен только если бы они действительно использовали собственные эталоны. В чём нет необходимости, потому что колонке не нужна такая точность. Тут другая ситуация. Колонка была по сути экспериментальным продуктом, поэтому использовали ntp пул чтобы сократить расходы на инфраструктуру и разработку. И почему не переехали на собственную инфраструктуру, когда проект оказался успешным — вопрос хороший.
так в статье же и ответ: потому что забыли, ибо работало хорошо и не отсвечивало
Это понятно, золотое правило "работает — не трогай". Просто когда используется открытая инфраструктура — это дополнительная точка отказа. Если используется своя, можно сбалансировать нагрузку, выделить сервера, чтобы было время решить проблему. Тут же всё пришлось делать сообществу пока Яндекс не выкатил хотфикс.
Яндекс, респект что не стали молчать и довольно оперативно всё порешали.
Добавлю. Тоже работаю в фирме, намного, намного меньше Яндекса, которая делает ответственные вещи для жд и метро с огромными показателями надёжности и безопасности (занимаюсь только ПО). И тут вопрос, а вы готовы тратить время и деньги на разработку такого прибора с учётом, что затраты на обеспечение надёжности идут по экспоненте. И сколько по итогу он будет стоить. Или же вы предпочтёте сначала проверить, выстрелит этот продукт или нет, возможно откусить кусочек рынка, а потом уже допиливать. И готовы ли вы, как потребитель, переплачивать за супер надёжный продукт, но который стоит как крыло самолёта.
Ну и скажу вещь, которая некоторым может показаться отвратительной, но которая есть в любом учебнике по функциональной безопасности. Если затраты на покрытие возможного ущерба за время эксплуатации прибора меньше, чем затраты на обеспечение этого уровня безопасности, нет необходимости его реализовывать :)
Яндекс.Станция это бытовой прибор вроде чайника, а не АСУТП сталелитейного завода. Какие метрологи, о чём вы?
Яндекс, у вас есть главный метролог? Он согласовывал ТУ на колонку, имеющую функцию часов?
А на неё вообще ТУ имеются ?
На мой взгляд все эти поделки a-la "яндекс колонка" - чистый самопал сделанный на аутсуорсе за три дня и три копейки.
Хотели они нанять главного метролога, но случайно наняли главного маркетолога
Я протестую, не нужно заднее число чтобы понять что алгоритм "долбимся раз в минуту, а если не получилось, то каждые 5 секунд" - полная дичь. Где exponential backoff?
так это он и есть xD, просто основание экспоненты < 1
Зашёл сюда написать этот комментарий, а он уже написан :D
Я где-то слышал, что в Яндексе работают только лучшие их лучших, и собес у них без знания всех четырех томов Кнута не пройти. ;)
Так Кнут вообще не про то
Что не мешает Яндексу периодически бить рекорды по оподливливанию. То у них данные миллионов клиентов утекут, то их научатся кидать на их Станции каким-то непроходимо тупым способом, то теперь вот сами ботнет сделали...
Наглядная иллюстрация, что все сложные собесы никак от идиотизма не защищают.
Прочтения https://www.ntppool.org/ru/vendors.html хватило бы для того, чтобы быть умным до, а не после. Этому же помогло бы изучение алгоритмов ntpd и chrony с попыткой, почему сделано так, а не иначе. Тем более, что относительно недавний баг в systemd-timesyncd как бы намекает, что можно легко облажаться.
Ну, тут пул тоже отчасти виноват. То, что правила пользования пулом pool.ntp.org следует искать на сайте ntppool.org - вот вообще неочевидно, и найти эту информацию на том же ntp.org не так-то просто.
Скажу больше, правила искать надо не на pool.ntp.org, а на www.pool.ntp.org, потому что pool.ntp.org разрешается в рандомный ntp сервер и браузером не откроется в большинстве случаев, или же откроет какой-нибудь рандомный сайт, на котором запущен NTP-сервер и включен в пул.
Отчасти поэтому ntppool.org и появился, потому что WWW вбивать в адресную строку моветон уже лет 10 как
«Никто», ага. Не надо нормализовывать некачественное отношение к работе.
но в реальной жизни никто не будет думать о выделении отдельных серверов времени под экспериментальную железку
Зато вместо использования готового клиента, строить свой высокотехнологичный велосипед - это пожалуйста =)
Каким задним? Не надо оправдывать рукожопов, которые ни правил использования сервисов не читали, и на чужих ошибках не учатся:
Есть раздел для вендоров, там чтива на пару-тройку минут и для самых упёртых уже есть упоминания подобных инцедентов:
A couple of examples in the past years are Flawed Routers Flood University of Wisconsin Internet Time Server in 2003 and the D-Link misconfiguration incident in 2006.
В 2018 году была статья на Хабре - Интернет убыточных вещей, про то что очень плохо использовать чужой NTP сервер для собственных умных вещей.
Похоже, что в Яндексе эту статью не читали.
Вводный фрагмент этой статьи
Почти два года назад, в понедельник 16 января 2017 года, в нашу систему баг-репортов BitFolk поступил интересный тикет от постороннего лица. Отправитель представился как ведущий инженер-программист компании NetThings UK Ltd.
Тема: запрос NTP на IP 85.119.80.232
Привет,
Это может показаться странным, но мне нужно настроить сервер NTP по IP-адресу 85.119.80.232.
Что такого особенного в адресе 85.119.80.232? Это IP-адрес одного из NTP-серверов для обслуживания наших клиентов. За несколько недель до этого тикета сервер также был частью проекта NTP Pool.
Здесь важное слово «был». В конце декабря 2016 года я вывел NTP-серверы BitFolk из общественного пула и заблокировал их для посторонних.
Я так поступил, потому что из-за бага Snapchat NTP на них пошёл необычно большой трафик. На самом деле это не вызвало каких-то огромных проблем, просто такой объём трафика выталкивал полезную информацию из базы сохранения сетевого потока Jump фиксированного размера, а я не хотел разбираться с этим во время праздников, поэтому просто отключил публичный доступ к сервису.
PS Яндекс платил за услугу NTP или нет?
Предполагалось, что коммерческие компании будут обращаться в отдельную «зону вендоров». Они перечисляют проекту небольшой взнос — и получают зону DNS, выделенную для их продукта, так что администраторам пула проще направлять трафик.
PPS Оказалось в Wiki есть статья с такими достижениями компаний в разные годы - NTP server misuse and abuse.
PS Яндекс платил за услугу NTP или нет?
кмк, второе
Flawed Routers Flood University of Wisconsin Internet Time Server
- Netgear Cooperating with University on a Resolution -
Этот канон (2003-2005) рекомендую к чтению наряду с "What Every Computer Scientist Should Know About Floating-Point Arithmetic".
https://web.archive.org/web/20060410200249/http://www.cs.wisc.edu/~plonka/netgear-sntp/
Надо бы обновить Wiki
Это главный вопрос. Отдельная зона в таких случаях позволяет потушить зону вендора, а не весь пул. За это кто-то должен быть наказан.
Знал бы где упадёшь - соломки бы подстелил.
Профессионализм показывается не тем, что компания или человек не допускает ошибок, а тем, как на свои ошибки реагирует.
Согласен полность, это либо экономия либо воровсво. Хуже воровства только простота, что не допустимо в сложных системах )))
Думаете увидим yandex.pool.ntp.org или ya.pool.ntp.org или alisa.pool.ntp.org ?
Добавим второй вопрос, из-за чего не договорились об собсвенном пуле, как у убунты есть свой ubuntu.pool.ntp.org
О таком мало кто заботится. Возьмите какой-нибудь домашний роутер, скажем, TP-Link или ASUS - их по миру немало натыкано, но во всех из коробки будет прописан адрес pool.ntp.org (или региональный типа ru.pool.ntp.org), но своего пула не заводят.
С роутерами другая история - их по всему миру продают, невозможно предсказать где именно он будет работать. Арендовать серверы по всему миру физически невозможно, а запрашивать в условном Зимбабве время с сервера в Тайване = создать нагрузку на сеть даже больше, чем если просто взять её у локального поставщика. Тем более обычно роутеры не запрашивают время раз в 5 секунд.
Деньги.
Как работник корпорации с 2+млн сотрудников, могу сказать, что несмотря на то, что отсутствие своих серверов усложняет многие внутренние процедуру сертификации - тем не менее и днс и нтп - внешние, ибо надо на них выделять бюджет.
А с точки зрения менеджмента - зачем, если все работает.
Скорее всего это было в результате ленивого чтения Хабра и такого же типа блогов. Как они сами указывают в статье - это не покрыто тестами.
Сколько ещё такого кода может, внезапно (как любит писать Максим в ЛОРе), создать на ровном месте аварийную ситуацию?
Как в моей практике это было с BIND4, хорошо что меня в своё время буквально ткнул носом в проблему AI (https://uic.vsu.ru/archive/5let/andy.html), в то время старший администратор ВЦ ВГУ, опорной точки сети RBNet.
Из личного опыта, нахожусь по счету на 4 линии техподдержки, пока проблема дойдет до меня она немного помаринуется на остальных трех, если действительно проблема есть и клиент не может починить сам, то я её увижу через неделю +/-2 дня.
То есть на первых трех линиях проблема маринуется по три дня примерно??? В нормальных сапортах первые два линии отрабатывают за пару часов, третья - сутки.
Ну в нормальных да, а Яндекс тут при чём)
На первой линии, по моей памяти, проблема дольше часа - это факап. На второй - сутки-двое. На третьей - неделя-другая. С четвёртой линией в штате как-то не сталкивался - в моей практике это либо вендор, либо подрядчик (да, с малазийцами был прикольный опыт, но это оффтоп)... даже не представляю, сколько может такое времени занять.
в той теме о коллапсе пула вчера отписывался сотрудник поддержки с заявлением в духе " колонки ведут себя нормально, просто им нужно очень точное время иначе будильник может зазвонить не вовремя". Конечно, на него слегка накинулись :)
А мне интересно, откуда взялся график? Его собирали "на всякую случку" или был повод ранее? Если первое, то нужно просматривать результаты мониторинга и отлавливать аномалии по всем собираемым показателям, при чем и на тестовых средах, что наиболее правильно, и при раскатке на фокусных группах особенно. А если второе, то нужно еще и сделать оргвыводы.
Планируете ли использовать multicast (наверно уже по IPv6?) для синхронизации устройств внутри локальных сетей?
плюс в карму Яндекса за то что сознались сами, а не дождались пока тыкнут носом
P.S. Всё жду когда таки СДЭК выкатит своё подробное расследование летнего инцидента. Но наверно не дождусь..
Возможно, вероятность реакции будет больше, если в комментарии упомянуть @Marat25, представителя СДЭК. Тогда ему придёт уведомление.
про это уже неоднократно тыкалось носом, но ответа от яндекса так не было..
почему яндекс станция принимает опцию 42 с dhcp и работает с локальным ntp сервером, но при этом не прекращает спам на ntp в Интернете?
почему обращение к ntp серверам идёт с частотой в 90 секунд?
почему яндекс станция так же берёт на себя функции ntp relay для "других клиентов или станций?", за день в списке dst-address почти полсотни ip адресов провайдеров по всей РФ.
почему имея дома разношёрстный зоопарк умный устройств, проблемы вызывает лишь яндекс, впервые именно для яндекс станции пришлось создать правило фаервола разрешающие только трафик на yandex cloud и блокирующее всё остальное..
А как быть с их спамерским yandex.net, причём через его скрипты завязано протаскивание всевозможной рекламы с их rbt-yandex?
Причём они на него завязали и выдачу результатов поиска, то есть необходимо на шлюзах ставить прокси с анализаторами потока, чтобы всякие телевизоры и обычные браузеры избавить от Р-Е-К-Л-А-М-Ы!!!
я думаю эффективнее будет вот так:
Яндекс
Тыкнули носом в оригинальном посте раз 10.
Всё жду когда таки СДЭК выкатит своё подробное расследование летнего инцидента.
Тоже самое, и судя по плюсам - нас таких много)
Жалоб было мало, действующий регламент поддержки не был рассчитан на подобные ситуации, поэтому обращения рассматривали не в самом высоком приоритете.
Домашнее задание - подберите эквивалентное предложение из двух слов.
Положили весь рунет и это не самый высокий приоритет. А что тогда высокий? Майкрософт багу с апдейтом винды починила за 4 часа.
ну это уже не первый раз, если вспомнить, например, апдейтер яндекс диска, который делал rmdir C:\
Не самый высокий приоритет был когда редкие технические продвинутые пользователи попадали на первую линию поддержки и писали «а у меня что-то станция часто запросы делает, это ок?».
Из текста, когда багу всё-таки обнаружили, её почти сразу пофиксили (пока ещё не осознавая масштабы проблемы) и медленно выкатывали (релизный цикл видимо порядка недели), а когда на хабре написали про большой факап всея рунета и популярно объяснили масштаб беды, предприняли альтернативные, но более рискованные меры.
ИМХО, это вполне себе высокий приоритет — в воскресенье применять правку конфига катить на 100% устройств — учитывая что дождаться обычной выктаки фикса оставалось всего около трёх дней.
Я бы лично настаивал на том чтобы докатить по стандартному флоу и без доп.рисков, нежели тратить свой выходной на то чтобы найти и придумать альтернативу, собрать фикс, выкатить, а утром понедельника рисковать увидеть новости в духе «Алисы по всей России перестали показывать время, миллионы будильников не сработали». Чай ещё три дня ддоса погоды рунету не сделают.
Чай ещё три дня ддоса погоды рунету не сделают.
Действительно, а всего-то нужно было настроить пару тройку своих NTP серверов.
Проблема не в будильниках, и не в ддосе рунета, проблема что, кто-то вообще не следил за нагрузкой создаваемой Алисой на не свои сервисы.
Это не техническая проблема, а управленческая, причина называется максимизация прибыли минимизация убытков. Вот беда, всплыло там где не ждали, такая большая компания и не может позволить NTP сервера себе который может позволить любой админ, с интернет каналом 100 мегабит.
Есть более заметный и известный пример, когда прибыль компания забирает себе, а издержки (инфраструктура, страховые случаи) перекладывает на общество -- Самокаты яндекса
Действительно, а всего-то нужно было настроить пару тройку своих NTP серверов.
Вот тоже об этом подумал. Им наверняка ничего не стоит воткнуть по старенькому серваку в каждом дата-центре и пускай работают.
Да даже просто админу в офисе на любом приличном компе поставить какую-нибудь ubuntu server и подключить к свободному белому ip.
Не могу понять, в той статье предлагался способ поднять свой ntp сервер засчет покупки хостинга и развертывания нужного софта. Яндекс сам по сути предоставляет хостинговые услуги, и неужели не могли сами поднять ntp сервер по той инструкции?...
Да никто об этом не думал просто. Сделали когда-то давно, потом забыли, ведь работает - не трогай, всегда есть более приоритетные задачи. А тут вот оно напомнило о себе.
Но конечно, как обычно в комментарии набегают теперь тысячи умных людей с их послезнанием и "задним умом все крепки", и считают что все было очевидно и предсказуемо с самого начала, а все случившаяся исключительно злая воля яндекса.
Ну речь вообще не об этом шла. Ниже в комментах тоже недоумевают на этот же счет: когда стало ясно что сервера вылетают, то был поднят клич, чтобы спасти ситуацию и предлагалось вложиться баблом и помочь (пишут что таймвеб сделали это и поучаствовали своими серверами). В этот момент яндекс не захотели вложиться баблом, а пытались устранить свой же косяк. Меня просто это и смущает, ведь улучшить ситуацию на тот момент можно было бы по той инструкции про которую в самом начале статьи написали сами же яндекс
В качестве временного решения, можно было бы просто поднять NTP виртуалки в yandex.cloud. Timeweb это сделал в течение дня. Кстати, можете сказать им слова благодарности за то, что они "подставили плечо")
Яндекс в это время устранял причину проблемы, снижая тем самым нагрузку.
Как бы там ни было, если одним из итогов этого неприятного события станет то, что Яндекс полноценно войдет в пул, думаю данная "встряска" сделает зону RU гораздо более стабильной и защищенной от подобных инцидентов в будущем.
Яндекс в это время устранял причину проблемы, снижая тем самым нагрузку.
В яндексе далеко не одна команда. Исправление проблемы - это два действия:
1. Быстрое тушение огня, чтобы справиться с последствиями.
2. Исправление причин проблемы в спокойном режиме.
Если огонь быстро не потушить, то устранять причину придется в огне. Что, собственно, у них и получилось.
Можно было бы сделать простую вещь - пока одна команда работает над исправлением, попросить другую команду поднять 50 виртуалок с NTP серверами. Это бы не исправило причину проблемы, но разгрузило бы сервера в рунете. И можно спокойно работать над релизом. Виртуалки потом можно было бы потушить.
Но там сделали по другому. Пока NTP серверы рунета испытывали DDoS, там в мыле трудились над релизом и не тушили огонь. Они сами пишут об этом.
К 20 ноября мы нашли ошибку, внесли исправление в код и начали готовить новый релиз.
В выходные 23–24 ноября ситуация с NTP‑серверами обостряется: доступными остаются лишь четыре сервера.
Хотя задним умом - все гении. Но я не увидел в статье, что они об этом задумались.
Но я не увидел в статье, что они об этом задумались
Потому что эта статья – просто пиар. У Яндекса ясно видна тактика реагирования на такие инциденты: они признают что-либо только когда комьюнити основательно вываляло их в грязи, и каждый раз что-нибудь обещают. Ненапряжное и невозможное для контроля.
Типа «проведём работу с персоналом», «улучшим тесты», «развернём сервера» – новости из будущего, короче.
До очередной NTP-bomb, BIND4 и прочих...
Весь исходный код и протоколы TCP/IP (IPv4) и сопутствующих сервисов не предполагал, исходно, глобального распространения и какой-либо защиты, в лучшем случае от дурака, это просто обычный концепт, который стал основополагающим скелетом текущего состояния цивилизации.
Иногда временные решения носят такой разрушительный характер, что для их исправления требуется замена IT систем. (цитата с vc.ru)
Весь исходный код и протоколы TCP/IP (IPv4) и сопутствующих сервисов не предполагал, исходно, глобального распространения и какой-либо защиты, в лучшем случае от дурака, это просто обычный концепт, который стал основополагающим скелетом текущего состояния цивилизации.
Скорее предполагал другое состояние цивилизации.
Он не являлся временным, наоборот, большая заслуга авторов в том, что он смог продолжить работу в условиях, на которые не рассчитывался - т.е. дураков + бизнеса.
Что, не помогли алгособесы от ошибки, грохнувшей NTP сервера в рунете?
Но число генерируемых нами NTP‑запросов исторически никогда не входило в метрики
Большинство опытных разработчиков, которые работу работают, а не з*****т аглоритмы, знают, что метрики должны быть на все генерирующие трафик (читай все io операции) компоненты.
Поэтому мы запланировали выделить ресурсы в общий пул NTP‑серверов.
Ну тут плюс конечно. А еще свои метеостанции раскидайте по стране, так как ваша яндекс.погода тоже держится за счет станций сообщества.
P.S. Минусите карму, мне пофиг. Всем слабо высказаться и признать, а мне нет, устал уже от этого цирка.
метрики должны быть на все генерирующие трафик (читай все io операции) компоненты.
К слову, в статье есть график с подписью «динамика числа отправляемых колонками NTP-запросов». Вопрос тут в том, почему на него никто не обратил внимание, но в статье пишут что банально уведомления не были настроены.
Не понятно как получили график. Возможно нарисовали постфактум.
То что алерты не были настроены, к сожалению это распространенная проблема. И на это так же часто обращают внимание опытные разработчики, так как в работе уже сталкивались с отсутствием алертов.
В подкорке уже срабатывает звоночек - тут не плохо было бы повесить уведомление.
Я лично такие вопросы на каждом дейлике поднимаю и выделяю отдельное время на метрики и алерты (читай задача).
Совсем смешная ситуация когда на алерты не обращают внимание, потому что их много))) С таким тоже сталкивался.
Тестов нет
Уведомлений нет
Сервера заиспользовали чужие
Дежурной команды нет
@
Не прокатило
@
Мы многому научились, гайз
Кажется, это именно оно. Крупная компания заложилась в своём проекте на инфраструктуру, NTP серверов, поддерживаемую кем-то другим и сама не озаботилась вовремя о поддержке этой инфраструктуры.
Уже вспомнили предыдущее https://habr.com/ru/articles/434422/ там в итоге всё умерло, правда.
маленькая индикомания яндекс не смогла позволить купить себе пару штук ntp серверов, пришлось ддосить публичные
У меня роутер по DHCP отдает NTP сервер(опция 42), что мешает Вам внедрить в DHCP клиент станции. чтение и использование этой опции, в корпоративных сетях да и дома у многих своя страта s2 используйте NTP которые развернуты внутри локалок
Потом вы поставите на своем NTP сервере 27 ноября 2013 года, и спросите - "Алиса, курс доллара!". А она вам - "35". И будут претензии ). А ведь можно еще что-то и посерьезнее политически-дискредитирующее спросить!
Сервер не должен полагаться на время клиента
В таком случаи она просто замолкнет, тк SSL/TLS сертификаты имеют свое время жизни, Алиса ответит "ой, что то с интернетом" НО опять же возвращаясь к своей инфраструктуре, за ней в компаниях следят как и дома, по умолчанию опция 42 и NTP server в локалке не работает, его просто нет......
У меня из-за NTP сервера провайдера TOTP отвалился, пришлось переключаться.
Выдавал неправильное время.
То есть он разъехался на больше минуты и потерял связность с другими серверами?!
Да, причём недавно, но раньше инцидента, поэтому скорее всего не связано.
Тут региональный провайдер, может подняли когда-то для галочки и не следят.
Возможно, часовой пояс сбился
О, была у меня история. Сетка машин на 60, примерно. И kerberos. Как раз тогда в России отменили то-ли летнее, то-ли зимнее время. А обновления временных зон на клиентские машины не накатились.
Пользователи уже знают, что если время стоит сильно не правильно - пускать в систему не будет. Время поменялось, встало правильное по Гринвичу, но не правильное визуально. Пользователи его поменяли руками в биосе. ("Ну мало ли что случилось"). А потом были массовые вопли "нас не пускает, а время правильное!"
Добавлю причину почему обновления не накатились - потому что аккуратно перед выходом законопроекта о переходе на вечное зимнее время с вечного "летнего" закончился срок поддержки Windows XP :-)
Тоже мне проблема. 2021-ый год, обновляем SSL сертификат для сайта, сотрудник на удалёнке получает ошибку про неправильное время. Разборки показали, что все эти годы в компьютере стоял неверный часовой пояс, а чтобы время было правильное - часы сдвинуты на час назад. Ну и сертификат оказался в будущем. Удивились, что за столько лет у сотрудника оказалась первый раз подобная ситуация.
нормальная у вас там обстановка, пользователи в биос сами ходят..
это как замок на дверь крутой повесить и окно рядом открытое оставить
Ну университетская кафедра, чего вы хотели? Пароли по идее должны стоять, но стоят далеко не везде и не всегда (севшие батарейки, потом батарейку поменяли, пароль поставить забыли. Я бороться пытался, но квалифицированных рук тупо не хватало уже тогда). А на современных материнках, когда дежурного питания нет, батарейку высаживает довольно быстро. Это в сочетании с "всё должно быть полностью обесточено когда не используется" и самыми дешёвыми батарейками приводит к тому, что батарейки живут максимум год-полтора.
Средние пользователи естественно не ходят, но лаборантский состав ходил.
"Жалоб было мало, действующий регламент поддержки не был рассчитан на подобные ситуации, поэтому обращения рассматривали не в самом высоком приоритете." - ваш звонок очень важен нет для нас , пожалуйста, оставайтесь на линии....
Вспоминается мой недавний багрепорт одну сервису за который я деньги плачу вида: не встает на новом устройстве, пишет api-сервер недоступен, в логах adguard-home - запрос в серверу такому то а там nxdomain. Ответ на 90% состоит из описаний как поставить VPN (сервис в значительной мере ориентирован на Россию и блокируется Роскомнадзором, из сторов их турнули)(в письме было прямо указано что VPN на роутере стоит) в разные местах и единственное полезное - ссылка на бета-версию приложения, это помогло.
root cause не баг, отсутсвие тестов, выделенных серверов и тд, а писать свой NTP клиент при наличии как минимум 2 отлаженных опенсорсных.
Думаю все IOT-компании вокруг посмотрят на этот инцидент, сделают выводы и поймут... насколько же это круто иметь под рукой собственный ботнет.
«Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью»
А что, если это и есть злой умысел? Эвона как все бросились сервера и баги обсуждать. А вдруг РКН или нечто такое же попросило\заставило\подкупило Яшу как раз для того, чтобы проверить на прочность рунет? Зачем? Я не знаю, самое простое обьяснение - это как злодеи в фильмах, вот им обязательно людям делать пакости, день без злодеяний - зря прожитый. Только это не в фильмах а уже тут. Зачем холопам знать точное время? Еще сговорятся и соберутся, а это низя. А может быть, этой таинственной и злой организации как раз и нужен под рукой ботнет?
/теории_заговора_off
Благодаря ему на запрос пользователя отвечает только одна, ближайшая колонка, а не из соседней комнаты.
Вы сравниваете до какой колонки звук дошел быстрее, та и отвечает?
Тут вот в чем проблема, сообществу "ссут" в глаза прямо проясняют первых строк.
Поэтому мы запланировали выделить ресурсы в общий пул NTP‑серверов. Это займёт некоторое время, потому что наши дата‑центры удалены от основных точек обмена трафиком, а для NTP‑серверов RTT (Round Trip Time) это — ключевой фактор качества. Мы установим и запустим мощности на основных точках обмена трафиком.
@slavashel не подозреват что у меня домашний роутер который отдален, от М9 выдает stratum 2 точности, и 100 мегабит из 500 я отдаю в пул.
https://www.ntppool.org/a/vgdnet
Из его слов получается яндекс чуть бедней чем я так как не может себе позволить, настроить NTP и разместить их у себя, и продолжит пользоваться общесвенным пулом, без выделения зоны.
Объясните, пожалуйста, дилетанту: а почему бюджетные наручные часы уходят на несколько секунд в год, а эти ваши устройства (а также RTC в материнках практически любого производителя) требуют такой вот частой синхронизации? Какие-то [censored] Эффективные Манагеры ради экономии в 0.000001 бакса не дают Гениальным Инженеграм использовать [censored] кварцевые резонаторы?
Потому что у ваших часов одна функция: показывать время. И направлена она на удовлетворение 1 потребности 1 человека: владельца часов. А эти колонки не только музыка для пользователя. Это ещё источник рекламы, денег с рекламы, и огромный распределённый ботнет при желании. За одну ночь можно раскатать обновление с "новым функционалом" на весь зоопарк этих колонок. Вопросы о том "какой будет функционал" и "нужен ли он пользователю" - не ставятся в принципе. Как и вариант "отказаться от обновлений" вне рамках доступного. То есть пользователи приобретают за свои деньги девайс, который будет вести себя как захочет Яндекс. Если Яндекс захочет то отключит все колонки и они просто перестанут работать. А захочет - будет майнить на них биткойны, слушать и записывать окружение, шпионить, транслировать рекламу или координировать звуком окружающие устройства имеющие голосовое и звуковое управление, спамить в NTP или взламывать Пентагон... Да что угодно в общем, у пользователя только 2 доступных режима: вкл и выкл. И всё. Повлиять пользователю на прием "обновленного функционала" не предоставляется. Или пользуйтесь "как есть" или не пользуйтесь. И это не только колонки Яндекса имеют такую политику.
Это еще не все. Обратите внимание, эта махарайка обновляется удаленно. У нее значит, есть загрузчик, ОС, апдейтер и система защиты, которую можно взломать. В подобных поделках всегда множество дыр, пример: Apple. Данный прецедент с NTP показывает, что отлаживали систему ну так... по регламенту.
Это вам не микротики (в которых тоже дырки есть). В микротиках копается огромное количество специалистов по безопасности и вылизывают там все. Здесь не так.
Что это значит, друзья? А это значит, что у нас потенциальный ботнет чудовищного размера.
Что значит ЕСЛИ ЗАХОЧЕТ "слушать и записывать окружение, шпионить, транслировать рекламу". А сейчас этого нет???
Вы ответили не на мой вопрос. Повторяю: почему в той колонке (а также в материнках) часы такие неточные? Напоминаю, на матплатах компьютеров/серверов/ноутов/... как бы настоящие аппаратные часы с батарейкой.
Потому что это ведёт к удорожанию, которое ощутимо при большой партии. Я помню как мне рассказывали, что некоторые фирмы не ставят защиту от переполюсовки на прибор за несколько миллионов ради экономии. Так что я вообще не удивлён.
Плюс, точности rtc, и уж тем более кварца, для позиционирования источника звука не хватит. Нужно синхронизироваться скажем, раз в полчаса (обычно этого достаточно), тут, видимо для большей точности, поставили 5 минут.
Ну и ещё, у алисы под капотом довольно небольшая плата, по размеру сопоставимая со смартфоном (именно со смартфоном, а не его платой). Причём на этой плате разведено сразу всё, от проца до усилителей, поэтому всё лишнее там исключено. Если разводку делали инженеры Яндекса, мне ничего не остаётся кроме как похвалить их за добротную работу.
Если разводку делали инженеры Яндекса, мне ничего не остаётся кроме как похвалить их за добротную работу
Вот тут Яндекс хвалился https://habr.com/ru/companies/yandex/articles/584214/
Пришлось перестраивать работу на ходу и разрабатывать ревизии, то есть варианты устройства с альтернативным набором компонентов. Казалось бы, здесь нет ничего сложного, но наш процесс разработки подразумевает тщательное тестирование выбранных деталей.
А тут как сложно было сделать станции подсветку - это очень важно :) https://habr.com/ru/companies/yandex/articles/668660/
Стандартной для кварцевых часов является точность в пределах ±20 секунд в месяц, а лучшие из наручных кварцевых часов показывают результат ± 5 секунд в год.
Я думаю что у часов компа точность примерно такая-же, что там что там недорогой "кварц". Как выше отметили - у часов "показывать время" это основная задача и всё-таки подстраивать руками всё равно приходится. У рядового десктопа точность кварца и хода часов не так критична т.к. автоматически подстроить проще. Ну и прям миллисекундная точность на компах не нужна, просто процесс синхронизации довольно простой, поэтому скорее тут руководствуются мыслью "чё бы не подсчитать drift и не стабилизироваться?"
Обычные компьютерные часы уходят где-то на миллисекунду в час. Это и есть несколько секунд за год. Инженеры Яндекса, очевидно, не в курсе.
Да бросьте, объяснили же про алгоритм контрактивации.
Скорость звука в воздухе при н.у. примерно 345 м/с. Разница в 1 м (типичное внутрикомнатное расстояние) во времени прихода голоса на 2 разных устройства составит примерно 3 мс.
Типичная точность хода потребительских RTC составляет, навскидку, 10ppm. Таким образом, эти 3 мс рассинхронизации набегают за примерно 5 минут. Всё вроде складно.
Можно было бы, кстати, не полагаться на публичную инфраструктуру ntp-пула. А вместо этого синхронизировать смещения часов колонок друг относительно друга. И для этого даже не придётся в интернет ходить, т.к. раположенные в одном помещении устройства скорее всего будут подключены к одному общему сегменту локалки. Это даже точнее будет и можно не стесняться и синхронизироваться до микросекундной точности, а это уже позволит различать дистанцию с миллиметровой точностью :-)
Думаю, ваше первое предположение о триангуляции звука через ntp неработоспособно. Я бы точно не стал забиваться на то, что два произвольных сервера из пула в любой момент дадут показания времени, совпадающие с точностью до 3 мс.
Это не так работает. Было здесь занимательное чтиво про синхронизацию времени, дедушку Калмана и прочие свистелки-перделки, придуманные сумрачными инженерами.
Если резюмировать, то да, каждая пара показаний от двух наугад выбранных ntp-серверов действительно не будет совпадать с требуемой точностью. Но если применить сумрачные технологии, то всё получится с любой наперёд заданной точностью, но не точнее хода локальных часов.
во времени прихода голоса на 2 разных устройства составит примерно 3 мс
С публичного NTP-пула разбег точности времени будет сопоставимым. Да и речь не об этом, а о кварце когда NTP недоступен.
Так я и возражаю против этого тезиса.
Когда NTP недоступен, кварц перестаёт давать приемлемую точность примерно через 5 минут. Ну или через час, если поставить крутой кварц. Ну или через пол дня, если это будет 0.1ppm с термокомпенсаций.
NTP всё равно нужен.
У колонок же есть связь между собой. Они же в одной локалке находятся? Ну нашли друг-друга, увязались вместе и синхронизируются. В чём проблема-то?
Такая синхронизация имеет разные edge кейсы, которые пришлось бы прорабатывать, имея на руках только абстрактные жалобы от пользователей, и не имея возможности посмотреть непосредственно на объекте, что произошло.
Например, колонки подключены к разным роутерам, или на роутере включена изоляция wireless клиентов, или в локалке есть какие-то ограничения по мультикасту.
Логично, что в яндексе решили не париться.
Например, колонки подключены к разным роутерам, или на роутере включена изоляция wireless клиентов, или в локалке есть какие-то ограничения по мультикасту.
Это как раз проверяется просто - спросили сервер - видит ли он ещё колонки в этой локалке на этом аккаунте и попробовали синхронизироваться/связаться. Не смогли - ну значит не судьба, будем отдельно.
Не нужен, достаточно разумного протокола (немного модифицированного SNTP), по которому эти две станции обменяются сообщениями о событии и вычислят текущее расхождение часов между ними.
кварц перестаёт давать приемлемую точность примерно через 5 минут
Точность у кварца особо не меняется и нам не очень важна – мы её можем программно компенсировать в разумных пределах опираясь на NTP например. Тут стабильность важнее.
У НИСТа есть отчётик про наручные часы из 2008, там даже для дешманских детских часиков кратковременная стабильность 10^-8. Так что имхо хватит больше чем на 5 минут даже без термостата.
Так что NTP и с кварцем всё равно нужен, но вряд ли раз в 5 минут.
Типичная точность хода потребительских RTC составляет, навскидку, 10ppm
Это паспортная типовая, в реальности там всё сложнее. На неё накладывается ещё пуллинг (уход частоты из-за неточного согласования нагрузочной ёмкости — а оно всегда неточное, если вы прецизионной подгонкой не занимались), потом ещё уход по температуре (а если мы берём умную колонку, то у неё довольно большой диапазон реальных рабочих температур из-за нагрева при работе на большой громкости)...
Но в целом 10 ppm можно брать за значение, примерно в которое вы с кварцем с паспортными 10 ppm и попадёте.
Я возможно дурак и чего-то не понимаю, но с какой целью кто-то будет ставить две умных колонки в одной комнате, и настолько близко друг к другу, чтобы понадобилось прям такое точное позиционирование источника звука? Мне как-то казалось что обычный сценарий использования когда они стоят все же на расстоянии побольше метра, и наверное можно тупо по децибелам определять к какой колонке пользователь обращается, не? Зачем яндекс вообще начал городить вычисление через скорость звука, я правда не понимаю.
Можно было бы, кстати, не полагаться на публичную инфраструктуру ntp-пула. А вместо этого синхронизировать смещения часов колонок друг относительно друга.
Для этого даже специальный отдельный протокол придуман: PTP - Precision Time Protocol
Обычно на порядок-два больше. Миллисекунда в час - это 0.3 ppm. Среднестатические кварцы - 5-20 ppm.
Разные компьютеры ведут себя по разному. Отклонение часов в том числе может зависеть от нагрузки или специфики использования (сервер терминалов например). Аварийное отключение также может привести к более значительным скачкам (в своей практике сталкивался с 40 секундами и более).
Заявленная точность ширпотребных кварцевых часов "±15 seconds a month" (на примере Casio G-Shock).
О_о на "электронике" и то в ГОД уходило время максимум на 3 секунды. И то, достаточно было раз или два задать корректировку (уже забыл как, но помню что не слишком сложно, нужно только определить в какую сторону и насколько ушли показания от эталона в течение какого-то интервала, и часы сами потом корректировали свой ход).
В статье это объясняется, на точное время завязана например, функция определения того, какой из ваших умных колонок надлежит ответить на ваш голос.
Ну и криптография тоже завязана на время: попробуйте на компьютере открутить время на недельку взад, а потом зайти на Хабр. Как раз недавно одному пользователю я исправлял последствия его, пользователя, просчёта с синхронизацией времени: этот феерический человек загнал свой роутер в замкнутый круг "в качестве DNS-сервера на роутере указан локальный адрес, недоступный, пока не поднят VPN-туннель; туннель после перезагрузки роутера не поднимается из-за сбитого времени; время невозможно синхронизировать, так как без рабочего DNS не удаётся отрезолвить домен NTP-сервера" - ну и всё, приплыли.
Ну для криптографии плюс минус пара секунд не роляет. А вот для всяких стереопар и мультирумов сотня миллисекунд уже будет заметна
Почти на порядок жёстче требования на самом деле.
В кино допустимый разбег между картинкой и звуком порядка 35 мс. В аудио между двумя каналами — надо где-то вдвое меньше, чтобы не начали появляться заметные на слух «псевдостереоэффекты».
где-то тут Яндекс уже писал что стереопары находят друг друга и синхронизируются друг с другом по отдельному ими разработанному протоколу.
Для криптографии в сети (TLS), кроме времени когда сертификаты меняются - даже неделя не очень критична.
Для kerberos-а - да, нужна точность порядка ±5 минут в разные стороны. (точнее - не более 10 минут разницы между сервером и клиентами). Это с настройками по умолчанию.
Для TOTP - интервал обновления ключа порядка минуты, но по идее правильная реализация будет проверять соседние интервалы тоже.
В ваших часах есть батарейка, от которой они и работают, у них нет других вариантов, кроме как иметь точное время автономно. На материнских платах есть батарейка (когда-то давно раньше - аккумулятор), от которой будут работать часы на них даже если компьютер полностью обесточен, что при обычном сценарии использования бывает редко. И есть дополнительно источник дежурного напряжения относительно приличной мощности, но это уже другая история. Пока синхронизация времени через интернет не была массово доступной, был смысл ставить более точные кварцы (даже с подстройкой частоты попадались, а ещё "гробики" от Dallas со встроенной батарейкой были хороши, пока она не кончится и не понадобится пилить чтобы подключить внешнюю). Сейчас, мне кажется, производители не заморачиваются проверкой - проблема не будет заметной у большинства пользователей, даже если время уйдёт, NTP его поправит. Но это в мире ПК, где совместимость и традиции. В мире интернета вещей всё не так (Буква S в аббревиатуре IoT обозначает безопасность). Во множестве устройств IoT никакой батарейки для часов (или отдельных часов для режима микропотребления) нет совсем, они запускаются с какой-то дефолтной датой, и полностью зависят от наличия сети и NTP - без них точного времени не будет, неоткуда взять. Потому что батарейка неудобна в пайке, и на больших тиражах это будет заметно, потому что устройство без доступа к сети не имеет смысла и неработоспособно, потому, что точное время не нужно устройству, потому что производитель не захотел тратить на это время и ещё 100500 причин. Такая же штука и с Яндекс - станциями, там нет батарейки - с одной стороны, нечего менять и нечему дохнуть со временем, с другой - без сети времени не будет, совсем. Именно поэтому, только загрузившись, станция начинает активно это время синхронизировать. Может быть в самой большой, с экраном, что-то есть, не смотрел, а в Max и более маленьких - нету. И не факт, что надо.
Может быть в самой большой, с экраном, что-то есть, не смотрел, а в Max и более маленьких - нету
Выделенный RTC есть в колонках с Zigbee, он питается от ионистора с запасом на пару суток. Но это не для точности счёта времени, а для быстрого его восстановления при перезагрузке (в т.ч. после отключения света), чтобы у вас завязанный на Zigbee умный дом продолжал корректно сценарии отрабатывать.
Для точности счёта выделенный RTC не очень нужен, центральный процессор вполне себе справляется, причём по большей части аппаратно (его основной кварц → делитель → счётчик). Уход времени у него сравнимый с RTC с 10 ppm кристаллом.
Потому что батарейка неудобна в пайке, и на больших тиражах это будет заметно, потому что устройство без доступа к сети не имеет смысла и неработоспособно, потому, что точное время не нужно устройству, потому что производитель не захотел тратить на это время и ещё 100500 причин.
Уже лет 20 есть ионисторы. По характеристикам - среднее между батарейкой и конденсатором. Паяются как конденсатор. Ёмкости для поддержания работы часов хватит минимум на неделю-другую после выключения. Скорее всего больше, мне лень считать (там ёмкости порядка единиц фарад).
Типичный хороший часовой кварц имеет паспортную погрешность ±10 ppm (кварц чуть проще — ±20 ppm, кварц заметно дороже — ±5 ppm; если вам надо ещё точнее, это уже не кварцы, а радикально более дорогие готовые генераторы). Это при 25 °С. Поверх этого есть дрейф по температуре и дрейф по нагрузочной ёмкости (т.н. «пуллинг» — pulling), которая в свою очередь есть некая комбинация из паразитной ёмкости дорожек платы, паразитной ёмкости входов чипа и паспортной ёмкости нагрузочных конденсаторов (у которых тоже есть погрешность).
Влияние каждого из этих паразитных факторов — до единиц ppm.
10 ppm — это 0,864 секунды в сутки, 26 секунд в месяц, больше 5 минут в год.
Более высокую точность гарантированно имеют только очень небюджетные часы, в которых много сил и денег было вложено в получение погрешности порядка 1 ppm. Если вы такую точность получаете в бюджетных часах — вам очень повезло с конкретным экземпляром.
Граждане помнят советские часы "Электроника" на дряных советских кварцах, но с цифровой подстройкой хода, которые давали точность 3-5 секунд за год. Для достижения этой точности их нужно было настроить по паспорту и потом ещё стараться всегда носить на руке чтобы у них не плавала сильно температура в течении этого времени
Удивительно что такая опция, казалось бы, фактически бесплатная в кремнии (размажется на больших тиражах) - но вроде как и не встречается в часах зарубежных фирм.
Вот сейчас подумалось, ведь есть часы с автоматической радиоподстройкой времени. Такую подгонку можно было вообще сделать автоматической. Хотя наверное в таких часах это не особенно что-то меняет. Ну, может, снизить регулярность автоподстройки…
Потому что там у них кварцы такой точности были, что не было смысла напрягать потребителя каким-то выставлением погрешности в скрытом меню
Сейчас все смартчасы, по факту, являются с автоподстройкой от часов сматртелефона.
Были часы, которые синхронизировались по радио на 433Мгц от адаптера на ПК
Сейчас все смартчасы, по факту, являются с автоподстройкой от часов сматртелефона.
Это не то, речь про частичную компенсацию ухода ущербных кварцев силами микросхем в часах. А так, есть и не очень «смарт» часы с блютуз, подстраивающие своё время с помощью смартфона. Даже у тех же Casio
Были часы, которые синхронизировались по радио на 433Мгц от адаптера на ПК
Есть и «не смарт» подстраивающиеся от радиовышек, те же Casio их маркируют как Multiband и wave ceptor. Без всяких адаптеров дома. Но эта рация опция применима не везде
Там, наверно, всё-таки такой точности не было. "Сигналы точного времени" по радио передавали, я с них цифровую подстройку корректировал. Вот сейчас беру время через интернет, так оказалось, что сигналы по радио несколько менее точны. Я, когда срочную во флоте служил, по правилам должен был бегать с секундомером для установки часов на катере в соответствии с заданными параметрами, так почти сразу стал по своим часам "Электроника" (с ЦПХ) устанавливать, только перед проверкой всё же время проверял. И сейчас у меня есть реле с ЦПХ (вырубает питание в случае задымления и некоторых потребителей в случае отклонений питающего напряжения, но не это важно), так я так же, как на "Электронике" действую: не корректирую время, а корректирую в том или ином направлении подстройку. Точное время беру своим скриптом со сторонних серверов. Если правильно помню, он должен по onload страницы синхронизироваться только.
Была, проверял лично
У меня такие рассуждения: насколько помню, точность ЦПХ задавалась до одной десятой в сутки. Тогда получается, что в стационарных условиях по всем остальным параметрам (чего, конечно же нет на практике) уход за 10 дней может составлять до одной секунды, или, если возьмём средний уход за год (а здесь, наверно, подходом дискретной математики всё же можно воспользоваться), то порядка ±18 секунд. То есть ваш результат лучше, чем в среднем по выборке. Вам повезло. Но, может, кто-то поправит, если я где в рассуждениях ошибся.
Вот сейчас беру время через интернет, так оказалось, что сигналы по радио несколько менее точны.
Потому что сейчас радио идёт в цифре. Кодировка-раскодировка-буферизация и прощай точность.
PS На Сочи-Автодроме смотрел Формулу-1 и хотел с телефона в наушнике слушать комментарий Попова через интернет вещание. Задержка была больше одного круга, около двух минут.
У наручных часов условия лучше - колебания температуры меньше
А синхронизация и проверка времени и параметров между колонками в одной локальной сети будет работать, дополнительно? А также синхронизация со смартфоном пользователя/роутером/Яндекс_ТВ_Станцией, при недоступности внешних источников?
Спасибо.
Где-то на хабре видел статью про то, как яндекс станция ntp-спамом ложила роутер у человека на работе, почему проблема не была решена еще тогда?
Наверное потому, что такие одиночные случаи всегда в низком приоритете, и всегда есть более важные задачи. Блин, ну все задающие такие вопросы как дети, прямо слово. Вы будто никогда не работали в компаниях и проектах больше чем на пару человек, где все очень медленно, огромный бесконечный бэклог с проблемами, менеджеры при этом постоянно накидывают срочные новые бизнесовые фичи, и до проблем какой-то пары гиков у команды руки дойдут примерно никогда. Пока вот гром не грянет.
Это сейчас очевидно что проблема была серьезная, а тогда было не очевидно. Мелкий перерасход трафика у пары человек, отложим на запланированный через пять лет крупный рефакторинг сетевого стека, а пока давай-давай новую рекламу прикручивай (или чем там колонка занимается, не в курсе, принципиально против подобных устройств).
Но число генерируемых нами NTP‑запросов исторически никогда не входило в метрики, требующие валидации
Как-то неубедительно звучит. IoT-устройство при тестировании подключается к сети через монитор трафика. Монитор создает отчет о всех типах запросов которые генерирует устройство в течении суток. Отчет сравнивается с отчетом по предыдущей версии прошивки. По отчету сразу должно быть видно что структура запросов изменилась по сравнению с предыдущей прошивкой. Сложно проглядеть что частота каких-то запросов в новой прошивке резко выросла.
Вопрос к знатокам:
Никогда не заморачивался мануалами, добавил alias синхронизации времени и.
Код:
┌─[user@DH]─[~]
└──╼❕sudo ntpdate ntp0.ntp-servers.net
27 Nov 12:22:28 ntpdate[9664]: adjust time server 195.186.4.100 offset -0.322929 sec
┌─[user@DH]─[~]
└──╼❕sudo ntpdate ntp0.ntp-servers.net
27 Nov 12:26:06 ntpdate[9732]: adjust time server 185.175.56.95 offset -0.221902 sec
┌─[user@DH]─[~]
└──╼❕sudo ntpdate ntp0.ntp-servers.net
27 Nov 12:26:43 ntpdate[9822]: adjust time server 217.14.146.53 offset -0.208654 sec
┌─[user@DH]─[~]
└──╼❕sudo ntpdate ntp0.ntp-servers.net
27 Nov 12:29:42 ntpdate[9986]: adjust time server 80.50.102.206 offset -0.140448 sec
┌─[user@DH]─[~]
└──╼❕sudo ntpdate ntp0.ntp-servers.net
27 Nov 12:29:53 ntpdate[10007]: adjust time server 62.173.141.123 offset -0.134949 sec
┌─[user@DH]─[~]
└──╼❕sudo ntpdate ntp0.ntp-servers.net
27 Nov 12:30:05 ntpdate[10027]: adjust time server 192.33.214.47 offset -0.122601 secТакая синхронизация времени с разбросом - это нормально?
Об инциденте с NTP-серверами