Настоящий CTO: думай как технический директор - Алан Уильямсон

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

8.4.2. Полное или частичное обслуживание

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

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

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

Обеспечить полное предоставление услуги гораздо сложнее, в том числе потому, что может понадобиться четко определить текущее состояние системы, которое необходимо воспроизвести в новой системе. Может ли что-то задублироваться или быть обработано повторно – потому что резервная зона не знает, что уже было сделано или какая-то информация полностью потерялась? В качестве примера можно привести уведомления по электронной почте, генерируемые системой. Если сбой происходит во время отправки пачки электронных писем, обязательно ли выяснять, какие письма уже были успешно отправлены, или допустимо, чтобы часть пользователей получила письма еще раз?

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

Дорого не всегда значит качественно

Мне нравится, как новые клиенты рассказывают мне о своих стратегиях аварийного восстановления, если они у них есть. Как гордые родители, они с энтузиазмом сообщают, сколько денег тратят на защиту данных клиентов и обеспечение бесперебойной работы. У меня был один клиент, который слишком доверял одной компании с названием из трех букв, и его ежегодные расходы на лицензии на ПО и оборудование превышали шестизначную сумму (в долларах). Его ожидания были высоки, и руководство верило, что, если оно столько платит, значит все в порядке. Все спокойно спали по ночам. Когда я начал задавать вопросы, оказалось, что всё не так радужно, и, если вкратце, в течение нескольких недель мы сократили расходы до четырехзначной цифры и создали конфигурацию, которая действительно работала и использовала AWS. Частая проблема: клиент слишком доверяет аутсорсингу, предполагая, что компания с названием из трех букв делает намного больше, чем есть на самом деле. Вопрос аварийного восстановления сложен, и это не то, что можно просто передать на аутсорсинг и забыть.

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

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

8.4.3. Переход вперед или возврат назад

Предположим, вы перешли на резервную зону в полной или частичной конфигурации. Что вы будете делать после восстановления основной зоны? Если вы обнаружите, что не знаете ответа, то обратите на это внимание. Это очевидный признак того, что в вашей организации аварийное восстановление никогда не происходило (или не отрабатывалось) и никто не думал о том, что будет происходить после того, как прошел Годзилла, и о том, что и как необходимо восстановить. Тем не менее все это вполне может произойти в реальности.

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

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

8.4.4. Организация реагирования на аварии

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

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

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

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

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

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

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

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

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

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

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

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

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

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