Все компании уверены, что информация — это ценный актив, но далеко не каждая из них принимает достаточные меры, чтобы защитить ее. Между тем использование таких регламентных мер, как создание планов восстановления после аварий — DRP (Disaster Recovery Plan), — может минимизировать негативные последствия аварийных ситуаций: от локальных сбоев оборудования до масштабных техногенных катастроф, затрагивающих ЦОД, и обеспечить быстрое и верное реагирование на инциденты.
Использование таких регламентных мер, как создание планов восстановления после аварий — DRP (Disaster Recovery Plan), — может минимизировать негативные последствия аварийных ситуаций
Важные аббревиатуры: RTO и RPO
Любой план восстановления создается с учетом индивидуальных параметров компаний. Он учитывает ключевые бизнес-процессы, существующие решения для обеспечения катастрофоустойчивости инфраструктуры и массу других факторов. Но в целом подход к созданию плана универсален. Его суть состоит в том, что сначала следует определить значения параметров RPO и RTO для всех подсистем предприятия, а затем сформировать стратегию восстановления этих подсистем после аварий: очередность, взаимосвязи, порядок конкретных мер ответственного персонала.
|
В качестве примера аварии рассмотрим отказ сервера. В классическом случае восстановление будет представлять собой последовательность шагов: обнаружение отказа, локализация причины, приобретение запчастей или сервера целиком на замену, установка и настройка, тестирование работоспособности.
Такой подход не требует предварительной подготовки, является реактивным и поэтому самым медленным. Однако даже при таком подходе нелишним будет проведение технического аудита IT-инфраструктуры, который, как правило, проводится внешними подрядными организациями, например системными интеграторами. По итогам проведенного обследования предприятие получает документированный результат, детально описывающий компоненты инфраструктуры и описание их функций. Наличие такого документа существенно убыстряет принятие верных решений в случае аварии.
Даже при классическом подходе нелишним будет проведение технического аудита IT-инфраструктуры, который, как правило, проводится внешними подрядными организациями, например системными интеграторами
Аудит и работа над ошибками
Аудит преследует несколько целей. Зачастую основная задача, которую позволяет решить аудит, — помочь владельцу IT понять, из каких подсистем и решений состоит его инфраструктура, и ранжировать их по степени важности для бизнеса. Помимо этого, аудит нужен, чтобы выявить возможные недочеты в ИТ-инфраструктуре. Если при ее создании и эксплуатации были допущены серьезные ошибки, то гарантировать сохранность данных в ней невозможно, тем более при неблагоприятных воздействиях. Подобные недочеты нередко встречаются в большинстве российских компаний.
Зачастую основная задача, которую позволяет решить аудит, — помочь владельцу IT понять, из каких подсистем и решений состоит его инфраструктура, и ранжировать их по степени важности для бизнеса
Следующим шагом после аудита должно быть исправление выявленных проблем. Обычно оно заключается в правильном конфигурировании имеющегося оборудования и ПО, а также в резервировании, дублировании каналов связи и мест хранения и обработки информации. Результатом этой работы должна быть такая конфигурация IT-инфраструктуры, которая соответствует двум фундаментальным принципам:
1. Вся важная информация хранится в нескольких экземплярах, желательная конфигурация: один — оригинал, второй — синхронная копия (зеркальная реплика, создаваемая в реальном времени), третий — удаленная асинхронная копия (резервная копия, бэкап); каждый экземпляр находится на отдельном носителе.
2. Вся важная информация не привязана к конкретному оборудованию: она хранится в стандартных форматах, всегда можно перенести ее на другое доступное оборудование и продолжить работу.
Три копии данных — это дешево и просто. Их легко создать: двумя носителями могут служить жесткие диски в зеркалируемом массиве RAID, а третьим — любой отторгаемый носитель. Стоимость такого решения невелика. Разумеется, в серьезном бизнесе качество решений должно быть на порядок выше, но принцип остается тем же — размещение данных в нескольких (желательно территориально распределенных) хранилищах и механизм синхронизации между копиями данных.
В серьезном бизнесе качество решений должно быть на порядок выше, но принцип остается тем же — размещение данных в нескольких (желательно территориально распределенных) хранилищах и механизм синхронизации между копиями данных
