Эффективность и коммерческие результаты IT-продуктов зависят от непрерывности их работы. Катастрофоустойчивость — одно из требований к инфраструктуре, которое позволяет поддерживать работоспособность оборудования. Для ее обеспечения создается система аварийного восстановления.
Даже использование последних технологий и резервирования мощностей в ЦОД не исключает сбои. Они могут быть результатом форс-мажоров, связанными с природными явлениями, например, крупными ураганами и землетрясениями, политическими или экономическими причинами. Те риски, которые не получится предусмотреть, необходимо учитывать при проработке disaster recovery. Что это, как работает система, как найти баланс между объективной необходимостью и расходами — расскажем в статье.
Риск-менеджмент IT проектов должен включать в себя планы по поддержке работоспособности бизнеса даже в условиях форс-мажоров. На прибыль компании влияет каждая минута, поэтому критично важные части системы должны работать без перебоев даже при аварийных ситуациях. Чтобы избежать простоев, потери данных, добиться моментального восстановления инфраструктуры, проводится резервирование ее элементов в облаке или на физическом оборудовании в другом ЦОД.
Disaster Recovery обеспечивает катастрофоустойчивость за счет создания резервной площадки для отдельных компонентов или полного клонирования системы и подготовки инструментов для восстановления. Два ключевых требования DR:
Зависимость компаний от IT-инфраструктуры постоянно растет. Даже малому бизнесу, не связанному с высокотехнологичными продуктами, для поддержки работоспособности нужно учитывать риски сбоев. DR помогает:
Параллельно созданная инфраструктура начинает работать при сбоях. В отличие от стандартных бэкапов, с которыми ее нередко путают, в ней хранятся не только данные, но и шаблоны виртуальных машин. Помимо защиты информации, ее задача — минимизироваться время простоя, взять на себя часть функций на время восстановления главной площадки.
Создать систему резервирования и аварийного восстановления можно разными способами. Главное — соблюдать требования автономности, географии и сетевой связанности.
Этот подход предполагает, что компания самостоятельно создает две одинаковые физические инфраструктуры. В случае сбоев в одной, включается другая. У этого метода есть три минуса:
Систему восстановления IT-инфраструктуры можно создать на арендованных у провайдера физических серверах. Резервный ЦОД надежнее с точки зрения геолокации. Организовать это проще, поскольку работу по дублированию могут выполнить инженеры дата-центра. Однако остается проблема с гибкостью: аренда оплачивается помесячно, а изменения требуют времени.
Большинство компаний выбирают этот способ для обеспечения катастрофоустойчивости. Причины:
Самый простой путь для компании — восстановление как услуга, или Disaster Recovery as a Service. Это готовый сервис, который облегчает задачи. Катастрофоустойчивую инфраструктуру провайдер прорабатывает за вас. Вместе с этим в цену часто входят консультации и бонусы.
При составлении плана DR компании принимают решения с учетом расходов и реальных потребностей бизнеса. Иногда менее значимыми характеристиками можно пожертвовать, чтобы сократить затраты. Для оценки используется два ключевых параметра: RTO и RPO.
Показатель связан с временем простоя, которое требуется на восстановление. Чем ниже показатель, тем быстрее проект начинает работать после сбоя и тем больше бизнес платит за это решение. Метрика отражает максимальное значение, то есть если RTO = 30 минут, инфраструктура этого проекта заработает не позднее, чем через полчаса.
Эта цифра критична для веб-приложений, интернет-магазинов и других компаний, чья прибыль генерируется только во время работы. Задача — не допустить, чтобы пользователи сталкивались со сбоями, потому что это влияет на доверие к бренду, его имидж, клиентский опыт. Для сайтов с небольшими объемами трафика требования ниже.
Если время влияет на сервис, то от RPO зависят объемы потерянных данных в аварийных ситуациях. На практике это частота резервного копирования: чем меньше показатель, тем меньше актуальной информации вы потеряете. При работе с сайтом это не так важно, как для SaaS-платформ, в которых постоянно фиксируются действия пользователей, а база обновляется каждые несколько секунд. Метрика также влияет на расходы бизнеса на организацию DR.
Универсального решения по определению уровня RPO и RTO — нет. Чтобы определить его, нужно оценить риски, опираясь на потребности проекта. Помогут следующие вопросы:
При проработке катастрофоустойчивого плана ответы на эти вопросы помогут объективно оценить риски, чтобы найти баланс.
Главный принцип при проработке плана — определение разных типов рисков. Резервный ЦОД нужно выбирать так, чтобы его обеспечение не было связано с основным, чтобы сбой не затрагивал оба дата-центра. Создать катастрофоустойчивый проект можно, только если вы предусмотрели возможности аварий природного характера, электросетей, интернет-каналов. Например, если основная инфраструктура расположена в Москве, а дополнительный ЦОД — в Санкт-Петербурге, то наводнения, ураганы и другие локальные явления не затронут работу.
Алгоритм по защите системы состоит из четырех действий:
От сбоев не застрахован ни один бизнес, работа которого связана с IT. Минимальный набор для защиты данных — настройка резервного копирования. Эта функция нужна всем, даже небольшим сайтам. Если же есть даже небольшая сетевая инфраструктура, бэкапов недостаточно — нужно прорабатывать DR. Чем выше потенциальный ущерб от простоев, тем сильнее потребность в системе для восстановления.
Например, для крупного банка или приложения авария может привести не только к финансовым потерям, но и навредить репутации. Неработающая несколько минут банковская карточка, потерянные данные о транзакциях, сбои в приложениях — все это создает пробелы для мошенников и снижает доверие к организации. Десять минут могут принести убытки на несколько миллионов рублей.
Со схожими проблемами сталкиваются и популярные сервисы — например, такси, доставка еды из ресторанов, маркетплейсы. Без параллельного ЦОД или резервов в облаке каждый простой приводит к потерям.
Для восстановления IT-проекта в облако чаще всего используется одно из двух технических решений:
Их главное отличие в минимальном RPO — в первом случае потерю данных можно сократить до 1 минуты, а во втором — до 5 минут. Однако второе решение проще в реализации: настройка по инструкции занимает около 15 минут, не нужно открывать дополнительные порты, а для управления создана единая панель. С Veeam работать сложно — тестировать систему нужно будет вручную.
Несмотря на это, облачные услуги не требуют сильной экспертизы — большинство задач выполняют провайдеры.
Даже самые продвинутые ЦОД уровня Tier III не могут давать стопроцентные гарантии бизнесу. Риски повреждения оборудования, простоев, серьезных сбоев в таких дата центрах минимальны. Несмотря на это, не все техногенные катастрофы можно предусмотреть. При резервировании форс-мажоры не так страшны, поскольку у вас будет готов план восстановления.
DR — это крайняя мера, которая многим компаниям никогда не пригодится. Однако если критическая аварийная ситуация произойдет, работа не встанет, а восстанавливать инфраструктуру этого проекта будет проще.
© 2023 Linx
