Как Мы Мигрировали В Облако... Пепла

Ваня, здравствуй! Как вы говорите, у меня есть хорошие и плохие новости.

Похоже, сегодня мы завершим миграцию в облако.

Это звонок, который я получил от нашего вице-президента по инженерным вопросам Виктора около 19:00 9 марта прошлого года.

Дело в том, что Виктор знает русский язык, но никогда не жил в России, поэтому часто добавляет «как здесь говорят» или какие-то другие известные только ему поговорки, поговорки и пословицы.

Но сейчас не об этом.

Прошел почти год и я наконец набрался смелости написать всю историю, ничего не приукрашивая и не убирая слов из песни.

Я надеюсь, что эта истина поможет читателю добиться большего и учиться на наших ошибках.

7 часов вечера по калифорнийскому времени – это такое редкое время, когда Москва еще не проснулась, а наши уже закончили и мы можем отдохнуть.

На тот момент у нас в Томске еще не было команды и я обычно отдыхал с 7 до 10-11 вечера.

Но не 10 марта.

И совсем не в марте.

Честно говоря, я почти не помню, как выглядел март прошлого года после 10-го числа.

И апрель тоже.

Той весной время было немного ускорено, а затем выпущено летом.



Мы мигрировали в облако пепла.

Переезд окончен

10 марта (00:47 по французскому времени и 9 марта вечером в Калифорнии) Дата-центр OVH в Старсбурге сгорел.

Точнее, два дата-центра, если вообще контейнеровозы можно назвать отдельными зданиями.

До этого момента я знал о Стартбурге только то, что он находится во Франции на границе с Германией и что там есть суд по правам человека, в который подают жалобы политзаключенные и другие несправедливо пострадавшие люди.

Но в тот день я также узнал, что у нас там, в дата-центре, стоят серверы и что он горит. На тот момент у меня в голове были примерно следующие мифы:

  1. Пожар скоро будет потушен
  2. Наш продукт (фаервол) продолжит работать, клиенты просто не смогут зайти в личный кабинет
  3. У нас есть резервные копии, мы все восстановим
Из этих заявлений НИ ОДИН не оказался полностью правдой .

Но чтобы дальнейшее чтение было интересным и понятным, следует дать краткую информацию о Валарме:

  1. Продаем межсетевой экран для API и приложений, который работает как модуль Ingress/Nginx/Envoy, анализирует трафик и сохраняет результаты анализа (вредоносные запросы) в облаке.

  2. Клиенты отправляются в облако, чтобы просмотреть UX, и используют API, чтобы получить их в PagerDuty, Slack и т. д.
  3. У нас три облака, а Европа, которая сгорела в ОВХ, самая старая в инфракрасном диапазоне.

  4. Облако США уже есть в кубе, оно есть в GCP, но оно новое.

    Поэтому первые крупные клиенты из США оказались в Европе.

А теперь по порядку обо всех перечисленных мифах.



Миф №1. Пожар скоро будет потушен

В первом сообщении говорилось, что пожар произошел в одной из комнат одного ДЦ, СБГ2, и ничего страшного не предвещает беды.

Бывают пожары, в РЦ имеются системы пожаротушения.

Через пару часов уже было понятно, что все плохо, и дата-центр потерян, то есть сгорел полностью.

При этом огонь перекинулся на соседний контейнер, который назывался СБГ-1, и также сгорела его половина.

Это текст, опубликованный генеральным директором OVH Октавом в своем Twitter:

У нас серьезный инцидент на SBG2. Пожар объявлен в здании.

Пожарные немедленно прибыли на место происшествия, но не смогли справиться с возгоранием в СБГ2. Весь сайт изолирован, что влияет на все службы в SGB1–4. Мы рекомендуем активировать план аварийного восстановления.

Самое крутое, что летом 2019 года мы с ним пообедали в Сан-Франциско и мило пообщались.

Затем Октав рассказал нам, какие большие планы у них по развитию и выходу на биржу.

А то надо было ему дать наш фирменный огнетушитель.



Миф №2. Наш продукт продолжит работать

Это было почти верно, но не для всех клиентов.

Мы продаем ПО, оно работает на инфраструктуре клиента и никак не зависит от наших облаков, одно из которых сгорело во Франции.

Но это не так.

Дело в том, что при запуске в кубе каждый новый стартовый под обращается к облаку через API и регистрируется там.

Без этого оно не запустится.

Причем тестами был охвачен случай, когда облако отваливается при уже работающем сервисе, но не был охвачен сам запуск.

То есть мы попали в ситуацию, когда через какое-то время все клиенты Kubernetis в Европе перестанут работать.

Более того, их трафик просто перестанет идти до тех пор, пока наш модуль не будет отключен от входа.

Наше программное обеспечение встроено.

Проблему решила заглушка, возвращающая JSON, и всё это при регистрации пода без каких-либо проверок.

Потом мы эту часть полностью рефакторили и сделали нормально, теперь ингресс запускается даже если облако недоступно.



Миф №3. Восстановим всё из резервных копий

Короче говоря, резервные копии находились в одном дата-центре.

Когда мы брали выделенные сервера, мы хотели, чтобы они были рядом, чтобы внутренняя связь была лучше (по легенде).

Ну или просто не посмотрели, откуда нам отдали сервера (по второй легенде).

Как бы то ни было, резервные копии точно должны были храниться отдельно и в облаке.

И теперь мы делаем это.

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

И об этом я расскажу немного подробнее.



Мы ломаем себя

Итак, наши резервные копии сгорели вместе с тем, от чего они были:) Условно все данные в нашем облаке можно разделить на три типа:
  1. События клиентского фаервола (условно логи атак) - на них вообще не повлияло, т.к.

    они тогда жили отдельно в Riak (мы перешли на S3, и никому не рекомендуем мертвый Riak)

  2. Учетные записи клиентов и ключи API для их экземпляров продукта (в худшем случае можно просто сбросить все учетные записи и пароли)
  3. Правила брандмауэра уникальны для каждого клиента.

    Мы называем его LOM — Local Training Set (да, мы его сами придумали) — самый критичный, потому что система обучается и правила постоянно добавляются, чтобы не было ложных срабатываний.

  4. Все остальные.

    Логи, настройки, графики и т.д и т.п.

    Потеря этого не приведет к ухудшению качества обслуживания самого фаервола.

Здесь стоит поговорить о наших правилах, которые являются СКРАП.

Дело в том, что они доходят до клиента не в том виде, в котором хранятся в облаке, а в скомпилированном виде.

Это необходимо для ускорения работы межсетевого экрана (мы должны обрабатывать даже очень большие JSON-запросы к API практически без задержки из-за использования процессора и памяти).

Поэтому правила компилируются из описаний в нечто вроде дерева решений (например, теория автоматов) и в таком виде летят к клиенту.

Поэтому, если вы просто возьмете правила у клиентов, вы не сможете поместить их обратно в облако, чтобы потом дополнять и использовать.

Идея сделать декомпилятор правил возникла практически сразу и в итоге была реализована.

Таким образом, мы немного сломали себя, запросили у клиентов скомпилированные файлы с настроенными для них LOM-правилами и после декомпиляции загрузили их обратно в наше облако.

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

Этот проект был успешно завершен, и мы подняли правила с минимальными потерями.



Служба поддержки

Забегая вперед, скажу – мы МЫ НЕ ПОТЕРЯЛИ НИ ОДНОГО КЛИЕНТА из-за этого инцидента.

Несмотря на то, что с самого начала всё было не в нашу пользу.

Более того, мы получили не только слова поддержки от тех, кто нам платит за поддержку, но и реальную помощь в виде LOM-файлов, о которых я писал выше.

Главное, что мы почувствовали понимание и настоящую любовь со стороны клиентов, которую сложно оценить и описать словами.

Хочу еще раз всех поблагодарить, это было очень искренне.



Написал генеральному директору Google Cloud и он ответил

Мы решили использовать Google Cloud в Европе, чтобы построить там новую Европу.

Но у нас не было менеджера во Франции, только в США.

Google — не самая простая в общении компания, и она не очень быстро обрабатывает заявки.

В итоге я просто решил написать в самый верх на удачу и закинул письмо в Томас Куриан Генеральный директор Google Cloud с темой « СРОЧНО: менеджер по работе с клиентами GCP пропал в разгар кризиса Он ответил в течение 3 (!!!) минут и решил проблему с менеджером.

На тот момент все нужно было сделать быстро и на удивление сработало.



Памятные сувениры и награды



Как мы мигрировали в облако.
</p><p>
.
</p><p>
.
</p><p>
 пепла

По итогам происшествия мы выплатили всем участникам (пожарным) премии, которые были разделены на категории в зависимости от их вклада в ликвидацию последствий и бессонных ночей.

А чтобы добавить немного юмора, еще выпустили серию мемов с собаками вот так Это отлично .

На каждом из них указана категория «пожарный», получивший его.



Совет

  1. Не храните резервные копии в том же DC, что и данные.

  2. Резервное копирование основных данных в облаках
  3. Сделайте резервную копию мастера Kubernetis.
  4. Делайте ежегодные «учения» и моделируйте, какие части системы в каких случаях отвалятся, особенно если у вас много программных компонентов в разных местах.

  5. Не бойтесь рассказывать клиентам актуальные и честные статусы, они помогут и поддержат.


выводы

Мы живем в мире, где из-за одного источника бесперебойного питания в дата-центре может возникнуть пожар и сгореть 2 здания.

Проектирование, пожаротушение, изоляция – никакой гарантии, что все будет работать.

Надейтесь только на себя и свою команду.

И перестраховать риски этой надежды у проверенных провайдеров (подсказка, мы теперь проверены).

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

У меня просто нет слов, чтобы выразить благодарность всем, кто помогал и участвовал в этом проекте.

Спасибо! Пользуясь случаем, хочу пригласить вас работать с нами в Валарм, мы можем нанимать куда угодно удаленно и помогать с переездом тем, кто хочет жить в Европе.

Мы крутые.

Пишите на [email protected] (особенно ищем сильные продукты, devops, Ruby/go/C).

Теги: #информационная безопасность #Резервное копирование #Kubernetes #DevOps #sla #OVH #fire #backup #disaster Recovery #ovhcloud #burned out #kubertenes
Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.