Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Всем доброго времени суток.
В данной статье речь пойдет про то, как мы «с нуля» учимся делать работающий Disaster Recovery Plan. Вы не ошиблись, я написал «учимся», потому что хотим получить «работающий» план.
Лирическое отступление
Мы расположены в центральной Азии, у нас IT-команда, которая сопровождает парк из 1000+ виртуальных серверов, имеет свои дата-центры, кубернетисы и все вот это вот. Когда к нам приходят новые инженеры, на собеседовании они всегда положительно качают головой на вопрос о том проводили ли они тестирование отработки отказов IT-инфраструктуры на прошлом месте работы. Скорей всего инженеры хорошие и они не врут, мы им доверяем. Начинается практика и каким-то счастливым случаем случается авария на второй день работы данного инженера. Выходя в опенспейс где сидит наша команда IT-инфраструктуры можно наблюдать различное поведение инженеров, вот некоторые примеры:
Senior - очень сильно чем-то занят, не реагирует на окружающий мир;
Middle - смотрит систему мониторинга, пытается обнаружить то, что старший инженер уже обнаружил, но не сказал;
Junior - просто не понимает, что ему нужно делать;
Если зайти в другой опенспейс, где сидят команды сопровождения, то там тоже можно заметить некое возбужденное настроение от происходящего. Когда все починят, то на ретро обязательно все дружно кивнут, что к следующей аварии все будут готовы или даже следующей аварии не будет.
Не верьте, это ложь, готовы не будут.
Что делать?
Я как технический директор прихожу в ярость от того, что где-то случилась авария. Начинаем с самого себя и принимаем ту ситуацию, что наш мир несовершенен. Авария может случится и это очень себе возможная ситуация.
Что такое авария?
Авария - это соревнование, в котором тебе на скорость нужно выполнить восстановление работы сервисов, в противном случае SLA будет нарушен. Чтобы не проиграть в соревновании спортсмены к нему готовятся, верно? Как готовиться к соревнованию? Повторять упражнение каждый день.
Упражнение №1 - "Включение и выключение"
Сразу делать так, чтобы все работало при отказе это прекрасно, но только нет замечательней тестов, чем промышленная эксплуатация. Начинаем с базовых вещей. Задайте себе вопрос — «Сколько времени займет включение и выключение вашей IT‑инфраструктуры?». Сможете ответить с точностью до минут? Нам очень захотелось ответить.
Сначала мы определили уровни доступности, которые мы будем контролировать:
Команда
Выполнение DRP это командная игра, следовательно нам нужно объединить команды. Так как в нашей структуре поддержкой IT-инфраструктуры занимается 3 подразделения, то мы будем собирать кросс-команду.
Наименование команд:
Альфа - отвечает за оранжевый уровень
Бета - отвечает за синие уровни
Гамма - отвечает за зеленые уровни
Примечание: за красный уровень отвечает обслуживающая компания, мы с ней поругались, поэтому они к нам присоединяться только в следующей итерации.
Важней всего - правильная коммуникация
У каждой команды есть координатор, взаимодействие между командами происходит только на уровне координаторов. Это не значит, что специалисты не могут общаться горизонтально, это значит что координаторы должны быть первыми в курсе, если что-то идет не по плану.
План
Каждая команда должна понимать свой порядок действий при выключении и включении. Для этого, те самые опытные инженеры должны написать подробный план, о том как и что правильно включать. Для данного этапа требуется некоторое время, так как вдруг может оказаться, что некоторые "железки" никто раньше не включал "с пальца" и множество других неожиданностей.
Про хорошие планы можно вдоволь начитаться на просторах интернета, хотелось бы выделить несколько важных моментов в структуре плана, которые отметили для себя мы:
План должен быть разбит на этапы согласно наших уровней доступности;
Этап состоит из нескольких шагов;
Каждый этап должен иметь четкий критерий завершенности;
Каждый этап должна иметь плановый и фактический тайминг;
Каждый шаг в этапе должен иметь плановый и фактический тайминг;
За каждым шагом закреплен ответственный инженер;
За каждым этапом закреплен ответственный координатор;
Планируем хорошо, чтобы потом не было больно.
Координаторы
План составили, теперь нужно объяснить координаторам, кто они такие. В моем случае координаторами были руководители подразделений. Я строго запретил им вмешиваться в процесс проведения DRP, так как инженеры должны работать, а менеджмент планировать и контролировать процесс. Таким образом координаторы более внимательно отнесутся к написанию плана, а инженеры поверят в то, что план это 80% процентов успеха.
Готовимся к тестированию
Так как у нас офис и ЦОД это разные локации, то есть необходимость в "удаленных" руках. Формируем еще одну команду под названием "Remote hands" и информируем её о том, что в момент тестирования DRP им нужно будет находится в ЦОДе.
Информируем остальных коллег из IT, предупреждаем бизнес, бронируем в планировщике встреч время на субботу после 11 вечера, скоро все произойдет.
Тестирование плана
Ну вот, день настал. Мотивированные инженеры приехали в офис (а счастливчики из Remote hands в ЦОД), чтобы сегодня ночью осуществить задуманное
Интересные статьи
Интересные статьи
