Цель этой статьи — показать, как и почему мы решили протестировать наш DRP (план аварийного восстановления) в реальных условиях… в нашей производственной среде.
Что такое ДРП?
Решения Toucan Toco исторически представляют собой решения SaaS, размещаемые на голых серверах.
Конечно, как редактор SaaS мы следуем обычным передовым методам работы с нашей инфраструктурой:
- все развертывается, настраивается и настраивается с помощью наших скриптов доставки Ansible
- вся инфраструктура контролируется нашими собственными агентами (со стеком ELKi, beats, Elastalert) и внешними сервисами (типа тестов StatusCake, автоматически создаваемых нашим модулем Ansible)
- каждый клиентский стек и данные резервируются и шифруются закрытыми ключами GPG (по одному для каждого клиента) и экспортируются на выделенный сервер хранения в другом центре обработки данных.
- у нас есть отказоустойчивость и балансировка нагрузки на наших основных сервисах
- и, наконец, мы используем инструменты и сценарии для управления и восстановления стека и данных наших клиентов.
Мы уверены, что все это работает. Со временем они становятся все более и более надежными, потому что мы используем их каждый день. Тем не менее, мы задались вопросом, будем ли мы готовы к тому, если центр обработки данных нашего поставщика серверов взорвется?
Даже если вероятность довольно низкая, мы должны быть готовы и знать, как реагировать.
Поскольку мы являемся решением SaaS, клиенты которого ежедневно полагаются на наш продукт и придерживаются SLA, просто необходимо знать, как справиться с наихудшими ситуациями.
План аварийного восстановления (также известный как DRP) становится возможностью вашей оперативной группы решать основные проблемы.
В нашем масштабе иметь полностью реплицированную инфраструктуру в разных центрах обработки данных не имело смысла.
У нас практический склад ума. Если бы произошло стихийное бедствие, нам не нужно было бы иметь 2 функциональных, идентичных и современных дома, потому что мы могли бы построить совершенно новый менее чем за 2 минуты.
А поскольку у нас были все инструменты для восстановления стеков и сервисов наших клиентов, нашей резервной копии, моментальных снимков и миграции, было легко соединить точки и представить DRP.
Для такой маленькой команды, как мы, это была интересная быстрая победа.
Этим летом мы написали наш полный план аварийного восстановления. Наш DRP представляет собой набор документов, процедур, методов и сценариев для восстановления бизнеса Toucan Toco после аварии, обрушившейся на наш центр обработки данных.
В то же время мы также купили несколько запасных серверов в другом дата-центре. Они запущены и готовы к производству, и они будут нашим запасным вариантом в случае серьезной проблемы.
Почему мы должны тестировать DRP?
Разве это не очевидно? :D
Вы должны проверить это до того, как случится катастрофа.
В противном случае это просто теория, и мы не верим в известную поговорку Не волнуйтесь, это должно работать
Ну давай же!
Если вы читаете этот пост, вы, вероятно, айтишник и хорошо знаете Закон Мерфи: если что-то может пойти не так… так оно и будет.
Итак, вам нужно протестировать свой план по нескольким причинам:
- чтобы убедиться, что это работает ;)
- настроить его
- чтобы команда была уверена в этом и избегала oupsy! знаете ли вы, что нам нужно делать, если X полностью выйдет из строя симптом
- потому что это часть технической культуры: мы хотим все тестировать!
Это не все.
Вдохновленные тестами обезьяны хаоса и подходом Netflix, мы твердо убеждены, что такие тесты следует проводить по-настоящему в производственном контексте.
Это как научиться плавать: вы можете выучить движения за пределами бассейна, но если вы хотите доказать себе, что умеете плавать, вам нужно делать это в глубине бассейна.
Как протестировать DRP?
Как только наш DRP был готов, мы запланировали краш-тест в нашей производственной среде. Только несколько человек были в секрете, остальная часть команды только знала, что что-то планируется, без каких-либо подробностей.
Почему? воспроизвести контекст, «сюрприз» и напряжение ситуации.
Однако мы нацелились на часть инфраструктуры, которая не оказала прямого влияния на бизнес. Это был самый первый раз, и мы не совсем сумасшедшие :P.
Мы хотели избежать «испытательного шаблона аварийных зданий»: они никогда не делаются правильно. Звонит будильник, люди хватают все (телефоны, сумки, ноутбуки…). Они идут, небрежно разговаривая со своими коллегами, и, наконец, выходят из здания… потому что знают, что это испытание.
Эти тесты не актуальны и не отслеживаются в реальных условиях, когда происходит реальная чрезвычайная ситуация, это большая неразбериха. Люди не всегда страдают или погибают в результате пожара, а из-за паники и стресса.
Вернемся к нашей теме. Основными целями испытаний являются:
- чтобы убедиться, что наш мониторинг, скрипты и процедуры работают
- проверить, как команда реагирует, общается и следует инструкциям и процедурам во время инцидента
- чтобы убедиться, что техническая команда способна справиться со всем без моей помощи. Я единственный официальный SRE/SysAdmin/DevOps/DevOops! (называйте меня как хотите) в команде, и это не должно быть проблемой для Toucan Toco
- сказать «мы готовы!» и вызвать доверие у наших клиентов
Смоделировать реальную катастрофу было довольно просто.
Мы решили просто отказаться от всего сетевого трафика от наших партнеров, демонстраций и учебных инфраструктур.
Давайте посмотрим, как мы это сделали.
Выпусти кракена!
Были здесь!
Все горит, а я смотрю на огонь!
Как объяснялось ранее, цель также состоит в том, чтобы подтвердить, что техническая команда может справиться с ситуацией без меня. Поэтому во время выпуска я просто делал заметки и проверял следующие моменты:
- сколько времени потребовалось команде, чтобы вернуться к нормальному состоянию
- насколько хорошо команда поняла проблему
- насколько хорошо использовались инструменты мониторинга, информационные панели и журналы
- насколько хорошо команда следовала процедурам
- как проходило общение между технической командой и остальными командами Toucan Toco?
- как они подтвердили, что все было в порядке и вернулось в норму
Во время симуляции я задавал вопросы, чтобы оспорить решения команды, выбор и заставить их немного усомниться в себе… ^^ (иначе это не смешно)
В итоге после 19 минут простоя вся партнерская, демонстрационная и учебная инфраструктуры были переустановлены, восстановлены с последними бэкапами на серверах «с нуля» в другом дата-центре с помощью одних лишь скриптов, ничего не делая вручную и без меня.
Команда ГГ!
Что дальше?
Для первого теста мы были очень довольны результатом.
Даже если это всего лишь часть инфраструктуры, процедуры и сценарии остаются прежними.
Зная то, что мы знаем, если бы нам пришлось переустанавливать и восстанавливать полную инфраструктуру Toucan Toco с нуля (все клиентские стеки, частные и общедоступные сервисы, CICD, мониторинг….), это заняло бы у нас менее 2 часов.
Для такой небольшой команды, как мы, это не так уж плохо, мы знаем, что готовы, а команда Toucan Toco полностью автономна, чтобы справиться с бедствием без меня.
Сейчас нам нужно улучшить нашу DRP, но мы знаем, что это «бесконечная» работа.
Поскольку мы проводили тест в реальных условиях, мы знаем, что нам нужно для изменения частей нашего мониторинга, журналов, скриптов и документации.
С того дня мы узнали, на чем сосредоточиться:
- изменение некоторых проверок мониторинга и выходных данных, чтобы помочь быстрее понять проблемы
- добавление некоторых журналов и слабых уведомлений, чтобы упростить отслеживание процесса восстановления
- получить лучший автоматизированный способ отправки уведомлений по электронной почте нашим партнерам и клиентам
Итак, наконец, что делать дальше?
Я буду наслаждаться каникулами, потому что я француз, и запланирую еще один тест, чтобы подтвердить, что мы стали лучше :)
Первоначально опубликовано Эрваном Бен Суйденом на https://toucantoco.com 4 декабря 2018 г.
