Атака БПЛА Ozon в Саратове снова показала, что логистика маркетплейсов стала не только вопросом складских метров и курьеров, но и частью инфраструктурной устойчивости бизнеса. В здании склада начался пожар, сотрудников эвакуировали, а приём и доставка заказов в Саратове и области временно остановлены.
О происшествии сообщает vc.ru со ссылкой на данные маркетплейса. По предварительной информации Ozon, пострадавших нет, на площадке работают экстренные службы. Компания скрыла товары, размещённые на саратовском складе, с витрины, чтобы покупатели не оформляли заказы на позиции, которые сейчас физически недоступны или требуют проверки.
Для клиентов это выглядит просто: часть товаров исчезла из выдачи, доставка по региону поставлена на паузу, сроки по уже оформленным заказам могут сдвинуться. Для операционной команды маркетплейса ситуация куда неприятнее. Товары, которые уже были в пути, Ozon перенаправляет в другие логистические центры, а маршруты приходится перестраивать на ходу. В нормальный день такие изменения просчитываются заранее, в аварийный — система должна выдерживать ручные решения, перегрузку соседних узлов и шквал обращений в поддержку.
Саратовский инцидент не выглядит единичным сбоем. В источнике перечислена серия сообщений Ozon об атаках на склады в августе 2026 года: 22 августа компания говорила о складе в Самарской области, 23 августа — в Оренбургской, 24 августа — о площадках в Краснодаре, Невинномысске, Адыгейске и Махачкале, 27 августа — в Уфе, 29 августа — в Ростове-на-Дону. Теперь в этом списке оказался Саратов. Для рынка это уже не «неприятность на одной площадке», а сценарий, который нужно закладывать в архитектуру логистики.
Похожее давление испытывает не только Ozon. С 18 июля 2026 года атакам беспилотников, по данным источника, неоднократно подвергались склады Wildberries: в Котовске, Электростали, Краснодаре, Подольске, Екатеринбурге, Ленинградской, Тульской, Пензенской, Самарской, Волгоградской, Воронежской и Владимирской областях, а также в других регионах. Конкуренты в e-commerce обычно любят спорить о комиссиях, скорости доставки и рекламных кабинетах, но здесь проблема общая: распределённая торговля зависит от крупных физических узлов, а эти узлы оказались уязвимы.
Ozon уже анонсировал меры поддержки продавцов, пострадавших из-за атак, и планы начать размещать и продавать товары из пунктов выдачи заказов. Идея выглядит логично: если центральный склад временно выпадает, часть товарного запаса можно держать ближе к покупателю. Но для IT-команд это не кнопка «включить резерв». Нужны новые правила учёта остатков, пересчёт доступности товаров в реальном времени, обновление маршрутизации, интеграция ПВЗ в складские процессы и понятная логика компенсаций для продавцов.
Атака БПЛА Ozon также поднимает неприятный вопрос для продавцов маркетплейса: где заканчивается зона ответственности площадки и начинается риск самого бизнеса. Если товар хранится на складе платформы, предприниматель ожидает предсказуемой логистики, страховки и понятных SLA. Но при физическом повреждении склада важны не только юридические формулировки, а скорость коммуникации: какие партии затронуты, что скрыто с витрины, когда появится акт, как быстро восстановят продажи и кто компенсирует простой.
Для разработчиков и IT-директоров здесь есть отдельный урок. Резервирование в e-commerce больше нельзя понимать только как бэкап базы данных, второй дата-центр и очереди сообщений. Устойчивость теперь включает физические склады, транспортные плечи, региональные ограничения, динамическое управление ассортиментом и клиентские уведомления без паники. Система должна уметь быстро отвечать на скучные, но критичные вопросы: какие SKU лежали на площадке, какие заказы зависли, куда можно перебросить поток, какие продавцы попали в риск и что показывать покупателю в карточке товара.
Пока маркетплейсы перестраивают маршруты и тестируют более распределённые модели хранения, главный тренд уже виден: логистика превращается в область, где безопасность, продуктовая архитектура и операционный IT больше не живут по разным кабинетам. Следующий конкурентный разрыв может появиться не там, где быстрее доставляют в обычный день, а там, где сервис меньше ломается в день, когда один из крупных узлов внезапно исчезает из схемы.