Бизнес больше не может позволить себе остановку цифровых процессов

Облачная инфраструктура становится частью устойчивости бизнеса

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

На первый план выходит устойчивость бизнеса. Руководству важно понимать, сможет ли компания продолжить работу при недоступности одной из критичных ИТ-систем. Как остановка ERP отразится на производстве, закупках, расчетах и отгрузках? Сколько времени бизнес может работать без ключевой системы? Какой объем данных допустимо потерять?

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

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

Зависимость бизнеса от цифровых систем продолжает расти. Сегодня сбой ERP может затронуть сразу несколько процессов — от производства и закупок до расчетов и отгрузок. Недоступность CRM осложняет взаимодействие с клиентами, а проблемы с финансовыми системами могут лишить руководство актуальной информации для принятия решений.

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

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

Гораздо важнее понимать, насколько инфраструктура готова поддержать непрерывность критичных бизнес-процессов при аварии.

Проектирование начинается с бизнес-процессов

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

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

От ответа зависит архитектура всей инфраструктуры. Нужно определить критичные бизнес-процессы, допустимую продолжительность простоя, приемлемый объем потери данных и последовательность восстановления систем.

Только после этого можно выбирать конкретные технические решения.

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

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

Поэтому Disaster Recovery следует рассматривать не как отдельную ИТ-технологию, а как комплексный сценарий обеспечения непрерывности бизнеса.

Сценарии восстановления необходимо тестировать

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

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

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

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

Приоритеты восстановления должны определяться потребностями бизнеса.

Как обеспечить устойчивость корпоративных систем

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

После этого формируется подходящая инфраструктурная архитектура.

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

Облачная платформа CorpSoft24 позволяет объединить размещение корпоративных информационных систем, резервное копирование, восстановление данных, отказоустойчивые конфигурации и Disaster Recovery в едином инфраструктурном контуре.

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

Устойчивость и информационная безопасность — единый контур

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

Это особенно важно учитывать при создании резервной инфраструктуры.

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

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

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

Эти направления необходимо рассматривать как единый контур устойчивости.

Что важно изменить в подходе к устойчивости бизнеса

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

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

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

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

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

Бизнес инвестирует уже не только в возможность восстановиться после аварии. Он инвестирует в способность продолжать работу во время нее.