Disaster Recovery Plan, или В ожидании катастрофы::Журнал СА 10.2013
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 2252
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 2228
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1788
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1311
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1842
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

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

Архив номеров / 2013 / Выпуск №10 (131) / 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.


Комментарии отсутствуют

Добавить комментарий

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

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru