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

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

Давайте подумаем вместе.

Бекапы. Если вчера достаточно было иметь один off-site бекап, то сегодня этого стало резко недостаточно. Две и более гео-разнесенных локации, куда можно складывать бекапы баз, кода и настроек для каждого сервиса.

Запас по ресурсам. В момент когда вам понадобятся вычислительные ресурсы, есть большая вероятность, что понадобятся они не только вам. Для виртуалок в публичных облаках это означает как минимум увеличение оверкоммита, а как максимум невозможность докинуть ресурсов или даже использовать оплаченные. Поэтому резервироваться необходимо заранее, закупая гарантированные мощности. Самый простой вариант эти мощности себе гарантировать - закупить выделенные сервера. Там никто кроме вас не может запустить процесс и отъесть так необходимый CPU или дисковую мощность. Вы сами выбираете сколько и каких контейнеров запустить на железке и она вся ваша.

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

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

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

Мониторинг. Если основной ДЦ станет недоступен с ним почти наверняка умрет и текущий мониторинг. Кроме того, пока резервная площадка стоит без нагрузки, с ней тоже может что-то произойти, поэтому развертывание локальной системы мониторинга становится пусть и не первостепенной, но важной задачей. Где-то между развертыванием и нагрузочным, потому что нагрузочное без мониторинга - деньги на ветер.

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

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

Если остались вопросы, завтра в 19:00 по Москве соберемся на встречу по георезервированию. Таймпад все еще не але, поэтому сделал группу: https://t.me/+qGxoTCH6JhFjYmUy

Завтра отдельно продублирую в канале.

Берегите близких и не роняйте продакшн.

@downtime_bar #DRP