Привет! Я Паша Ковальчук, системный администратор AGIMA.

Воскресенье, 11 октября. Я просыпаюсь в четыре утра от того, что у меня разрывается телефон. Коллеги сообщают: прод лёг. Уже тогда я понял, что ночь будет веселой. К восьми утра портал снова работал — прод на двух ядрах вместо восьми и за фильтром, который я собрал на ходу. Ниже — как это было по шагам, где мы чуть не встряли и что я советую сделать заранее всем, чтобы облегчить себе жизнь.

Инфраструктура

Речь пойдёт о крупном портале, который мы сопровождаем. Клиент важный. Около 1,5 млн запросов в сутки, операционная система — Astra Linux, хостинг — Yandex Cloud.

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

Схема у нас была такая. Трафик шёл через Smart Web Security — WAF Яндекса — затем Traffic Inspector Next Generation и дальше на сервер. DNS-записи тоже были в Яндексе. Бэкапы — 14 штук разной глубины — тоже хранились в Яндексе. 

В начале октября Yandex Cloud начал терять дата-центры. 8 октября остановилась площадка в Сасово, а вместе с ней зона ru-central1-b. Наш прод жил в другой зоне и продолжал работать.

За два дня до: полезная паранойя

После Сасово у меня включилась паранойя. Я участвовал в нашем проекте с самого начала, многие архитектурные решения принимал сам и хорошо понимал: если умрёт нода с продом, у нас не останется ничего — ни прода, ни бэкапов. Написал коллегам: нужна рабочая копия прода вне Яндекса, и нужна сейчас.

Тут начались первые сюрпризы. Скачать бэкап или образ диска напрямую не получилось — готовой кнопки для этого мы не нашли. До этого момента нам просто не приходилось срочно забирать что-то из облака.

Но теперь нам было нужно, поэтому мы начали искать решение. Оно нашлось, а коллеги из Яндекса подтвердили работоспособность схемы и посоветовали её же. Делюсь ниже.

Как выгрузить бэкап из Yandex Cloud:

1. Создать в Yandex Cloud маленькую ВМ на свободных мощностях.

2. Сделать образ с работающего прода.

3. Подключить этот образ к новой ВМ вторым диском.

4. Зайти на ВМ по SSH и забрать данные.

Так я вытащил около 300 ГБ. Можно было сложить данные куда угодно и успокоиться, но мне нужна была не просто копия, а рабочая копия. С Astra Linux это особенно важно: у неё мандатное разграничение доступа и свои особенности, которые стоит учитывать. Я хотел точно знать, что машина запустится и прод на ней заработает в любом другом месте.

Поэтому сконвертировал выгруженные данные из RAW в образ виртуальной машины и поднял его у нас, в инфраструктуре AGIMA. Система грузилась очень долго, но загрузилась. Только без сети, сеть куда-то делась.

Причину нашли не сразу: Yandex Cloud сам настраивает сеть на виртуалках через cloud-init. За пределами Яндекса эта настройка не срабатывает, и машина остаётся без сети. Поправил руками — и получил рабочую копию прода. Тогда казалось, что мы застрахованы.

04:00. Доброе утро

В ночь на воскресенье остановился дата-центр во Владимире — и наш прод вместе с ним. Когда меня разбудили, то первая мысль была примерно такой: ничего страшного, копия есть, сейчас просто переключу трафик.

Вторая мысль: а куда переключу? Трафик шёл через Smart Web Security и Traffic Inspector Next Generation (TING). WAF лежал вместе со всем остальным, а TING был виртуалкой на той же ноде, что и прод, и умер вместе с ним.

Третья: даже если поднять копию где-то ещё, нужно поменять запись в DNS... как вы уже догадываетесь, тоже от Яндекса. Захожу, проверяю — Service Unavailable. Доброе утро, так сказать.

С DNS оставалось только ждать и верить, поэтому я занялся остальным. Был потенциальный вариант пустить продовый трафик в нашу инфраструктуру на развернутую из бэкапа виртуалку, но ресурсы там ограничены, и открывать прод без фильтрации нельзя. К тому же копии уже на тот момент было двое суток. Так что я начал искать другое решение.

05:00. Когда два лучше восьми

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

Зато уцелел свежий снимок прода, который я сделал прямо перед сном в ночь аварии. Как потом выяснилось, снимки в Yandex Cloud хранятся отдельно от дисков и реплицируются между зонами доступности, поэтому авария их не задела.

Решил, что два ядра лучше, чем ничего. Создал из снимка ВМ — грузилась долго, но поднялась.

Успели мы, похоже, одними из последних. На эти мощности побежали все, и вскоре создавать там что-то стало нельзя: Yandex Cloud приостановил выдачу дополнительных квот.

06:00. Свой WAF за одну ночь

Прод живой, но открыть его в интернет без защиты нельзя — сразу налетят боты. Здесь Яндекс повёл себя очень честно по отношению к клиентам: с первых дней сам советовал разворачиваться на альтернативных площадках, а 9 октября договорился с Selectel, K2Cloud и VK Cloud, чтобы те помогли пострадавшим с переездом.

Процесс согласований у нас был сложный, но быстрый, спасибо ИБ. План получился такой: маленькая ВМ-прокси в Selectel, за ней — двухъядерный прод в Яндексе.

Поднял ВМ, написал конфиг, бэкендом указал виртуалку с продом. Прежде чем трогать DNS, проверил схему у себя: прописал домен портала в hosts на своём компьютере. Сайт открылся через прокси — схема работает.

Дальше — защита, по слоям:

• iptables. Для всех открыты только 80 и 443. Остальные порты — только для нескольких IP-адресов AGIMA. Это сразу сильно сужает поверхность атаки.

• OpenResty. По сути это nginx плюс Lua: на Lua удобно писать собственные правила фильтрации трафика.

• ipset для чёрных списков. Адресов ботнетов набралось около 15 000. Если загрузить столько правил в iptables напрямую, он начнёт тормозить, а ipset нормально переваривает такой объем.

• Скрипт обновления. Забирает адреса ботнетов и вредоносов из открытых списков, которые ведёт сообщество, складывает их в ipset.

Получилась фильтрация на минималках, но фильтрация.

07:00–08:00. Прод работает

К этому времени ожил и DNS в Яндексе. Чудо свершилось. Я поменял запись, пустил трафик и попросил коллег все проверить. Оба сайта открывались. Реакция в чате была примерно такой: «Как так, половина интернета лежит, а у нас всё работает?». Что тут сказать — вот так. Да, появилась пара новых седых волос, но в целом даже было интересно. Правда, на этом все не кончилось.

Воскресенье. Тюнинг на живом трафике

Больше всего я боялся за сам прокси. Прод принимает трафик только с его адреса, поэтому в обход фильтра к нему не попасть, но всё, что прокси пропустит, ляжет на два ядра. А запросов было много, ботов — тоже.

Следующие часы я провёл с двумя окнами. В одном — логи в реальном времени, в другом — конфиг OpenResty. Админку на прокси сразу закрыл для всех, кроме адресов AGIMA, по логам отделял человеческий трафик от ботов и дописывал правила. Готового рецепта тут нет: это ручная работа на опыте. Но в итоге легитимный трафик проходил, а два ядра справлялись с нагрузкой.

Спустя несколько дней

Пока прод держался на двух ядрах в Яндексе, мы подняли из внешней копии второй прод в Selectel на восьми ядрах, синхронизировали данные между серверами и пустили трафик уже на новый прод.

Другим проектам пришлось тяжелее. Там, где не было копии вне Яндекса или снимка, системы собирали в Selectel практически вручную, заново. Эта работа идёт до сих пор. Но паники нет: все понимают, что делают и к какому результату идут.

Как застраховаться от падений дата-центров

1. Храните бэкапы у другого провайдера. У нас было 14 бэкапов, и все в Яндексе. Снимки пережили аварию — они реплицируются между зонами доступности. Но поднять прод из снимка удалось только потому, что мы успели урвать квоту. Не успели бы — выручила бы только внешняя копия. Держите хотя бы одну копию у себя или у другого провайдера — лучше на хранилище, которое можно физически отключить.

2. Нельзя поставить агент бэкапа — используйте скрипты. Например, в некоторых госпроектах на виртуалку часто нельзя поставить сторонний софт вроде Veeam. Тогда стоит придумать другую схему: ежедневный дамп базы в отдельную папку, ночью rsync забирает дамп, файлы и конфиги на внешнюю площадку.

3. Проверяйте копию за пределами облака. Образ из облака может не взлететь в другом контуре. У нас мешал cloud-init, у вас может мешать что-то ещё. Узнать это лучше заранее, а не в четыре утра.

4. Помните, что облачные WAF и DNS — тоже точки отказа. Если периметр и DNS живут у того же провайдера, что и прод, в случае сбоя переключаться будет некуда. DNS лучше держать где-то еще.

5. Держите под рукой всё для переезда: сертификаты, доступы к другой площадке, заготовку конфига прокси. Ночью без этого теряются часы.

6. Начали падать соседние зоны — забирайте данные и занимайте мощности сразу. Во время массовой аварии свободные мощности разбирают за часы. Мы успели взять два ядра одними из последних.

7. Держите тёплый резерв у другого провайдера. Нам пришлось собирать его на ходу, после аварии. Лучше сделать это до неё.

Главный совет — не про технологии

Не паниковать. Пока прод не спасён, голова не может думать ни о чём другом: мозг плохо держит две глобальные задачи одновременно. Поэтому порядок такой: сначала забрать данные — в любом виде и куда угодно. Потом убедиться, что они поднимаются. И только потом думать о трафике, DNS и защите. Как только данные у вас, думать становится заметно легче.

И не верьте комментариям в духе «из Яндекса бэкапы не забрать — всё». Решения почти всегда есть. Они бывают неочевидными, но обычно лежат на поверхности.

Отдельно хочу сказать про Яндекс. У меня была одна бессонная ночь — у их команды недели работы в режиме, который сложно даже представить. И всё это время они честно сообщали клиентам о ситуации, первыми подсказывали, куда переезжать, и помогали с переездом. Я уверен, что Яндекс справится и станет ещё сильнее. Коллеги, мы с вами.

Подписывайтесь на канал моего коллеги и ИИ-амбассадора — СТО AGIMA, Андрея Непряхина. И заходите на сайт AGIMA, стараемся работать для вас.