![image](https://habrastorage.org/webt/ba/lm/yt/balmyts5_3sbkpzgwptikjgokyi.jpeg)
Возможно, вы ждали, что мы затолкаем этот косяк под ковёр, как и следовало бы сделать обычному хостинг-провайдеру. Но я обещал рассказать подробнее о причинах простоя.
Итак, оператор связи в дата-центре М9 запланировал техработы с 23:00 4 июля до часу ночи 5 июля по Москве. Предварительно — им нужно было обслужить и при необходимости поменять коммутатор уровня ядра плюс провести ещё ряд сопутствующих работ. Обещали до 2 часов без связи. Для нас это считается простоем (несмотря на то, что виртуальные машины работают и некоторые VDS-хостинги не рассматривают ситуацию без отключения сервера как простой) — мы оповестили своих клиентов, чьи ВМ физически были размещены в этом ЦОДе.
Примерно под конец планового времени простоя дата-центр сообщил про продление работ до 06:00 5 июля, то есть ещё на 5 часов. Уведомить об этом продлении в адекватное время мы не успели, потому что в этот момент как раз и закрутилась история.
▍ Что вам надо знать про автономную систему для анонса сети
Фактически оператор связи поменял систему, откуда шёл анонс наших сетей в М9.
За несколько месяцев до этого из-за ужесточения всех регуляторных политик Роскомнадзора и санкционного давления на международного оператора связи (магистрального уровня) они, магистральщики, потребовали от нас заменить систему анонсирования со своей на нашу, чтобы вот эти российские IP-адреса не имели никакого отношения к их оборудованию.
Если что, анонс сетей — это идентификатор, кому принадлежит IP. Что-то вроде ИНН организации, только идентификатор сети. Идентификатор начинается на AS — автономная система, дальше набор цифр. Когда вы вбиваете свой айпишник на сервисе проверки IP и получаете название своего оператора — это как раз по IP устанавливается AS, а из него уже устанавливается, чья это сеть.
До этого времени магистральщики анонсировали сети со своих автономных систем. Если кто-то на что-то жаловался, то абуза просто пересылалась нам, мы реагировали. Физически на администрирование адресов это никак не влияло. После замены автономной системы, условно, был один адрес в реквизитах, стал другой.
Мы зарегистрировали автономную систему, это очень просто, примерно как поцеловать гадюку. Это некая новая сущность, которую надо админить и подавать отчёты в тот же РКН. Но взяли в работу, бесшовно заменили, и никто переключения не заметил — собственно, так и должно быть.
Что важно, в этот момент в RIPE NCC добавляется новая запись, а старая не затирается. Если всё работает хорошо, используется прайм-запись, если прайм не отвечает — используется старая. Далее, когда всё штатно работает, уже убирается старая. В районе марта мы убрали из RIPE старую, и осталась только актуальная (на самом деле не везде: есть 4 сети, где без согласия владельца арендованного IP нельзя удалять AS, только добавлять — но их мы со временем заменим). И всё работало штатно.
▍ Возвращаемся в вечер 4 июля в M9
Итак, меняется железо, откуда физически отправляется анонс сетей. На момент техработ мы уже давно бесшовно сделали смену анонса, и актуальные данные по принадлежности сетей есть в двух базах — государственной РАНР и RIPE, которые совпадают с реальностью. Это важно, потому что для оборудования ТСПУ данные РАНР — основные. Если вдруг анонсы идут не так, как указано в РАНР, налицо подмена сети и трафик в ней блокируется.
Оператор менял коммутационное оборудование и наступил на те же грабли, на которые уже один раз наступали всем Рунетом.
Но детали мы узнали немного позже. Сначала у нас просто всё поднялось и заработало задолго до заявленного конца техработ. Потом, когда техработы закончились, трафик ещё некоторое время лился, чего хватило ровно на то, чтобы отметить, что опасный период пройден. А потом у нас вдруг отвалился трафик с площадки. Точнее, с серверов, расположенных на M9.
На самом деле всё чуть хитрее. Часть трафика отвалилась ещё до конца техработ, ночью. Админы ВМ, то есть наши клиенты, писали про это тикеты, а наши админы поддержки, соответственно, со спокойной душой их закрывали со словами «так техработы у провайдера же». Потом техработы кончились, а проблемы сохранились. Тамошние админы закрыли техработы и пошли спать. К моменту, когда они уснули, мы подняли ещё одну смену и вместе поняли, что работы закрыли как-то криво.
Около 6 утра мы висели на линии с админами ЦОДа и работниками магистральщиков. Но те админы, которые всё сделали, уже спали, следующие нормальные спецы просыпались в 10 утра, а те, что были на месте, имели полномочия только перезагрузить. Причём примерно полчаса ушло на диалоги в духе:
— Алло, пожарная! У нас напротив красный кирпичный дом горит!
— Да? А у нас тоже напротив такой же, и он не горит.
В итоге включили и выключили они несколько раз, это не помогло. В общем, если вам говорят про поддержку 24/7, помните, что иногда тикет начинается с побудки админа, который не 24/7.
Сначала мы грешили на кривой коммутатор. По симптомам это была аппаратная ошибка, и буквально недавно мы с такой же сталкивались. Почему мы так думали — потому что трафик терялся не из всех сетей. 4 подсети работали отлично и как ни в чём не бывало.
Железо включено, всё работает. До серверов можно по iBMC достучаться.
В это же время у нас в телеграм-канале начали появляться комментарии с разными невероятными версиями, которые вывели из себя дежурного админа, и так разогретого беседой со специалистами ЦОДа, и он успел пару раз не очень приятно для нас ответить. Эти комментарии до сих пор под постом, никто ничего не удалял, но объяснить пару вещей пришлось. Если вам хочется ответить резко — лучше разбудить меня или кого-то ещё из бизнеса. Вообще, кстати, меня не будили, считая, что это чисто техническая проблема — и, наверное, зря.
По трассировкам удалось понять, что же именно происходит — оборудование ТСПУ РКН дропало наш трафик. Стали думать, что проблемы там — потому что, повторяю, дропался не весь трафик, 4 сетки ходили без проблем. Но отключить трафик от ТСПУ нельзя, у нас и доступа к нему нет, да и оператор связи не имеет на это права.
Наконец, поняли, что же случилось. В общем, сотрудники оператора сменили старый коммутатор в нашей зоне и накатили не текущие конфиги, а из бекапа примерно полугодовой давности. Почему — это большой вопрос, на который от оператора до сих пор нет ответа. Сказали, человеческий фактор, ошибка админа.
В старом конфиге был старый анонс и старые данные по AS. Дальше оборудование ТСПУ увидело, что трафик автономки не совпадает с их базами, и нам начали резать трафик, потому что явно же какие-то мошенники. По правилам ТСПУ, при таком несоответствии попытка соединения есть, а трафик никуда не идёт, ничего не работает.
Примерно так же было в феврале, только в больших масштабах. До сбоя в Рунете не тот конфиг залили на коммутаторы.
Дальше возник вопрос — что делать быстрее. Можно в RIPE внести старую автономную систему, но растекание до новых анонсов от 2 часов до 2 суток. Либо срочно менять обратно конфиг на новом коммутаторе. В итоге приехал главный инженер этого оператора связи, как только поняли, что случилось, оперативно сделал. От 10 до 30 минут на разных подсетях анонсы разлились на правильную автономку, и всё заработало.
▍ Осталось понять, что же было с теми 4 подсетями, которые работали
Тут сработал другой человеческий фактор.
Как я уже рассказывал, при смене AS при добавлении новой системы она становится прайм, а старая — вторичной. Потом старая удаляется. Так как сети в аренде, какие-то владельцы дают доступ поменять эти данные, какие-то нет и делают это сами. В целом старую можно и оставить, но правило хорошего тона — написать в RIPE и попросить убрать ненужные упоминания автономных систем. На большинстве систем так и было сделано в марте. Так как арендуем мы у разных личностей, где-то изменения идут оперативно, где дают сделать самим, где-то месяцами. На четырех подсетях не убрали старые автономки, то есть ТСПУ видели, что они актуальные, одна из автономок соответствовала. Чтобы вы понимали, почему анонсы не убрали, просто объясню, что конечные владельцы одной из сетей — иностранцы. Они сидят и не хотят менять — работает, не трогайте. У нас они были в плане на замену всех 256 адресов, но заменить не успели.
В итоге вредность владельцев сетей привела к тому, что эта сеть работала и осложнила нам постановку диагноза по другим. В остальных трёх плюс-минус такая же история.
▍ Итого
На ряде машин даунтайм по сети был 7 часов. По тем машинам, где даунтайм вышел за пределы технических работ дата-центра, мы выплатили компенсацию согласно нашему sla.
Интересно, что в ЦОД входит два разных луча только этого провайдера двумя независимыми маршрутами: один из европейской части РФ, второй с восточной части страны. Физически это как будто два разных оператора в одном. Это независимые инфраструктуры в рамках одного глобального оператора. Но ТСПУ у всех операторов связи одинаковые. Через кого пакеты — всё фиолетово. Так что концепция критической инфраструктуры устаревает, я как раз недавно написал статью в Forbes про то, куда смещается сегодня ландшафт рисков.
На всякий случай, если у вас ценная инфраструктура, берите машины в двух геораспределённых ЦОДах или провайдерах, как советует Амазон. Потому что даже у них регулярно подобное происходит. Может ли такой сбой повториться — да, может, и легко.
С провайдера до сих пор компенсацию мы не получили, хотя заявили сумму ущерба эквивалентную тому, что мы заплатили.
Никто, кроме нас, с тех пор про этот сбой ничего не опубликовал.
Telegram-канал со скидками, розыгрышами призов и новостями IT ?
![](https://habrastorage.org/webt/tp/sk/z-/tpskz-7w7a8e74isoowuep40xeg.png)
Комментарии (24)
vanxant
15.08.2024 07:10+23TL;DR: админы залили в железку протухший на полгода конфиг и ушли спать:)
А статья интересная, спасибо!
Erop22
15.08.2024 07:10+7Респект и уважуха, что тут сказать.. Косякнули, починили, компенсировали согласно прейскуранту, отчитались с тех. подробностями. Браво! Почаще бы так относились к ошибкам!
JHD
15.08.2024 07:10+8Ностальгично. ТСПУ -1 в карму. Жаль только ответственные за тспу его kpi не в карме считают.
ifap
15.08.2024 07:10+4ТСПУ увидело, что трафик автономки не совпадает с их базами, и нам начали резать трафик, потому что явно же какие-то мошенники
А автоматически уведомить владельца сетки об инциденте - у него лапки?
mayorovp
15.08.2024 07:10+1Да ладно бы просто уведомить, кто вообще придумал в случае кривых анонсов резать трафик, а не эти кривые анонсы?
lightman
15.08.2024 07:10Но отключить трафик от ТСПУ нельзя, у нас и доступа к нему нет, да и оператор связи не имеет на это права.
Вот кстати на фоне замедления ютуба я пару раз видел комментарии от людей "мы в своём городе так задолбали техподдержку провайдера жалобами на медленный ютуб, что он сдался и отключил замедление".
Интересно, возможно ли это?
vvzvlad
15.08.2024 07:10+1Провайдеру потом от РКН прилететь может
lightman
15.08.2024 07:10Т.е. технически он всё-таки может отключить ТСПУ или пустить свой трафик в обход его?
lorc
15.08.2024 07:10Ну оно ж стоит на площадке провайдера. Так что технически - может.
lightman
15.08.2024 07:10Просто "у нас и доступа к нему нет" из поста прозвучало так, будто физического доступа нет. Живо представилось, что ТСПУ стоит в отдельной комнате, на двери висит амбарный замок и рядом строгий дедушка-охранник.
lorc
15.08.2024 07:10+1Я так понимаю, что для операторов санкции за обход ТСПУ такие, что уж лучше бы дедушка-охранник с берданкой стоял.
s0lgryn
15.08.2024 07:10+2У провайдера нет возможности поменять конфиги или вообще хоть какие то настройки ТСПУ, но пустить траффик в обход он может. Когда работал в ТП крупного провайдера у нас офисная сетка ходила мимо ТСПУ, всякие инстаграмы фейсбуки открывались без ВПН
v0rdych
15.08.2024 07:10+1так в данном случае тспу стоит в цоде у «магистрала» для хостинга. у них доступа скорее всего и правда нет.
CQ17
15.08.2024 07:10VVV
KA
GD GLD
Пост-фактум, действительно выглядит, ну очень - очень весело,
а в реальности: отсутствие штатного уровневнего взаимодействия при подобных: "стечение обстоятельств", явно чья-то недоработка плана восстановления из актуальной резервной копии, которая в трёх экземплярах, минимум, должна была храниться у всех участников "возможного инцидента", до всех описанных событий, после изменений.
Почему у оперативного персонала "под рукой" оказалась такая не актуальная резервная копия (?),
после внесения изменений, фактически в "продакшн" (?);
Проверка процедуры восстановления из крайней-актуальной резервной копии
входит в обязательные штатные мероприятия, при планировании процедур восстановления.
Админы?
Разумеется, люди.
Первое Админское правило: сделай резервную копию перед внесением любых изменений.(!);
Очевидно, поскольку источник проблемы не был локализован,
Админы и откатились на "пылящуюся в архиве" древнюю,
снятую до внесения актуальных крайних изменений;
Вполне штатный отклик: трезво,
по-админски (!);
Ну, и классика "жанра": 2N+1, -
на всё что 999;
А "запасной" рояль в кустах,
с хранения, так и не понадобился...
Очень - очень впечатляющий кейс;
73
EE
CQ17
15.08.2024 07:10Старая Пара: Номер AS + старый блок IP адресов, - в старой резервной копии, снятой до описанных событий;
-
Новая Пара: Номер AS + новый блок IP адресов, - в действующей конфигурации.
Не распределённый блок IP-адресов, выделенный для AS, сконцентрированный у одного провайдера, -
Единая точка отказа (!).
Нет анонсов с интерфейса маршрутизатора (оборудование провайдера) в сторону магистралей, через какое-то время никто не знает куда "перенаправлять траффик" предназначенный для актуального блока IP-адресов.
Динамика.
В котором месте отвалилось можно узнать обычной трассировкой по известным IP-адресам нового блока. Да и доступность старого блока тоже можно проверить, чтобы оценить масштаб происходящего.
А дальше ?
Проверять работу того устройства которое выдаёт с интерфейса анонсы. Что с ним происходит.
Автор рассказал, что провайдер заменил коммутатор уровня ядра
( неуправляемый switch у провайдера ?)
Или управляемый коммутатор: агрегация-распределение, а это минимум L2+ или полноценный L3, со своей таблицей маршрутизации
и наверняка "горячим" резервированием-дублированием.
В общем, тоже "кусок работы".
В чьей компетенции функции:
ядро и распределение,
из описания не слишком ясно изложено, могут быть не только разные индивиды, но и целые команды, а у них единоначалие: технический директор, главный инженер и т.д.
Если выход из подобной ситуации "сработал" исключительно на организационном уровне "Топ-Топ", значит нет соответствующих полномочий-процедур у технических специалистов дежурной смены в Центре Управления Сетью (?);
Человеку всегда нужен Человек.
Опять же "откат" на не актуальную резервную копию со старой связкой выдачи анонса "номер AS + блок IP адресов" никого не спас, пока не возникла требуемая компетенция в виде ведущего специалиста (?);
В общем вывод:
Изменения в действующую конфигурацию внесены, а плановые штатные процедуры на случай возможного-вероятного отказа обновления не получили.
По чьей инициативе процедура, со всеми последующими?
Остаточный риск присутствует всегда.
Одна хорошая вспышка на Солнце
и всё что не в свинцовой оболочке "хандрит".
Два провайдера, блок адресов для AS с сегментацией, плюс резерв, - это НОРМА: необходимое и достаточное, минимум;
Админы действовали штатно, в пределах своей компетенции: взяли резервную копию и вернули в продакшн "нулевой отсчёт".
Третья сторона, в виде специальной железяки, как правило работает в прозрачном режиме, но если, что записанный траффик можно приложить при разборе инцидента.
По Действующей НОРМЕ так.
А каков ПРЕЦЕДЕНТ?
73
EE
tcinott
15.08.2024 07:10+1У вас один аплинк?
ОДИН АПЛИНК????
Два независимых ввода? Ахахах, тракторист смеётся вам в лицо!
Работы на сети аплинка и у вас недоступны ВСЕ виртуалки клиентов, т.к. работы на сети аплинка??
Как вы вообще сущуствуете на рынке?
Andruh
15.08.2024 07:10А как же "интернет - это децентрализованная, самоорганизующаяся сеть, способная пережить любые размыкания графа, в том числе ядерную войну"?...
Наше время: залили вронг бекап, правильный админ спал...
subTimer
15.08.2024 07:10inet всё может пережить, если бы не РКН ... и даже его , только сложнее будет ...
gvfnk
15.08.2024 07:10+1Автоматизируйте тесты - запрашивайте таблицу свотх анонсов у аплинка и сверяйте с оргиналом, если есть расхождения бейте в колокол.
Mike-M
15.08.2024 07:10человеческий фактор, ошибка админа
Это не ошибка. Это наступившая эпоха всеобщей безответственности.
MountainGoat
Как говорил мой дедушка Ирико: "ни разу не обосрался тот, кто с рождения не ел"