Disaster Recovery - возможности

Disaster Recovery (DR) или катастрофоустойчивость – порядок восстановления работы бизнеса после серьезной аварии. В современном цифровом мире это в значительной степени относится к ИТ инфраструктуре компании.

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

Главная задача компании – это грамотно просчитать риски. Disaster Recovery позволяет найти баланс между минимизацией ущерба для бизнеса и затратами на резервирование системы. Это дает возможность обеспечить стабильное развитие бизнеса.

Что такое Disaster Recovery или аварийное восстановление в облако?

Disaster Recovery или катастрофоустойчивость – это набор оборудования, правил и методик для восстановления работы всей ИТ инфраструктуры компании. Инструмент для работы с критическими сбоями, основная задача которого максимально быстрое восстановление нормального функционирования бизнеса. Отказ серверной или целого ЦОДа не должен надолго прервать бизнес процессы.

В основу Disaster Recovery заложено два основных параметра:

• RPO (Recovery Point Objective) – максимальная потеря данных
• RTO (Recovery Time Objective) – максимальное время простоя

Рассмотрим их подробнее

RPO - это периодичность резервного копирования. Частота бэкапа зависит от сферы деятельности компании, критичности информации и финансовых возможностей.

Для банков период RPO будет меньше, чем для мелкой компании продающей изделия hand-made. В случае аварии мы можем потерять данные за период меньший RPO. Например, если резервное копирование производится раз в час, то при аварии максимальная потеря данных будет меньше часа.

RTO – это максимальное время простоя. Величина времени простоя также определяется видом деятельности компании, возможными убытками и финансовыми возможностями. Например. Если RTO составляет 20 минут, то не позже этого срока вся ИТ инфраструктура должна функционировать с сохраненными до аварии данными.

Для непосредственного восстановление системы составляется Disaster Recovery Plan (DRP) или план аварийного восстановления.

Возможности аварийного восстановления

В зависимости от решаемых задач аварийное восстановление можно разделить на несколько категорий

Резервное копирование и восстановление работы в облаке (DRaaS)

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

Параллельная инфраструктура в облаке

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

Репликация бывает активной и пассивной. При пассивной репликации основная система передает данные дублирующей. При активной репликации обе системы равноправны и получают данные одновременно.

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

Параллельная инфраструктура в дополнительной серверной (ЦОД)

Предыдущие варианты Disaster Recovery Plan основывались на использовании облачных технологий. Но в ряде случаев, по соображениям безопасности параллельная инфраструктура создается в компании без использования внешних связей. К примеру, крупные заводы имеют две и более территориально разнесенных серверных (ЦОД). Каждая серверная имеет дублирующий набор серверов, систем хранения и сетевого оборудования. Данные активно реплицируются и выход одной серверной из строя не оказывает влияния на технологический цикл. Это решение наиболее надежно, но имеет самую высокую стоимость.

Как работает Disaster Recovery as a Service (DRaaS)?

Стоимость этого решения зависит от частоты резервного копирования и готовности резервных серверов.

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

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

DRP - план аварийного восстановления в облако

Как у мультипликационного персонажа «мистера Фикса», в любой компании должен быть план аварийного восстановления информационной системы (Disaster Recovery Plan). Оформленный, актуализированный и изученный всеми сотрудниками он должен ждать своего часа.

Примеры Disaster Recovery Plan - как это выглядит?

План аварийного восстановления информационной системы может выглядеть следующим образом:

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

В качестве примера можно взять шаблон Disaster Recovery Plan от компании TechTarget.

Как разрабатывается DRP?

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

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

Рассмотрим эту работу по пунктам:

Список контактов персонала

Актуализируйте контакты Ваших сотрудников. У ключевых специалистов ИТ инфраструктуры необходимо попросить резервные каналы связи (родственники, друзья). Информированность руководства о местонахождении работников уменьшает время решения проблемы. Один из руководителей в шутку сформулировал свои требования к ИТ-администраторам: «Эти люди не должны веселиться в одной компании, ездить на одном автомобиле и летать одним самолетом». В каждой шутке есть доля шутки.

Чем полнее будет этот список, тем меньше времени понадобится на поиск человека.

Список систем и сервисов

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

Ответственные за системы и сервисы

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

• Добавить заместителей на случай отпуска или болезни.
• Проверить связку знания-умения-навыки (ЗУН) работников и обучить в случае необходимости.
• Проверить уровни доступа каждого работника и работоспособность основных и аварийных паролей.
• Зафиксировать распределение документально. Ознакомить всех сотрудников с этим документом.

В документе указывают ответственных за связанные с системой №1 сервисы и системы. Допустимо дублирование информации о контактах, в момент аварии искать информацию будет некогда.

Внешние контакты

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

Дерево инцидента

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

Вариант взаимодействия при нештатной ситуации.

Документирование процессов

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

Резервное копирование

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

Оценка рисков

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

1. Идентификация рисков. На этом этапе рассматриваются любые возникающие риски, от пропадания электропитания, до потери ключа от серверной комнаты.
2. Оценка рисков. Все выявленные риски расставляются по степени их влияния на работу ИТ инфраструктуры.
3. Выбор способа воздействия на риски. Для каждого риска есть несколько возможностей:
   • Избежать. Например, поставить дизель-генератор на случай отключения электричества
   • Принять. Заложить в бюджет возможные убытки.
   • Разделить. Заложить в договоре возможность аварии.
   • Смягчить. Например, заказать дубликат ключей от серверной.
   • Снизить. Создать план действий при наступлении риска.
   • Передать. Застраховать возможный ущерб
4. Разработка действий по управлению рисками. Создание Disaster Recovery Plan
5. Мониторинг и оценка результатов по управлению рисками. Оценка результатов тестовых испытаний и реальной работы Disaster Recovery Plan

Оценку рисков можно провести самостоятельно, но лучше пригласить сторонних специалистов. Посторонний человек может увидеть и оценить то, что привычно глазу работника компании, но в реальности составляет риск. Этот эффект описывал поэт: «Лицом к лицу Лица не увидать, большое видится на расстоянье». Привычное не значит правильное.

Примеры рисков:

• Технологические. К вашим серверам перестали поставлять запчасти и осуществлять поддержку. Низкий уровень отказустойчивости серверов
• Природные. Ваш ЦОД находится в зоне затопления при разрушении плотины местной ГЭС.
• Внутренние. Недостаточный уровень квалификации. Болезнь сотрудника. Ошибки при составлении документации.

Вместе с оценкой рисков оцениваются и бизнес процессы компании по уровню важности:

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

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

На основании полученных данных строятся два графика с точками безубыточности:

• Точка пересечения стоимости данных и стоимости резервного копирования покажет оптимальные затраты на RPO.
• Точка пересечения стоимости простоя системы и стоимости резервирования даст оптимальный уровень затрат на резервирование системы и допустимое время простоя (RTO).

На основании этих оценок строится стратегия Disaster Recovery Plan.

Составление Disaster Recovery Plan по каждому сервису

Каждый сервис или система должен иметь свой план аварийного восстановления.

В нем должно отображаться:

• Серверы, системы хранения информации, сетевое оборудование способы соединения и настройки. Месторасположение оборудования;
• Серийные номера, номера договоров поставки, сопровождения и другая информация для работы с горячими линиями;
• Резервное оборудование и его месторасположение;
• Наличие запасных частей и место их хранения;
• Состав команды Disaster recovery, их роли в восстановлении, адреса и телефоны;
• Резервные пароли администраторов для каждой системы. Могут быть в запечатанном конверте на аварийный случай;
• Горячие линии производителей оборудования и внешних сервисов. Основные и дополнительные способы связи с ними;
• Пошаговые сценарии устранения различных неисправностей;
• Отчеты о проведенных ранее восстановлениях и возникших проблемах;
• Отчеты о проведенных тестовых восстановлениях;
• Любая другая информация, которая поможет в работе.

Варианты оформления могут быть разными. В процессе тестовых отработок Disaster Recovery Plan пункты могут добавляться и видоизменяться. Каждый план индивидуален. В критической ситуации у Вас не будет времени искать телефон провайдера, IP адрес маршрутизатора или пароль администратора сервера – вся эта информация должна быть под руками.

Решение от Smart Office

Для клиентов Smart Office предлагает различные варианты резервного копирования в облако. Это могут быть:

• Копии файлов и папок
• Копии физических и виртуальных серверов
• Копии приложений и служб

Более подробно с этими предложениями вы можете ознакомиться на нашем сайте.

Резервное копирование в облако