Почему сбои дата-центров Яндекса стали тревожным сигналом для бизнеса Узбекистана

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

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

Дата-центр — это здание с большим количеством серверов: компьютеров, которые обеспечивают работу сайтов и приложений. Когда компания пользуется «облаком», она арендует такие компьютеры и связанные с ними услуги у провайдера. За словом «облако» всегда стоят реальные здания, электроснабжение и линии связи.

Что произошло

В течение нескольких дней Яндекс сообщил об атаках на три площадки. В ночь с 7 на 8 октября серьёзно пострадал дата-центр в Сасово, его работу остановили. 9 октября атака затронула площадку в Калуге, где вышла из строя часть оборудования. В ночь на 11 октября был атакован дата-центр во Владимире, его работа также остановлена.

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

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

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

Как это отразилось на Узбекистане

8 октября произошёл сбой Uzum Market, затронувший работу маркетплейса, складов и пунктов выдачи. Однако считать его установленным следствием атаки на Яндекс нельзя.

В комментарии Spot пресс-служба Uzum объяснила неполадки плановым обновлением систем. Компания сообщила, что использует собственное оборудование и облачные серверы на территории Узбекистана. Uzum Bank заявил, что работает в штатном режиме и сбой маркетплейса не затронул его сервисы. Материал Spot с комментариями компаний.

11 октября перебои наблюдались и в части сервисов Yandex Go в Узбекистане. По информации UzDaily, представители Yandex Uzbekistan на момент публикации не уточнили, связаны ли местные проблемы с инцидентом в России. Сообщение UzDaily.

Следовательно, нельзя утверждать, что Uzum и узбекский сервис такси целиком работают на Yandex Cloud и остановились по одной причине. Но эти события ставят перед бизнесом общий вопрос: как обслуживать клиентов, если основная компьютерная система перестала работать?

Почему крупный поставщик не гарантирует бесперебойную работу

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

Однако надёжность поставщика и готовность клиента к аварии — разные вещи.

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

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

Даже несколько площадок не всегда обеспечивают полную защиту. Они могут зависеть от одних систем управления или одновременно столкнуться с общей угрозой. Сам Yandex Cloud предупреждает: после отказа одной зоны свободные ресурсы в остальных расходуются быстрее. Рекомендации провайдера.

Что могло бы уменьшить последствия

Без доступа к внутренним системам Uzum и Yandex Go нельзя установить, какие меры у них уже действовали и что именно предотвратило бы конкретный сбой. Но для компаний с похожими рисками есть несколько практических решений.

Первое — иметь подготовленную запасную площадку.

Компания может разместить резерв у другого поставщика или на собственном оборудовании. Главное — убедиться, что он сможет работать при остановке основной системы.

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

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

Второе — хранить отдельные копии важных данных и проверять их.

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

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

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

Третье — предусмотреть работу с ограниченными возможностями.

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

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

Однако есть предел: если система не может достоверно проверить оплату или наличие товара, принимать новую операцию опасно. Лучше объяснить временное ограничение, чем дать клиенту обещание, которое компания не сможет выполнить.

Четвёртое — осторожно внедрять обновления.

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

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

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

Пятое — проводить учения до настоящей аварии.

Руководству нужны понятные ответы на два вопроса: сколько времени потребуется для восстановления и какие последние операции могут не сохраниться?

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

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

Шестое — заранее продумать общение с клиентами.

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

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

Почему нельзя просто перенести всё за границу

Выбор запасной площадки зависит не только от расстояния. Бизнесу Узбекистана необходимо учитывать требования к хранению и передаче персональных данных, а регулируемым отраслям — дополнительные правила. Допустимость конкретного решения нужно проверять с учётом того, какая информация обрабатывается. Закон Узбекистана «О персональных данных».

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

Сколько стоит готовность к аварии

Запасная инфраструктура требует денег. Но простой тоже имеет цену: несостоявшиеся продажи, компенсации, задержанная логистика, дополнительная работа сотрудников и потеря доверия.

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

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

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