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

В некоторых случаях это понять проще (вспомните о запуске «Аполлона», когда думаете, начинать ли процедуру аварийного восстановления), в некоторых – сложнее. Например, полный отказ оборудования, пожар, наводнение или кража – это события, после которых нельзя быстро восстановиться, поэтому имеет смысл запустить аварийное переключение.

Однако другие события не столь очевидны. Например, ввод питания, который периодически выключается, но при этом для поддержания работы ключевых серверов как раз хватает ресурса ИБП (источника бесперебойного питания), или сбой сети, когда провайдер уверяет вас, что занимается проблемой и подключение будет восстановлено «очень скоро». Когда – «скоро»? Стратегия перехода в режим аварийного восстановления, включающая такие критерии, как затронутые сбоем службы и время, в течение которого они остаются недоступны, избавит от неопределенности, и вы будете четко понимать, когда пора щелкнуть воображаемым переключателем.

Определив, когда переключаться, спланируйте порядок перехода. В общем случае необходимо сделать следующее:

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

• Определите, какие службы необходимо запустить (если они находятся в режиме холодного резервирования) и заполнить актуальными данными.

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

• Определите все роли и параметры настройки, а также какие тесты необходимо выполнить для проверки резервной зоны и кто должен будет это делать.

• Если вы планируете возврат к исходной конфигурации, продумайте план перехода к основной зоне после устранения сбоя.

Заметки с полей

Непреднамеренные последствия

Для работы сотрудников с серверами, расположенными в офисе, в компаниях обычно используются виртуальные частные сети (VPN). Но что произойдет, когда вы переключитесь на новую зону с другими точками доступа? Что ж, у одной портфельной компании, с которой я работал, с помощью аварийного восстановления отлично получилось перепилить сук, на котором она сидела. Ей удалось полностью заблокировать себе доступ к резервной зоне, потому что правила файервола были прописаны только для основной зоны. Положительный момент: средства безопасности сработали отлично!

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

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

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