Создание плана аварийного восстановления при сбое сервера

pasted-image-0-1-1

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

Что такое план аварийного восстановления?

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

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

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

Какие ситуации следует учитывать в DRP?

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

Центральным исследованием, лежащим в основе любого DRP, должен быть Анализ воздействия на бизнес, который учитывает все потенциальные риски для данных или оборудования, такие как:

  • Случайная потеря приложений и данных
  • Аппаратный сбой
  • Проблемы с подключением
  • Электрические перебои
  • Утечки воды
  • Длительные DDoS-атаки
  • Погода и геологические события. 

План аварийного восстановления сосредоточен только на реагировании на бедствия?

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

Как мне создать план аварийного восстановления?

Для облегчения работы в сети существуют шаблоны DRP, помогающие организовать процесс реагирования на бедствия. Хотя доступно несколько шаблонов, IBM разработала особенно полезный шаблон аварийного восстановления , который можно скопировать или воспроизвести для вашего бизнеса.

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

Шаг 1: Укажите основные цели DRP

Цели, которые обычно важны для любого бизнеса, включают те, которые перечислены в шаблоне IBM DRP, которые

  • Чтобы минимизировать прерывания нормальной работы.
  • Ограничить степень разрушения и повреждения.
  • Чтобы минимизировать экономический эффект от прерывания.
  • Заранее установить альтернативные способы работы.
  • Обучить персонал экстренным процедурам.
  • Обеспечить плавное и быстрое восстановление сервиса.

Шаг 2. Проведите инвентаризацию всего оборудования и приложений ИТ-системы.

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

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

Шаг 3: Проведите тщательный анализ рисков систем вашей компании

Проведите инвентаризацию оборудования и приложений, используемых в бизнесе, с оценкой потенциальных опасностей, которые могут повлиять на работу каждого ИТ-актива. (Некоторые опасности могут зависеть от конкретного места, например, от возможных протечек воды.) Проанализируйте электрические и другие факторы. Определите приемлемые целевую точку восстановления (RPO) и целевое время восстановления (RTO) для аппаратного сбоя и для каждого набора приложений и данных.

Шаг 4: Установите бюджет

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

Шаг 5: Разработайте и расставьте приоритеты в плане аварийного восстановления в три уровня

Первый уровень DRP должен быть сфокусирован на оборудовании, приложениях и данных, которые были оценены как абсолютно важные для бизнес-операций и наиболее неотложные. Второй уровень восстановления включает в себя оборудование и приложения, которые также необходимы, но без которых бизнес может существовать в течение 10-24 часов. Таким образом, третий уровень — это оставшиеся аппаратные активы и приложения, которые должны быть эффективными для компании, но которые могут быть восстановлены в течение нескольких дней без заметного влияния.

Шаг 6: Сосредоточьтесь на персонале команды восстановления

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

Вспомогательный персонал также должен быть обучен вмешиваться в случае бедствия в то время, когда члены команды могут заболеть или в отпуске. DRP должен определить ключевые роли и назначить конкретные обязанности для каждого человека в команде. Необходимо четкое понимание относительно шагов, которые необходимо предпринять после того, как руководитель группы восстановления объявил о бедствии, последовательности этих шагов и того, как взаимосвязаны функции и обязанности команды. Четкая картина «кто за что отвечает» абсолютно критична; это порождает универсальное понимание плана восстановления и способствует его эффективному выполнению. 

Шаг 7: Разработайте план коммуникации

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

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

Шаг 8. Включение информации о расположении резервной рабочей площадки

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

Ведение плана аварийного восстановления

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

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *