С 8 по 14 октября российская IT- инфраструктура столкнулась с серией атак: беспилотники последовательно вывели из строя три дата-центра Яндекса в Сасово (Рязанская область), Калуге и Владимире, а затем ЦОД Сбербанка в Балаково Саратовской области. ЦОД во Владимире был полностью остановлен, облачная платформа Yandex Cloud перешла в аварийный режим. Пользователи по всей стране сообщали о сбоях в работе банковских приложений, мобильных операторов, хостинг-провайдеров, сервисов доставки и такси. Падение акций Яндекса составило 8%.
Для гостиничного бизнеса этот инцидент стал проверкой на устойчивость: отели, чьи PMS, каналы продаж и платёжные шлюзы размещены в облаках пострадавших провайдеров, на несколько дней потеряли возможность заселять гостей, принимать бронирования и проводить платежи. На фоне этих событий Минцифры совместно с Минобороны начало прорабатывать меры защиты ЦОДов, включая размещение под землёй и информационную маскировку.
Мы поговорили с ведущими поставщиками IT-решений для гостиничного бизнеса и узнали, как архитектура их продуктов позволяет отелям переживать подобные катастрофы.
Эквио: офлайн-режим работает только с подготовкой заранее, а данные теперь живут в другом облаке
— В обновлении Эквио появилась возможность проводить аудиты без интернета, а курсы можно скачивать заранее. Но если у отеля пропал интернет на ресепшн, может ли сотрудник пройти обязательный вводный инструктаж или тест по безопасности с телефона, если контент не был скачан заранее? Или офлайн-режим требует ручной подготовки, которая не всегда возможна при внезапном сбое?
CEO Алексей Вагин, CEO «Эквио»: Офлайн-режим требует, чтобы необходимые материалы уже находились на устройстве. Если сотрудник не загрузил контент заранее и у телефона полностью отсутствует связь, получить новый курс с сервера он не сможет.
При этом отсутствие интернета на ресепшн не всегда означает отсутствие доступа к платформе: если на телефоне работает мобильный интернет и сервис доступен, сотрудник может использовать его.
Для аудитов подготовка устроена так: достаточно открыть нужный аудит при наличии связи и дождаться загрузки. Он сохранится в мобильном приложении и станет доступен офлайн. Без интернета можно заполнять аудит и сохранять черновики. Как только соединение появится, их можно будет отправить на проверку.
— После атаки на дата-центр Яндекса вы восстанавливали сервисы, но резервное копирование за тот день не успело завершиться на всех окружениях. Какие данные клиентов в итоге оказались утрачены или откачены? Затронуло ли это данные о прогрессе обучения сотрудников отелей, или потеря ограничилась техническими логами? Что компания сделала, чтобы клиенты не потеряли подтверждения прохождения обязательных инструктажей?
CEO Алексей Вагин, CEO «Эквио»: Мы регулярно создаём резервные копии данных. После инцидента восстановили системы из доступных копий и помогали клиентам восстанавливать недостающие результаты прохождения обучения. Основной объём данных удалось восстановить из бэкапа; дополнительной работы потребовали преимущественно результаты за субботу, 10 октября.
Отдельно прокомментировать прогресс сотрудников отелей сложно: мы работали со всеми затронутыми клиентами, без выделения конкретной отрасли.
Подробнее о ходе восстановления и принятых решениях наш CEO Алексей Вагин рассказал в статье «Хроники 11 октября. Как мы восстанавливали Эквио после атаки на дата-центр Яндекса».
— Серверное размещение позволяет держать данные внутри инфраструктуры клиента. Кто отвечает за резервное копирование и отказоустойчивость в этом сценарии — IT-команда отеля или Эквио? Если отель разместил платформу у себя, но его собственный дата-центр атакован, остаётся ли у Эквио какой-либо механизм восстановления, или клиент остаётся один на один с проблемой?
CEO Алексей Вагин, CEO «Эквио»: У Эквио есть несколько тарифов и вариантов серверного размещения с разным распределением ответственности. В одном варианте компания-клиент берет на себя обслуживание инфраструктуры и связанные с ней риски, включая создание и хранение резервных копий. В другом предусмотрено полноценное сопровождение со стороны Эквио: эти задачи входят в нашу зону ответственности.
Порядок восстановления при недоступности дата-центра клиента зависит от выбранного тарифа и согласованной схемы резервирования. Все условия определяются еще на этапе подготовки инфраструктуры и закрепляются в договоре.
— Какие уроки вы извлекли из инцидента с дата-центром и изменили ли архитектуру резервирования? Были ли с тех пор внедрены геораспределённое резервное копирование или автоматическое переключение на альтернативного провайдера, или по-прежнему используется схема с зарезервированными мощностями, куда можно развернуть копии? Как вы видите ответственность между Эквио и отелем, если из-за сбоя платформы сотрудник не смог вовремя пройти обязательное обучение по безопасности и это привело к инциденту? Есть ли у Эквио рекомендации по резервированию критических инструктажей на случай длительного простоя?
CEO Алексей Вагин, CEO «Эквио»: Инцидент подтвердил на практике работоспособность заранее подготовленного сценария восстановления и экспертность нашей технической команды. Специалисты действовали по согласованному плану и восстановили работу инфраструктуры на другой площадке.
После инцидента клиентские окружения перенесены из Yandex Cloud на Cloud.ru. Сейчас Cloud.ru — основной облачный провайдер Эквио. При этом мы сохраняем практику распределенного резервного копирования.
Сейчас команда работает над дополнительными мерами защиты данных и сокращением времени восстановления при возможных будущих инцидентах. Наша задача — обеспечить клиентам более высокий уровень сохранности и доступности данных.
bnovo: ставки на один ЦОД больше нет — резервы в Selectel, Cloud.ru и VK Cloud
— Три ЦОДа Яндекса были атакованы последовательно в течение недели — Сасово, Калуга, Владимир. Если площадка, на которой размещен bnovo, выйдет из строя аналогичным образом, каков ваш план переключения? Есть ли резервная площадка в другом регионе с автоматическим перераспределением нагрузки?
Илья Зимин, технический директор bnovo: Инфраструктура bnovo была распределена между несколькими зонами доступности Яндекс Облака. Автоматическое перераспределение нагрузки между ними позволяло продолжать работу при выходе отдельных площадок из строя.
Сейчас у Яндекса ограничены дополнительные резервные мощности, поэтому мы создаем резервы у других облачных провайдеров. Резервирование в Selectel уже готово, в Cloud.ru и VK Cloud еще готовится. При дальнейшей недоступности площадок планируем переключаться на работающие дата-центры. По мере восстановления и появления дополнительных мощностей Яндекс Облака мы также будем их использовать.
— Вы уже реализовали офлайн-шахматку, которая автоматически запускается при потере интернета и обновляет данные каждые 10 минут. Какой объем функциональности доступен отельеру в этом режиме, только просмотр или также заселение, выселение и проведение платежей? Как происходит синхронизация после восстановления связи?
Илья Зимин, технический директор bnovo: Офлайн-шахматка доступна только для просмотра информации о бронированиях. Ее первоначальная задача — помочь администратору работать при отсутствии интернета. Изменение бронирований офлайн и последующая синхронизация с сервером сейчас не реализованы.
Такой сценарий требует отдельной проработки, особенно при подключенных внешних каналах продаж. С учетом последних событий мы включили эту задачу в бэклог.
— bnovo использует хостинг с защитой персональных данных по 152-ФЗ. Расположен ли этот хостинг в ЦОДе, который можно считать защищенным от физических атак? Рассматриваете ли вы переход на подземные или географически распределенные площадки?
Илья Зимин, технический директор bnovo: Все облачные провайдеры, которыми мы пользуемся, находятся в России и соблюдают требования 152-ФЗ.
Для повышения устойчивости мы уже используем географически распределенные дата-центры Яндекс Облака. Сейчас дополнительно создаем резервы у других провайдеров, которые также располагают географически распределенными площадками.
Следим за предложениями подземных ЦОДов на рынке, чтобы рассмотреть и такие варианты размещения инфраструктуры.
— Какие выводы вы сделали для архитектуры своих продуктов после серии атак на ЦОДы Яндекса и Сбера? Что изменилось или изменится в ближайшие месяцы?
Илья Зимин, технический директор bnovo: Мы последовательно вкладываем ресурсы в стабильность bnovo, в том числе используем географически распределенные дата-центры. Текущая ситуация показала, где мы можем дополнительно повысить отказоустойчивость системы.
Главное текущее изменение — резервирование у нескольких облачных провайдеров. Размещение всех мощностей у одного провайдера стало более рискованным, поэтому мы расширяем список провайдеров, у которых создаем резервы. Наша цель — обеспечить непрерывность рабочих процессов клиентов.
— Депутат Горелкин предложил строить распределенную архитектуру ЦОДов с географическим разносом и автоматическим перераспределением нагрузки. Насколько это реализуемо для гостиничного сегмента с учетом стоимости и масштабов отелей?
Илья Зимин, технический директор bnovo: В bnovo уже используются географически распределенная инфраструктура и автоматическое перераспределение нагрузки. Чтобы оценить предложенную модель и ее отличие от существующих решений, нужны конкретные параметры. После этого можно будет рассчитать затраты и оценить экономическую целесообразность.
— Георезервирование, подземные ЦОДы, резервные площадки — все это требует инвестиций. Кто, по вашему мнению, должен нести эти затраты: поставщик, отель или государство? Насколько вырастет стоимость решений, если закладывать защиту от физических атак?
Илья Зимин, технический директор bnovo: Пока сложно сказать, как именно распределятся эти затраты между поставщиками, отелями и государством. Дополнительные меры защиты потребуют инвестиций, объем которых будет зависеть от выбранных решений.
В конечном счете рост расходов может отразиться и на стоимости проживания для гостей. Оценить масштаб подорожания можно будет после определения конкретных мер защиты и затрат на их реализацию.
— Традиционно под киберустойчивостью понимали защиту от хакеров. События октября показали, что физическая атака на ЦОД может быть не менее разрушительной. Как это меняет подход к проектированию инфраструктуры?
Илья Зимин, технический директор bnovo: Физические атаки дополнили перечень рисков, которые необходимо учитывать при проектировании инфраструктуры. Среди других причин выхода дата-центра из строя — природные катаклизмы и различные аварийные ситуации.
Мы изначально закладывали риск выхода отдельного ЦОДа из строя и продолжим учитывать его при развитии инфраструктуры. Система должна быть отказоустойчивой и готовой к выходу любой из зон. Наша цель как компании — обеспечить непрерывность рабочих процессов клиентов.
Libra Hospitality: эпоха Cloud First закончилась, начинается эпоха Resilience First
— События октября — атаки на три ЦОДа Яндекса и ЦОД Сбера — показали, что происходит с отелями, полностью зависящими от облачной PMS. Можно ли утверждать, что on-premise-архитектура Logus полностью исключает для отеля риск потери доступа к системе при атаке на внешний дата-центр? Какие сценарии всё же остаются уязвимыми?
Сергей Фомин, директор Libra Hospitality: Да, мы можем утверждать, что on-premise архитектура полностью исключает паралич операционной деятельности отеля. Если падает внешний ЦОД (как это было в октябре), наша система Logus HMS этого даже не замечает на уровне базовых процессов, так как сервер стоит физически внутри здания отеля. Администраторы продолжают работать, система «летает» без задержек.
Но мы должны быть честны: отель не существует в вакууме. Уязвимыми остаются внешние шлюзы. Что отвалится: перестанут приходить новые бронирования от агрегаторов (Channel Manager), если упал их ЦОД. Заблокируются облачные сервисы рассылок email-уведомлений. В чем наше отличие: В SaaS-модели при падении ЦОДа вы теряете всё — вы даже не знаете, кто живет в номере 302, и не можете выдать ключ. В Logus HMS вы теряете только внешний трафик, но сохраняете 100% контроль над объектом, историей гостей, финансами и инфраструктурой. Вы продолжаете оказывать премиальный сервис тем, кто уже заехал.
— Вы отмечаете, что ваша архитектура способна работать при нестабильном интернете. Что именно происходит с PMS отеля, если интернет пропадает на 24–72 часа? Какие функции остаются доступны, а какие блокируются?
Сергей Фомин, директор Libra Hospitality: Мы называем это стандартом Zero Downtime (Нулевой простой). Если экскаватор перерубил оптику и отель остался без связи на трое суток, Logus HMS продолжает управлять зданием.
Что работает штатно (100%): Заселение и выселение гостей, печать фискальных чеков (кассы могут работать в офлайн-режиме до 30 дней по закону), кодирование электронных замков (система общается с энкодером по локальной сети), внутренние начисления из ресторана (интеграция с POS-системами), выгрузка любых управленческих отчетов.
Что временно блокируется: Прием оплат по банковским картам (эквайрингу нужен интернет, придется перейти на наличные или СБП по QR, если работает мобильная связь), получение онлайн-броней с сайта и автоматическая выгрузка данных в УФМС (придется выгрузить файл локально и отправить позже).
Как только интернет возвращается, HOS автоматически синхронизирует накопившиеся пакеты данных с внешним миром.
— В ваших материалах подчёркивается, что сисадмин отеля, скорее всего, не является специалистом по информационной безопасности. Как on-premise-решение компенсирует этот дефицит? Кто отвечает за обновления безопасности и мониторинг угроз на локальном сервере отеля?
Сергей Фомин, директор Libra Hospitality: Это главный миф, которым пугают облачные вендоры: «купите сервер, и вас взломают, потому что ваш сисадмин — студент». Во-первых, on-premise система гостиницы по умолчанию не «торчит» открытыми портами в публичный интернет. Это закрытый контур. Чтобы взломать локальный сервер, хакеру часто нужно физически проникнуть в сеть отеля. Облако же доступно для DDoS и брутфорса отовсюду 24/7. Во-вторых, мы не бросаем клиента. Мы перешли от модели «продали коробку» к моделиManaged On-premise. Наши инженеры Libra Hospitality настраивают защищенные VPN-туннели, через которые мы сами мониторим состояние серверов, накатываем патчи безопасности и обновляем систему. Отелю не нужно держать в штате дорогого ИБ-офицера — мы забираем эту экспертизу на себя в рамках договора техподдержки, оставляя данные физически у клиента.
— Какие выводы вы сделали для архитектуры своих продуктов после серии атак на ЦОДы Яндекса и Сбера? Что изменилось или изменится в ближайшие месяцы?
Сергей Фомин, директор Libra Hospitality: События октября подтвердили нашу стратегию: мы отказываемся от концепции PMS (просто шахматка) и переходим к HOS (Hotel Operation System) с фокусом на Edge Computing (граничные вычисления).
Мы будем усиливать локальную автономность. Например, наши новые AI-модули (тот же CallScore AI для анализа звонков). Рынок привык отправлять аудиофайлы на расшифровку в облака Яндекса или Сбера. После атак на их ЦОДы многие отели остались без аналитики. Мы же инвестируем в то, чтобы тяжелые алгоритмы (включая нейросети) могли локально разворачиваться на серверных мощностях самого отеля. Данные не покидают периметр, а значит, внешние атаки на ИТ-гигантов нам не страшны.
— Депутат Горелкин предложил строить распределённую архитектуру ЦОДов с географическим разносом и автоматическим перераспределением нагрузки. Насколько это реализуемо для гостиничного сегмента с учётом стоимости и масштабов отелей?
Сергей Фомин, директор Libra Hospitality: Для отдельного отеля строить собственный геораспределенный ЦОД — это финансовое самоубийство. Но парадокс в том, что on-premise архитектура тысяч отелей — это и есть идеальная геораспределенная сеть в масштабах страны.
Если все отели сидят в одном облаке (например, в ЦОДе Яндекса), то атака на этот ЦОД «кладет» индустрию гостеприимства целого региона. Если каждый отель имеет свой локальный сервер (On-premise), то уничтожить ИТ-инфраструктуру отрасли физически невозможно — нет единой точки отказа. Децентрализация — это и есть высшая форма безопасности, которую мы предлагаем рынку.
— Георезервирование, подземные ЦОДы, резервные площадки — всё это требует инвестиций. Кто, по вашему мнению, должен нести эти затраты: поставщик, отель или государство? Насколько вырастет стоимость решений, если закладывать защиту от физических атак?
Сергей Фомин, директор Libra Hospitality: Если мы говорим про SaaS-вендоров, они будут вынуждены инвестировать в эти подземные ЦОДы, и эти миллиардные затраты лягут в OPEX (ежемесячную подписку) для отелей. Облачные PMS неизбежно подорожают в разы.
Для наших клиентов (On-premise) стоимость владения (TCO) не изменится. Капитальная инвестиция (CAPEX) в стандартный отказоустойчивый сервер и ИБП (источник бесперебойного питания), который стоит в охраняемой серверной отеля, уже обеспечивает 99% защиты от физических атак. Затраты несет отель, но это разовая инвестиция в собственный капитальный актив, которая окупается за 1,5–2 года по сравнению с растущими аппетитами SaaS-провайдеров.
— Традиционно под киберустойчивостью понимали защиту от хакеров. События октября показали, что физическая атака на ЦОД может быть не менее разрушительной. Как это меняет подход к проектированию инфраструктуры?
Сергей Фомин, директор Libra Hospitality: Это меняет всё. Эпоха «Cloud First» (сначала облака) в критической инфраструктуре закончилась. Начинается эпоха «Resilience First» (сначала отказоустойчивость).
Гостиница — это режимный объект жизнеобеспечения. Вы не можете выгнать 500 человек на улицу зимой из-за того, что где-то сгорел серверный шкаф провайдера. HOS-архитектура возвращает управление туда, где происходит бизнес-процесс — на землю, в сам отель. Физическая безопасность вашего локального сервера обеспечивается вашей же службой безопасности. Это прозрачно, надежно и полностью соответствует духу 152-ФЗ.
Подытожим
Октябрьские атаки на дата‑центры стали для гостиничного бизнеса не просто ИТ‑сбоем, а стресс‑тестом всей модели цифровой инфраструктуры. Инцидент показал: зависимость от единого облачного провайдера — это единая точка отказа, которая способна парализовать операционную деятельность отеля: от заселения гостей до проведения платежей.
На фоне этого поставщики решений предлагают разные пути повышения отказоустойчивости — и в позициях экспертов чётко прослеживается спектр подходов. Гибридный офлайн и резервное копирование (как у «Эквио») помогают сохранить критически важные процессы при потере связи, но требуют предварительной подготовки: материалы и аудиты должны быть заранее загружены на устройства. Мультиоблачная стратегия (позиция bnovo) снижает риски за счёт географического распределения и резервирования у нескольких провайдеров. При этом даже в таком сценарии часть функциональности (например, офлайн‑изменение бронирований) остаётся ограниченной, а дополнительные меры защиты неизбежно ведут к росту затрат — в конечном счёте это может отразиться и на стоимости услуг для гостей. Локальная автономность и концепция HOS (Libra Hospitality) делает ставку на полный контроль отеля над собственной инфраструктурой: при отключении интернета ключевые процессы (заселение, выселение, печать чеков, кодирование замков, внутренние начисления) продолжают работать. Переход к Edge Computing и локальному исполнению даже «тяжёлых» алгоритмов (вроде AI‑аналитики) позволяет исключить зависимость от внешних облаков и минимизировать риски при физических атаках на крупные ЦОДы.
Для отельеров главный вывод звучит однозначно: устойчивость бизнеса теперь определяется не только функциональностью системы, но и её способностью продолжать работу при полном отсутствии связи и при выходе из строя внешних дата‑центров. Выбор архитектуры — будь то мультиоблако, усиленный офлайн‑режим или on‑premise с управляемой поддержкой — должен опираться на оценку рисков, критичности процессов и стоимости простоя. В условиях, когда физическая атака способна остановить облачные сервисы, стратегия «Resilience First» (отказоустойчивость прежде всего) становится не опцией, а необходимостью.
