 |
|
|
|
Disaster Recovery Plan, или В ожидании катастрофы
Disaster Recovery Plan, «Всякое неприятное событие неожиданно, даже если к нему готовились». Что необходимо учесть, чтобы простой и потери были сведены к минимуму? Глоссарий
А что, если... Вот наступил момент, когда мы настроили новый сервер. Протестировали его работу под нагрузкой, установили службы и запустили в промышленную эксплуатацию. Разослали всем ответственным лицам письмо о том, как получить доступ к новым возможностям, которые должны облегчать жизнь и помогать экономить время и деньги. Вроде все хорошо, но не покидает чувство, что что-то не учли или забыли. В погоне за скорым завершением проекта мы не подумали, что будет, если наступит «тот самый день», когда произойдет авария. Итак, надо продумать процесс восстановления уровня сервиса в полном объеме. Многие системные администраторы ассоциируют этот план со списком резервного копирования, но это только крупица в огромном списке мыслительной работы. И первый же сбой покажет, что бэкап полезен, но без дополнительных манипуляций это всего лишь занятое место на диске. В терминологии ITIL и ИТ-менеджменте укоренился следующий термин DRP – Disaster Recovery Plan, свод документов и заранее подготовленных процессов, помогающих в минимально возможные сроки восстановить работу ИТ-сервисов. Из этого документа должно быть ясно, в какой последовательности необходимо приступать к восстановлению систем, какие из них имеют решающее значение для бизнеса, и какие условия требуются для их скорейшего восстановления. В ITIL описывается специальный процесс управления непрерывностью ИТ-услуг (IT Service Continuity Management (ITSCM), предназначенный для профилактики случаев чрезвычайных обстоятельств и восстановления всех необходимых бизнесу сервисов. В ITSCM учтены разработка, тестирование и поддержка плана восстановления ИТ-услуги с достаточным уровнем детализации, который призван помочь пережить чрезвычайную ситуацию и вернуть нормальную работу в заданный промежуток времени. Даже в небольшой компании выкладки и принципы, используемые при его создании, могут оказаться полезными в повседневной работе. В любом случае все наши действия, направленные на поиск способов устранения последствий сбоев, – это попытки угадать будущие неопределенные события, которые могут меняться от случая к случаю. Если система работает четко, тонеобходимо иметь живой опыт организации работы во время сбоев и аварий. Самым простым и дешевым способом остаются эмуляция и учения. Сначала на бумаге (штабные учения), потом в тестовой лаборатории в условиях, «максимально приближенных к боевым». С точки зрения рисков и угроз необходимо предусматривать покрытие следующих больших групп:
Мы все прекрасно понимаем, что нарушение работы информационных сервисов или невозможность подключиться к ним ведут к финансовым потерям, ущербу для репутации и, возможно, даже к закрытию бизнеса. Сам по себе документ сназванием «План восстановления» является просто листами бумаги. Требуется, чтобы все без исключения ответственные лица знали, что он существует, и каждый понимал, как действовать и какие средства связи нужно использовать. Если этого нет, то не будет и слаженного и четкого выполнения действий, описанных в плане. Значит, проблемы будут серьезными. Давайте рассмотрим сценарий, в котором задействуется Microsoft Exchange Server. Несколько серверов с разными ролями почтового сервера, контроллер домена, система резервного копирования. Аппаратные или виртуальные серверы будут расположены в центре обработки данных. Почта – один из критически необходимых сервисов и элемент репутации компании. Теперь составим список рисков с точки зрения возможных потерь начиная с отсутствия подключения к ЦОД. Всвязи с участившимися стихийными бедствиями и «блэкаутами» вполне возможный сценарий. Статью целиком читайте в журнале «Системный администратор», №10 за 2013 г. на страницах 32-35. |
СЕРГЕЙ БАРАМБА,Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
