Пожар в OVH, героическое восстановление, неожиданные неприятности и тревожные планы на ближайшее будущее.
Пожар в OVH
10 марта 2021 года случилась чрезвычайная ситуация — пожар в крупнейшем в Европе и третьем по величине в мире дата-центре (ДЦ). Огонь полностью уничтожил один и вывел из строя еще три ДЦ (один из которых так и не удалось впоследствии восстановить) компании OVH в городе Страсбург, Франция. В тушении участвовало 115 пожарных и 44 единицы техники. К счастью, обошлось без человеческих жертв, но не всех потерявших свои данные или получивших простой в бизнесе это утешает.
Пожар в OVH по подсчетам экспертов отправил в офлайн более 3’6 млн сайтов и парализовал работу правительственных организаций и множества компаний. Среди пострадавших специализированные государственные ресурсы Франции, Великобритании и Польши, аэропорт Страсбурга, телекоммуникационная компания AFR-IX, криптовалютная биржа Deribit, разработчик шифровальной утилиты VeraCrypt, Центр Искусства Жоржа Помпиду, новостной портал eeNews Europe, компания по интернет-безопасности Bad Packets и многие другие, в т.ч. Платформа ABCP.
Не все из пострадавших смогли быстро восстановиться. К примеру разработчик онлайн-игры Rust безвозвратно потерял 25 серверов с активной версией игры и бэкапом, хранившимся там же, а это вся европейская ветка игры. Второй пример — Webasyst, платформа, где по информации на сайте работают 13’000+ интернет-магазинов. Разработчики Webasyst также хранили бэкапы в Страсбурге, но, к счастью для них, на уцелевших серверах, поэтому платформа восстановилась. Потребовалось больше 2 недель до первого запуска и вот ещё 2+ недели продолжается отладка.
Причины пожара в OVH
Хотя риск пожаров в ДЦ является первоочередным, для всей индустрии случай в OVH грянул как гром. Последний раз пожар такого масштаба был в ДЦ другого бренда в 2012 году. С тех пор стандарты изменились, ДЦ обязали иметь системы сверхраннего обнаружения пожара и длинный перечень других мер по пожарной безопасности.
OVH славится новаторской смелостью и высокотехнологичным подходом в своей деятельности. К примеру выгоревшее здание SBG2, площадью 500 кв.м., было построено в 2011 году и оснащено инновационной системой естественного воздушного охлаждения, обеспечивающей экологичность и энергоэффективность. Некоторые эксперты высказали опасения, что именно эта система и стала причиной масштабности пожара, конструкция сооружения превратилась в “дымоход” и способствовала усилению огня. Само же возгорание, по словам СЕО OVH, Октава Клаба, началось с источника бесперебойного питания, который на днях до пожара проходил плановую проверку. Но это пока догадки, официального заключения нет, расследованием занимаются полиция и страховщики.
В 2017 году OVH сталкивался с неприятной ситуацией с полным отключением трех ДЦ на 2 часа. Тогда причиной послужили неполадки с электросетью, вызванные замыканием и выходом из строя источников питания. После происшествия Октав Клаба заявил, что OVH станут “еще более параноидальными, чем сейчас” и предпримут кардинальные меры и многомиллионные вложения по совершенствованию систем безопасности и электропитания.
В тот момент мы уже размещались в OVH, и несмотря на происшествие приняли решение оставаться там, т.к. доверились официальным заявлениям компании и её репутации. К тому же, если не брать в расчет чрезвычайные и редкие ситуации, в остальном уровень обслуживания в OVH в этом сегменте ЦОД выше конкурентов и нас полностью устраивал.
Героическое восстановление ABCP
Мы, конечно, предполагали, что в ДЦ может случиться форс-мажорная ситуация, поэтому использовали сервера в трех разных корпусах, каждый корпус имеет независимые друг от друга источники электропитания и сети. При выходе любого корпуса из строя, мы могли быстро переключаться на другие и продолжать работать в штатном режиме.
Да, самое страшное, что мы себе представляли, — это выход из строя одного корпуса. А на случай “нереальных” ситуаций настроили систему бэкапов не просто в ДЦ других брендов, но еще и в другие страны. Это позволило не ждать 2 недели перезапуска уцелевших в пожаре серверов, а приступить к восстановлению сразу же после того, как OVH предоставили официальную информацию о случившемся и появилось понимание, что проблема серьезная.
На восстановление Платформы ABCP до минимального рабочего состояния потребовалось двое суток и еще сутки для отладки основных функций. Практически без перерывов и сна команда из системных администраторов и разработчиков героически сражалась за максимально быстрое восстановление Платформы. Этот процесс включил в себя: покупку и получение новых серверов в другом ДЦ, установку ПО на серверах, развёртывание бэкапов, запуск Платформы, тестирование и оптимизация.
Что нам помогло восстановиться быстро:
- слаженная работа ответственных сотрудников;
- разработанный четкий порядок действий для технических специалистов;
- наличие аккаунта и бэкапов внутри ДЦ, где происходило развёртывание Платформы;
- ускоренный процесс покупки и выдачи новых серверов — обычно этот процесс занимает 3-7 рабочих дней, в этот раз ДЦ пошёл нам на встречу и сработал оперативно.
В чем мы провалились:
- отсутствие связи с клиентами — мы остались без CRM и, собственно, без смс и email-рассылки, чтобы оповестить клиентов о случившемся. Кроме чата Платформы в телеграме, у нас не осталось каналов связи для массового оповещения клиентов. Сайт abcp.ru также был недоступен и мы не могли поставить заглушку с информацией. Телефон разрывался, от перегруженности линии включался автоответчик, что оставляло часть клиентов, которые не используют телеграм, без какой-либо информации;
- плохая организация оповещения клиентов — пока технические специалисты дружно взялись и занялись восстановлением, остальные сотрудники не знали, как проходит процесс и что отвечать на вопросы клиентов, потребовалось время, чтобы сориентироваться и запустить информирование в чат;
- ошибка планирования — мы предположили 2 срока восстановления Платформы, оптимистичный, до 10:00 11 марта, и пессимистичный, до 18:00 11 марта, оба варианта оказались ошибочными, хотя в 18:00 мы и смогли открыть доступ клиентам к ПУ и сайтам, но потребовалось ещё время до 10:00 12 марта, чтобы работа была более-менее стабильной, и только 12 марта к вечеру весь функционал Платформы был полностью доступен.
Потери:
- крайне малое количество некритической для нас и наших клиентов информации, такой как история поиска запросов на сайте и некоторая информация складского модуля, которая и не включалась в регламент хранения;
- непредвиденные расходы на закупку новых серверов;
- потеря времени и нарушение графиков и распорядков в плановой разработке;
- неудобства, доставленные нашим клиентам и нарушение их бизнес-процессов.
Выводы после пожара:
- даже самые маловероятные риски могут случиться, нужно быть готовыми ко всему. Помимо пожара в OVH в марте произошла еще одна ситуация, которая могла потрясти мир дата-центров еще сильнее — террористы пытались уничтожить один из центров AWS (Amazon Web Services), крупнейшего провайдера облачных услуг. На этот раз акт не удался, и остается только надеяться, что этого не произойдет в будущем;
- необходимо разработать план и интерфейс для развёртывания бэкапа и настройки Платформы за срок не более суток;
- необходимо настроить систему информирования клиентов в случае полного отсутствия доступа к Платформе.
Кризисные ситуации в бизнесе — показатель устойчивости и надежности компании и команды, а также лучший инсайдер точек роста. Для нас случай с пожаром стал отличным опытом, отчасти мы даже рады, что это произошло сейчас, когда у нас появилось много далеко идущих планов по развитию Платформы и новых направлений. Пожар указал на слабые стороны, усиление которых обеспечит большую эффективность всему проекту в будущем.
А ещё мы ощутили мощную поддержку от пользователей Платформы. Благодарим всех наших клиентов за понимание и терпение! И отдельное спасибо клиентам, кто делился информацией с коллегами о том, как организовать рабочий процесс пока Платформа недоступна.
Неожиданные неприятности
Только мы приободрились и выдохнули после запуска Платформы в новом ДЦ, как посыпались непонятные ошибки, сбои сети, отключение и блокировка серверов, потеря связи между отдельными частями ДЦ и другие, пока ещё до конца не выявленные спецэффекты. В чате Платформы стоны, всхлипы, ругань и бесконечные жалобы на “тормоза”.
Для справки:
Платформа переехала в ДЦ бренда HETZNER, находящийся в Нюрнберге, Германия. Этот ДЦ такого же класса, как и OVH, т.е. Tier 3+, оба ДЦ находятся в одной ценовой категории и активно между собой конкурируют. HETZNER мы уже много лет используем для хранения резервных копий, поэтому развёртывание там было самым коротким путем к восстановлению. Для запуска Платформы мы докупили самые мощные и новые сервера из имеющихся в ДЦ, это должно было способствовать ускорению работы Платформы, в т.ч. и сайтов наших клиентов. В первые дни после восстановления многие клиенты успели это почувствовать.
Причины проблем:
В сгоревшем OVH мы размещались уже 6 лет и, естественно, Платформа была привязана к особенностям ДЦ. К тому же за эти годы количество функционала и опций увеличилось в несколько раз, а число пользователей заметно выросло. Всё развитие Платформы происходило с оглядкой на возможности и особенности ДЦ.
В HETZNER мы переехали в том виде, в котором существовали в OVH, и это оказалось проблемой и для нас, и для HETZNER. Новый ДЦ не был готов обрабатывать поток информации и запросов также, как это делал OVH, нагрузка Платформы для них считается слишком высокой, что приводит к отключениям серверов. Происходит это не из-за слабости или ненадежности ДЦ, а по причине другого порядка работы, который необходимо учитывать при настройке своих сервисов. Т.е. если бы много лет назад мы выбрали HETZNER и всё это время развивали Платформу здесь, то особенности ДЦ были бы учтены и качество работы не уступало состоянию до пожара.
Почему не удалось избежать этих проблем?
Отличный вопрос! Развертывание и тестирование резервной копии Платформы без клиентской нагрузки не показывало тех проблем, которые возникли после переезда. Поэтому заранее предугадать и заранее к этому подготовиться было невозможно. Экстраполировать теоретические знания и практику других IT-проектов в таких ситуациях нельзя, т.к. каждый проект индивидуален, нет даже близко похожих проектов. Только сейчас, получив этот опыт мы можем подготовиться, чтобы в будущем подобная ситуация стала для нас безболезненной.
Почему нет зеркал?
Такой вопрос писали нам в чате и в отзывах. Ответ на него простой — чтобы сохранить низкую стоимость тарифов. Если мы организуем абсолютно бесперебойную работу Платформы, используя несколько ДЦ, то стоимость тарифов значительно возрастет. Мы понимаем, что это дорого, т.к. для многих наших клиентов перетерпеть 1 день простоя Платформы, при должной организации рабочего процесса на такой случай, обойдется дешевле, чем ежемесячно платить в 2-3 раза больше. И ошибочно нас сравнивать с более крупными IT-компаниями как, например, Яндекс, у которого заработок в минуту выше нашего заработка в месяц.
Тревожные планы на ближайшее будущее
“Сколько можно терпеть?”, “Скажите, когда это закончится уже?” и “Это уже не серьезно!” — вот что сейчас получаем от клиентов практически каждый день. Нам также неприятна эта ситуация, как и вам! Нас это злит, огорчает и расстраивает... Но бизнес остается бизнесом, поэтому мы не уходим в запой или депрессию, и не записываемся в рабочее время на прием к IT-психологам, и уж тем более не ждем, когда все клиенты от нас отключатся, чтобы что-то начать делать.
Какие есть варианты?
Их несколько. И у них есть такие критерии: сложно, дорого, не очень сложно, экономно. Как, думаем, все догадываются варианта “легко и дешево” не существует. Нужно выбирать из “не очень сложно, но дорого” или “экономно, но сложно”. Разумеется, все варианты надежные и, естественно, на все нужно время. Повышение стоимости тарифов — не лучшее решение, поэтому мы выбрали путь “экономно, но сложно”.
Планы и сроки
В больших IT-проектах в долгосрочной перспективе не бывает ни точных планов, ни точных сроков. В нашем случае предстоит сильно изменить архитектуру Платформы, выделить ядро и разместить его в дорогом очень надежном ДЦ, остальные модули проработать так, чтобы при экстренном отключении одного из них работа Платформы продолжалась с допустимой деградацией качества. Разработка уже идёт, вся команда максимально задействована и распределена по ответственным зонам. Процесс продвигается поэтапно, каждую неделю пользователи будут замечать улучшения. Общий срок оцениваем максимум в полгода.
Чтобы и перестройка Платформы, и улучшение её функционала, и наши планы, и новые проекты выполнялись быстро и качественно, мы сейчас активно нанимаем новых frontend и backend-разработчиков.