Готовим Drp — Не Забываем Учесть Метеорит

Готовим DRP — не забываем учесть метеорит

Даже во время катастрофы всегда есть время выпить чашечку чая.

ДРП (план аварийного восстановления) — это вещь, которая в идеале никогда не понадобится.

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

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

В этом посте я хочу поделиться рекомендациями о том, как написать DRP и что он должен содержать.

Мы также рассмотрим следующие вещи:

Давайте научимся думать как злодей.
Давайте посмотрим на пользу чашки чая во время апокалипсиса.
Продумаем удобную структуру DRP
Давайте посмотрим, как это проверить

Каким компаниям это может быть полезно?

Очень сложно провести черту, когда ИТ-отдел начинает нуждаться в таких вещах.

Я бы сказал, что вам обязательно нужен DRP, если:

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

Когда ИТ-отдел месяцами выпрашивает хотя бы пару HDD в старый сервер для резервного копирования, вам вряд ли удастся организовать полноценный перенос вышедшего из строя сервиса для резервирования мощностей.

Хотя и здесь документация лишней не будет.

Документация важна

Начните с документации.

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

Получив хорошее описание компонентов сервиса, просмотрите статистику аварий.

Они почти наверняка будут совершенно типичными.

Например, ваш диск время от времени переполняется, что приводит к сбою узла, пока он не будет очищен вручную.

Либо клиентский сервис становится недоступен из-за того, что кто-то снова забыл продлить сертификат, а Let's Encrypt не смог или не захотел настроить.

Мысли как диверсант

Самая сложная часть — предсказать те аварии, которые никогда раньше не случались, но которые потенциально могут привести к полному сбою вашего сервиса.

Здесь мы с коллегами обычно играем злодеев.

Возьмите побольше кофе и чего-нибудь вкусненького и запритесь в переговорной комнате.

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

Не обязательно вдаваться в подробности вплоть до конкретной уборщицы и протаскивания кабелей; достаточно рассмотреть сценарий «Нарушение целостности локальной сети».

Как правило, наиболее типичные аварийные ситуации делятся на следующие виды:

Ошибка сети
Сбой служб ОС
Сбой приложения
Железный провал
Сбой виртуализации

Просто просмотрите каждый тип и посмотрите, что применимо к вашему сервису.

Например, демон Nginx может упасть и не подняться — это означает сбои со стороны ОС.

Редкая ситуация, которая приводит к сбою вашего веб-приложения, — это сбой программного обеспечения.

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

Как отличить зависший интерфейс на виртуализации от упавшего цис-диска и аварии сети, например.

Это важно, чтобы быстро найти виновных и начать тянуть их за хвост, пока авария не будет устранена.

После того, как типичные проблемы записаны, наливаем еще кофе и начинаем рассматривать самые странные сценарии, когда некоторые параметры начинают выходить далеко за пределы нормы.

Например:

Что произойдет, если время на активном узле переместится на минуту назад относительно других узлов в кластере?
Что, если время двинется вперед, что, если на 10 лет?
Что произойдет, если узел кластера внезапно потеряет сеть во время синхронизации?
Что произойдет, если два узла не поделят лидерство из-за временной изоляции друг друга в сети?

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

Если сложно поставить диагноз, то даже лучше.

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

И если вы им пообещаете для этого испытательный стенд, это совершенно нормально.

Что это у тебя за ДРП?!

Итак, вы определили свою модель угроз.

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

Ваша задача написать те самые красные конверты, которые будут вскрыты в экстренной ситуации.

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

Посмотрите, как установлены аварийные знаки в медицинских кабинетах.

Например, что делать при анафилактическом шоке.

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

Для этого на стене висят четкие инструкции с пунктами типа «открыть упаковку такого-то» и «ввести такое-то количество препарата внутривенно».

В критической ситуации трудно думать! Должны быть простые инструкции по разбору спинного мозга.

Хороший DRP состоит из нескольких простых блоков:

Кого уведомить о начале ДТП.
Это важно для того, чтобы максимально распараллелить процесс исключения.
Как правильно диагностировать - выполнить трассировку, посмотреть в systemctl статус servicename и так далее.
Сколько времени вы можете потратить на каждый этап? Если вы не успеете исправить это вручную в течение срока SLA, виртуальная машина будет убита и откачена из вчерашней резервной копии.
Как убедиться, что авария окончена.

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

Простая потеря резервирования не должна вызывать DRP. Также в DRP можно записать чашку чая.

Серьезно.

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

Как правило, 5 минут за чашкой чая дадут вам время успокоиться и проанализировать происходящее.

Не путайте DRP и паспорт системы! Не перегружайте его ненужными данными.

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

А в самом DRP есть только прямые инструкции куда и как подключаться с конкретными командами для копирования-вставки.

Как правильно проводить тестирование

Убедитесь, что любой ответственный сотрудник способен выполнить все пункты.

В самый ответственный момент может оказаться, что у инженера нет прав доступа к нужной системе, нет паролей от нужной учетной записи или он понятия не имеет, что такое «Подключиться к консоли управления сервисом через прокси на Головной офис» означает. Каждый пункт должен быть предельно простым.

Неправильный - «Зайти в виртуализацию и перезагрузить мертвый узел» Верно - «Подключитесь через веб-интерфейс к virt.example.com, в разделе узлов перезагрузите узел, вызывающий ошибку».

Избегайте двусмысленности.

Помните испуганного стажера.

Обязательно протестируйте DRP. Это не просто план напоказ – это то, что позволит вам и вашим клиентам быстро выйти из критической ситуации.

Лучше всего сделать это несколько раз:

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

Ключевые моменты

Если дерьмо и может случиться, то оно не только произойдет, но и произойдет при самом катастрофическом сценарии.
Убедитесь, что у вас есть ресурсы для аварийного переключения нагрузки.
Убедитесь, что у вас есть резервные копии: они создаются автоматически и регулярно проверяются на целостность.
Продумайте типичные сценарии угроз.
Дайте инженерам возможность придумывать нестандартные варианты предоставления сервиса.
DRP должна представлять собой простую и четкую инструкцию.
Вся комплексная диагностика проводится только после восстановления обслуживания клиентов.
Даже если на резервной мощности.
Укажите ключевые номера телефонов и контакты в DRP.
Регулярно проверяйте понимание сотрудниками DRP.
Организовывать плановые аварии на производственных объектах.
Стенды не могут заменить все.