Disaster Recovery Plan, или В ожидании катастрофы

СЕРГЕЙ БАРАМБА, начальник отдела системных решений ООО «БФТ». Опыт работы с компьютерами более 12 лет. Специализация Exchange Server, линейка Windows, виртуализация. Тренер Microsoft и ITIL

Disaster Recovery Plan,
или В ожидании катастрофы

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

Глоссарий

• RPO (Recovery Рoint Оbjective – целевая точка восстановления) – максимальный объем данных, которые могут быть потеряны по итогам восстановления услуги. Выражается в «отрезке времени» до сбоя. Например, целевая точка восстановления в «один день» обеспечивается ежедневным резервным копированием, при этом допустима потеря данных не более чем за 24 часа. Для каждой ИТ-услуги RPO должна быть обсуждена, согласована и задокументирована, после чего используется как требование для проектирования ИТ-услуг и плана обеспечения их непрерывности.
• RTO (Recovery Тime Оbjective – целевое время восстановления) – максимальное время, отведенное для восстановления ИТ-услуги после ее прерывания. Предоставляемое при этом качество может быть ниже нормальных значений целевых показателей. Проще говоря, мы предоставляем доступ к серверам и службам, но, возможно, не в полном объеме (его определяет PRO). Например, как часто делается в Exchange Server 2010/2013, пользователей переключают на работу с резервным сервером, на котором создают пустую базу данных. Продолжается получение и отправка почты, но архив недоступен, так как восстанавливается из резервной копии, а это может занять несколько часов. Затем «временный» и «старый» почтовые ящики сливаются вместе, и наступает момент полного восстановления сервиса.
• Interruption Window (окно недоступности сервиса) – ожидаемое время от начала происшествия до восстановления доступа к сервису и его предоставления.
• SDO (Service Delivery Objective – цели предоставления услуг) – уровень предоставления сервиса, который может быть достигнут на альтернативном оборудовании до возврата на основное.

А что, если...

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

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

В терминологии ITIL и ИТ-менеджменте укоренился следующий термин DRP – Disaster Recovery Plan, свод документов и заранее подготовленных процессов, помогающих в минимально возможные сроки восстановить работу ИТ-сервисов.

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

В ITIL описывается специальный процесс управления непрерывностью ИТ-услуг (IT Service Continuity Management (ITSCM), предназначенный для профилактики случаев чрезвычайных обстоятельств и восстановления всех необходимых бизнесу сервисов.

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

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

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

С точки зрения рисков и угроз необходимо предусматривать покрытие следующих больших групп:

• ошибки и действия пользователей (от 70 до 90% сбоев приходится на эту группу, необходимо очень внимательно подходить к тому, чтобы отладить их устранение максимально эффективно);
• сбои ПО и аппаратуры;
• аварии инженерных систем (это не только кабельные сети или электричество, но и кондиционирование, которое для серверных помещений имеет ключевое значение);
• катастрофы (техногенные и природные).

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

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

Давайте рассмотрим сценарий, в котором задействуется Microsoft Exchange Server. Несколько серверов с разными ролями почтового сервера, контроллер домена, система резервного копирования. Аппаратные или виртуальные серверы будут расположены в центре обработки данных. Почта – один из критически необходимых сервисов и элемент репутации компании. Теперь составим список рисков с точки зрения возможных потерь начиная с отсутствия подключения к ЦОД. Всвязи с участившимися стихийными бедствиями и «блэкаутами» вполне возможный сценарий.

Статью целиком читайте в журнале «Системный администратор», №10 за 2013 г. на страницах 32-35.

Комментарии могут оставлять только зарегистрированные пользователи