Есть такая поговорка: “Если вы параноик, это ещё не значит, что за вами не следят”. И порой паранойя бывает полезна. 11 октября эта паранойя нас спасла.

Несколько месяцев назад мне стало трудно спокойно спать. Меня не покидали мысли, что случится, если мы неожиданно потеряем целый регион. (Регион - это зона расположения ЦОД, где наши клиенты размещают свои облачные проекты). Причём потеряем регион не на пару часов, как иногда случается со всеми облачными провайдерами, а полностью. Я стал поднимать на планерках с командой тему, что мы должны быть к такому готовы и должны знать, как спасти проекты клиентов. У нас было три региона, в России, Европе и Америке, но российский исторически был самым крупным.

Немного контекста – мы делаем PaaS-облако Amvera. В отличие от классических облаков, где пользователь просто арендует VPS и берет всю ответственность на себя, мы предлагаем платформу для запуска приложений без настройки сервера. Пользователь привязывает репозиторий и получает работающий на сервере бот, сайт или любое другое приложение. Но раз мы избавляем пользователя от настройки инфраструктуры, то и берем на себя ответственность за инфраструктуру, бэкапы и безотказность. Когда потеря ЦОДа случается в условном (а в контексте статьи - в реальном) Яндекс Облаке, - это проблема клиента. А когда у нас - то наша. 

Поначалу коллеги возражали, что мы и так делаем больше, чем принято на рынке. У нас исторически использовались бэкапы в два уровня. Мы делали полный системный бэкап для всех дисков, которые реплицировались в трёх экземплярах. Плюс был пользовательский уровень атомарных бэкапов постоянного хранилища и кластеров PostgreSQL, которыми пользователи управляли сами. 

До моего приступа паранойи бэкапы для российского региона хранились в Яндекс облаке, распределенные по дискам в разных зонах доступности и S3. Здесь важно отметить, что для российского региона бэкапы нельзя хранить в иностранном ЦОДе. Так как это нарушит требования к локализации данных, которая важна для многих наших пользователей. Казалось бы, что может пойти не так, ну нельзя же потерять сразу больше одного ЦОДа…

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

Мы последовали простому плану: 

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

2. Сделать бэкапы, независимые от Яндекса, но хранить их в России. На случай, если все регионы Яндекса станут недоступны. 

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

Мы настроили репликацию нашей СУБД в несколько независимых ЦОДов и подготовили функционал быстрого переключения мастер-реплики.

Далее стали делать дополнительные бэкапы всех дисков в независимый ЦОД. Это было дорого и сложно, ведь в этих бэкапах содержались данные многих тысяч приложений.

Хотели сделать ещё пару полезных вещей, но не успели.

Хронология событий 

8 октября под удар попадает первый ЦОД Яндекс Облака. Нас начинает немного штормить, но глобально сервис всё ещё работает.

Мы начинаем быстро завершать последние работы. 9 октября делаем рассылку всем пользователям с работающими проектами в российском регионе и публикуем посты в социальных сетях с рекомендацией перенести проекты в иностранные регионы. Разумеется, рассылку почти никто не прочитал…

Тем временем, актуальные бэкапы перекачиваются в другой ЦОД. Хорошо, что мы это сделали. Потому что, как выяснится позднее, восстановиться из бэкапов в Яндексе в их уцелевших зонах будет невозможно – Яндекс ограничит квоты, чтобы пользователи не положили им оставшуюся инфраструктуру.

Я просыпаюсь в 4 утра 11 октября и вижу, что под удар попал наш основной ЦОД. И уже сыпятся обращения в поддержку. Связываюсь с нашим дежурным инженером и выясняю, что регион полностью выведен из строя.

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

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

• Личный кабинет восстановили к 12:00 11 октября. Пользователи получили доступ к работающим регионам, но, увы, не увидели свои проекты из потерянного региона. 

• К 20:30 11 октября у пользователей появилась возможность скачать бэкапы приложений и кластеров PostgreSQL. Для этого программисты нашей команды экстренно написали целый сервис для доступа к файлам, со своей логикой и фронтом.

• к 21:30 11 октября запущен новый российский регион Москва_1. Это отдельное инженерное чудо, и я выражаю благодарность коллегам за такую скорость. Изначально мы рассчитывали, что ввод региона в эксплуатацию займёт неделю, а не половину дня.

• К ночи 12 октября мы восстановили 99% работающих приложений и большинство кластеров PostgreSQL в новом регионе в остановленном статусе.

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

• С 15 октября начинаем принимать заявки на возмещение по нашей политике SLA. Мы понимаем, что инцидент был ощутим. И пусть компенсации по SLA обычно небольшие и привязаны к фактическим тратам на платформе, это лучше, чем ничего. Мы не снимаем с себя ответственность. Если вы наш пользователь, достаточно в свободной форме попросить о компенсации в чате в личном кабинете.

Если говорить честно, нам ещё только предстоит сделать некоторые вещи, чтобы вернуться на прошлый уровень. Но большая часть уже сделана. Нам удалось восстановить более 99% запущенных приложений, а по остальным - дать доступ пользователям к бэкапам. Удалось восстановить 99,7% запущенных PostgreSQL на быстрых дисках полностью, 95% PostgreSQL на медленных дисках тоже полностью и 4% частично. Для большинства оставшихся кластеров либо были атомарные пользовательские бэкапы, которыми пользователи могут воспользоваться самостоятельно, либо нам удалось их восстановить в ручном режиме по запросу. Нам всегда можно написать в поддержку, чтобы мы вручную восстановили то, с чем не справился автоматический скрипт. Это может занять время, но мы постараемся помочь каждому.

Что не предусмотрели

Так как восстанавливали работоспособность сервиса в авральном режиме, не всё получилось предусмотреть. В новом регионе изменился формат бесплатных и приватных доменов, а также A запись для привязки собственных доменов. Зато домены активировались сразу с новыми функциями защиты от ботов и брутфорса и с нашими продвинутыми возможностями управления сетью.

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

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

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

Отдельно хочу затронуть тему сгенерированных ИИ-тикетов в поддержку. Не надо так делать, пожалуйста. У нас в поддержке отвечают люди. Представьте, что у вас в очереди 100 обращений и вам приходит максимально подробное обращение с 24 мельчайшими вопросами и размером с 4 страницы А4. Что вы будете делать? Скорее всего, отложите его, пока не ответите на сообщения, которые можно быстро прочитать, понять их суть и помочь. И если честно, это очень странное ощущение – отвечать на сгенерированные ИИ вопросы. Делать это не совсем комфортно. Поэтому если помощь нужна быстро, лучше формулировать запрос самостоятельно – так намного больше шансов на качественную помощь.

Что будет дальше

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

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