Всем доброго времени суток.

В данной статье речь пойдет про то, как мы «с нуля» учимся делать работающий Disaster Recovery Plan. Вы не ошиблись, я написал «учимся», потому что хотим получить «работающий» план.

Лирическое отступление

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

1. Senior - очень сильно чем-то занят, не реагирует на окружающий мир;

2. Middle - смотрит систему мониторинга, пытается обнаружить то, что старший инженер уже обнаружил, но не сказал;

3. Junior - просто не понимает, что ему нужно делать;

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

Не верьте, это ложь, готовы не будут.

Что делать?

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

Что такое авария?

Авария - это соревнование, в котором тебе на скорость нужно выполнить восстановление работы сервисов, в противном случае SLA будет нарушен. Чтобы не проиграть в соревновании спортсмены к нему готовятся, верно? Как готовиться к соревнованию? Повторять упражнение каждый день.

Упражнение №1 - "Включение и выключение"

Сразу делать так, чтобы все работало при отказе это прекрасно, но только нет замечательней тестов, чем промышленная эксплуатация. Начинаем с базовых вещей. Задайте себе вопрос — «Сколько времени займет включение и выключение вашей IT‑инфраструктуры?». Сможете ответить с точностью до минут? Нам очень захотелось ответить.

Сначала мы определили уровни доступности, которые мы будем контролировать:

Команда

Выполнение DRP это командная игра, следовательно нам нужно объединить команды. Так как в нашей структуре поддержкой IT-инфраструктуры занимается 3 подразделения, то мы будем собирать кросс-команду.

Наименование команд:

• Альфа - отвечает за оранжевый уровень

• Бета - отвечает за синие уровни

• Гамма - отвечает за зеленые уровни

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

Важней всего - правильная коммуникация

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

План

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

Про хорошие планы можно вдоволь начитаться на просторах интернета, хотелось бы выделить несколько важных моментов в структуре плана, которые отметили для себя мы:

1. План должен быть разбит на этапы согласно наших уровней доступности;

2. Этап состоит из нескольких шагов;

3. Каждый этап должен иметь четкий критерий завершенности;

4. Каждый этап должна иметь плановый и фактический тайминг;

5. Каждый шаг в этапе должен иметь плановый и фактический тайминг;

6. За каждым шагом закреплен ответственный инженер;

7. За каждым этапом закреплен ответственный координатор;

Планируем хорошо, чтобы потом не было больно.

Координаторы

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

Готовимся к тестированию

Так как у нас офис и ЦОД это разные локации, то есть необходимость в "удаленных" руках. Формируем еще одну команду под названием "Remote hands" и информируем её о том, что в момент тестирования DRP им нужно будет находится в ЦОДе.

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

Тестирование плана

Ну вот, день настал. Мотивированные инженеры приехали в офис (а счастливчики из Remote hands в ЦОД), чтобы сегодня ночью осуществить задуманное????

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

Наше тестирование выключения и включения инфраструктуры длилось 5,5 часов. Из которых примерно 30 минут заняло выключение и 5 часов включение. Процент действий выполненных по плану был достаточно высокий. Попутно выполняя план координаторы делали заметки, чтобы после их обсудить на ретро и внести корректировки в RDP, либо архитектуры сервисов.

Итоги

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

Упражнение №2 - это отключение электропитания и переключение сервисов на резервный ЦОД, но это уже совсем другая история...