Как мы мигрировали в облако… пепла
Ваня, привет! У меня хорошая и плохая новость, как у вас говорят. Мы нашу миграцию в облако, похоже, сегодня закончим.
Такой вот звонок ко мне пришел от нашего VP of Engineering Виктора около 7 вечера 9 марта прошлого года. Дело в том, что Виктор знает русский, но никогда не жил в России, поэтому он часто добавляет «как у вас говорят» или какие-то другие только ему ведомые присказки, поговорки и пословицы. Но сейчас не об этом.
Прошел уже почти год и у меня наконец-то хватило духа написать всю историю целиком, ничего не приукрашая и не выкидывая слова из песни. Надеюсь, что эта правда поможет читателю делать лучше и учиться на наших ошибках.
7 часов вечера по Калифорнии — это такое редкое время, когда Москва еще не проснулась, а наши уже закончили и можно отдохнуть. На тот момент у нас еще не было команды в Томске и я с 7 до 10–11 вечера обычно отдыхал. Но не 10 марта. И вообще не в марте. Честно говоря, слабо помню как выглядел март прошлого года после 10 го числа. И апрель тоже. Время немного ускорили той весной и потом отпустили уже летом.
Мы мигрировали в облако пепла. Переезд окончен
10 марта (00:47 по времени Франции и 9 марта вечером у меня по Калифорнии) у OVH в Старсбурге сгорел датацентр. Точнее два дата центра, если контейнерные вагончики вообще можно было называть отдельными строениями. До этого момента я знал про Стартбург только то, что он находит во Франции на границе с Германией и то, что там есть суд по правам человека, в который подают жалобы политзаключенные и прочие несправедливо пострадавшие люди. Но в этот день я еще узнал, что у нас там стоят сервера в датацентре и что он горит.
На тот момент, у меня были примерно такие мифы в голове:
Пожар скоро потушат
Наш продукт (фаервол) продолжит работать, просто клиенты не смогут зайти в личный кабинет
У нас есть бэкапы, мы все восстановим
Из этих утверждений НИ ОДНО не оказалось в целиком правдой. Но чтобы дальше было интересно и понятно читать, следует дать краткую справку про Валарм:
Мы продаем фаервол для API и приложений, который работает как модуль Ingress/Nginx/Envoy, анализирует трафик и кладет результаты анализа (вредоносные запросы) в облако
Клиенты ходят в облако смотреть UX и по API забирать их в PagerDuty, Slack, etc
У нас три облака, и Европа, которая горела в OVH, самая старая по инфре
Штатовское облако уже все на кубе, оно в GCP, но оно новое. Поэтому первые большие штатовские клиенты сидели в Европе
А теперь по порядку по всем перечисленным мифам.
Миф #1. Пожар скоро потушат
Первое сообщение говорило, что пожар возник в одной из комнат одного ДЦ, SBG2 и ничего страшного не предвещало беды. Пожары случаются и в ДЦ есть системы пожаротушения.
Через пару часов уже было понятно, что все плохо, и датацентр потерян, то есть сгорел целиком. При этом пожар перекинулся на соседний контейнер, который назывался SBG-1 и половину его тоже пожег.
Вот такой текст опубликовал СЕО OVH Октаве в своем твиттере:
We have a major incident on SBG2. The fire declared in the building. Firefighters were immediately on the scene but could not control the fire in SBG2. The whole site has been isolated which impacts all services in SGB1–4. We recommend to activate your Disaster Recovery Plan.
Самое прикольно, что летом 2019-го года, мы с ним обедали в Сан-Франциско и мило общались. Октаве тогда рассказывал какие у них большие планы по развитию и выходу на биржу. А мне стоило бы тогда подарить ему наш фирменный огнетушитель…
Миф #2. Наш продукт продолжит работать
Это было почти правдой, но не для всех клиентов. Мы продаем софт, он работает в инфраструктуре клиента и никак не зависит от наших облаков, одно из которых сгорело во Франции. Но это не совсем так. Дело в том, что при старте в кубе, каждый новый стартующий под обращается по API к облаку и регистрируется там. Без этого он не запускается. Причем тестами был покрыт случай, когда облако отваливается при уже запущенном сервисе, но вот сам старт не был покрыт.
То есть мы были в ситуации, когда через какое-то время все кубернетис клиенты Европы перестали бы работать. Более того, у них просто перестал бы ходить трафик, пока наш модуль не был бы выключен из ингресса. Наш софт стоит в разрыв (inline).
Проблема решалась заглушкой, которая отдает JSON, что все при регистрации пода без каких-либо проверок. Затем эту часть мы полностью отрефакторили и сделали нормально, теперь ингрес стартует, даже если облако недоступно.
Миф #3. Восстановим все из бэкапов
В двух словах, бэкапы были в том же датацентре. Когда мы брали выделенные сервера, мы хотели, чтобы они были рядом, чтобы внутренняя связность была лучше (по легенде). Ну или просто не смотрели где нам давали сервера (по второй легенде).
Как бы там ни было, бэкапы точно стоило хранить отдельно и в облаке. И теперь мы так делаем.
Восстанавливать в итоге пришлось по логам, старым и кусочным бэкапам на машинах людей, а также методом декомпиляции клиентских правил. И об этом расскажу чуть подробнее.
Ломаем сами себя
Итак, у нас сгорели бэкапы вместе с тем, от чего они собственно и были :)
Условно все данные в нашем облаке можно поделить на три типа:
Клиентские события фаервола (условно логи атак) — они вообще не пострадали, потому что они жили отдельно в Riak тогда (мы перешли на S3, и не советуем никому мертвый Riak)
Учетки клиентов и API ключи от их инстансов продукта (в самом плохом случае можно просто скинуть все коючи и пароли)
Правила фаерволов, уникальные для каждого клиента. У нас это называется ЛОМ — Локальное Обучающее Множество (да, сами придумали) — самое критичное, потому что система тренируется и правила дописываются постоянно, чтобы не было ложных срабатываний
Все остальное. Журналы, настройки, графики и проч-проч-проч. Потеря этого не приведет к ухудшению качества сервиса работы самого фаервола
Тут стоит рассказать про наши правила, которые ЛОМ. Дело в том, что они попадают на клиента не в том же самом виде, в котором храняться в облаке, а в компилированном. Это необходимо для ускорения работы фаервола (мы должны обрабатывать даже очень большие JSON запросы к апишкам почти без задержки, за счет использования ЦПУ и памяти). Поэтому правила компилируются из описаний во что-то типа дерева принятия решений (пример, теория автоматов) и уже в таком виде летят на клиента. Поэтому если просто взять правила с клиентов, их не получиться положить в облако обратно так, чтобы потом можно было их дополнять и пользоваться.
Идея сделать декомпилятор для правил появилась практически сразу, и в итоге была реализована. Таким образом, мы немного ломали сами себя, запросил у клиентов компилированные файлы с настроенными под них правилами ЛОМ и раскомпилировав заливали обратно в наше облако. Мы не могли просто начать обучение клиентов с нуля, так как продукт работает в режиме блокировки, а в правих храняться настройки по предотвращению ложных срабатываний и структура API приложений клиентов. Этот проект был успешно выполнен, и с минимальными потерями мы подняли правила.
Поддержка от клиентов
Забегая вперед скажу — мы НЕ ПОТЕРЯЛИ НИ ОДНОГО КЛИЕНТА из-за этого инцидента. Не смотря на то, что все складывалось совсем не в нашу пользу с самого начала. Более того, мы получили не только слова поддержки от тех, кто платит нам за поддержку, но и реальную помощь в виде файлов ЛОМ, про которые писал выше. Главное — мы почувствовали понимание, и настоящую любовь от клиентов, которую сложно оценить и описать словами.
Хотел бы поблагодарить всех еще раз, это было очень душевно.
Написал CEO Google Cloud и он ответил
Мы решили брать Google Cloud в Европе для поднятия там новой Европы. Но у нас не было менеджера во Франции, только в США. Гугл — не самая простая компания для коммуникации и тикеты обрабатывает не очень быстро.
В итоге просто решил написать на самый верх на удачу и кинул письмо в Thomas Kurian CEO Google Cloud с темой »URGENT: GCP Account Manager is missing in the middle crisis». Он ответил через 3 (!!!) минуты и решил проблему с менеджером. В тот момент надо было все делать быстро и это на удивление сработало.
Памятные сувениры и премии
По итогам инцидента, мы выплатили всем участникам (пожарникам) премии, которые разбили на категории в зависимости от вклада в устранения последствий и бессонных ночей. А чтобы добавить немного юмора, выпустили также серию вот таких мемовых собак This is fine. На каждой из которых обозначена категория «пожарника», который ее получил.
Советы
Не храните бэкапы в том же ДЦ, что и данные
Делайте вторичное резервное копирование данных, представляющую основную ценность, в облаках
Делайте бэкап кубернетис-мастера
Делайте ежегодные «учения» и симулируйте какие части системы отвалятся в каких случаях, особенно, если у вас много компонент софта в разных местах
Не бойтесь рассказывать актуальные и честные статусы клиентам, они помогут и поддержат
Выводы
Мы живем в мире, где в датацентре может случиться пожар из-за одного источника бесперебойного питания и спалить 2 здания. Проектирование, пожаротушение, изоляция — никаких гарантий, что это сработает. Надейтесь только на себя и на свою команду. И перестраховывайте риски этой надежды проверенными поставщиками (подсказка, мы теперь проверены).
Спасибо нашим клиентам и нашим командам: поддержке, на которую упала вся коммуникация и все нервы с передовой, девопс за супер адекватные действия по устранению инцидента и супер быстрому поднятию нового облака Европы, разработке за декомпилятор правил и помощь всеми силами программистов, детекту, всем кого забыл, и, конечно, Виктору за координацию процесса и disaster recovery plan, который был готов до пожара. У меня просто нет слов, чтобы выразить признательность всем, кто помогал и участвовал в этом проекте. Спасибо!
Пользуясь случаем, хотел бы пригласить работать к нам в Валарм, мы можем нанимать где угодно на удаленку и помочь с переездом тем, кто хочет жить в Европе. Мы классные. Пишите на jobs@wallarm.com (особенно ищем сильных продуктов, devops, ruby/go/C).
