ТурБК - технологии, консалтинг, разработка » Технологии » Обзоры » Что будет с сайтом турбизнеса, если Яндекс перестанет работать: карта зависимостей

Что будет с сайтом турбизнеса, если Яндекс перестанет работать: карта зависимостей

Главное

  • 8–12 октября 2026 года сбои в дата-центрах «Яндекса» затронули облако, Метрику, Вебмастер, Пэй и Диск; сам «Яндекс» при этом не перестал работать.
  • Резерв внутри одного облака не гарантирует работу сайта: недоступными оказались две зоны Yandex Cloud из трёх.
  • У турбизнеса зависимость от «Яндекса» чаще скрыта в подрядчиках, системах бронирования и платёжной форме.
  • Начинать стоит с собственной карты прямых и косвенных зависимостей и выгрузок данных вне одного провайдера.

8–12 октября 2026 года: сценарий, который проверили на практике

В ночь на 8 октября 2026 года после атаки беспилотников на дата-центр «Яндекса» в Сасово (Рязанская область) начался пожар, и площадка остановилась. По данным статусной страницы Yandex Cloud, зона доступности ru-central1-b стала недоступна, создание новых ресурсов в облаке ограничили, а сроков восстановления компания не называла. 9 октября пресс-служба «Яндекса» сообщила об ударе по дата-центру в Калуге: несколько модулей полностью выведены из строя, часть сервисов может работать с перебоями. 11 октября, по сообщению компании, полностью остановился ЦОД во Владимире; по данным Yandex Cloud, сбой затронул более 80 сервисов, облако перешло в аварийный режим.

К 12 октября, по данным компании, остановлены три дата-центра из пяти. CNews при этом писал о четырёх объектах в сети: Сасово, Калуга, Владимир и Мытищи, так что в разных сообщениях число площадок различается. Вечером 11 октября «Яндекс» сообщил о постепенном возвращении доступа к сервисам, но часть функций оставалась недоступной. Всё описанное актуально на 11–12 октября: ситуация менялась по часам, сроков полного восстановления компания не называла.

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

Кого задело и почему несколько зон не спасли

Пострадали два круга. Первый — собственные сервисы «Яндекса»: Пэй, Диск и «Яндекс 360», Метрика, Вебмастер, кабинет Директа. Второй — сторонние сайты на его инфраструктуре. По сообщениям СМИ, 8 октября проблемы возникли у «Циана», «Авито», застройщиков («Брусника», А101, «Гранель») и ряда СМИ, пользователи жаловались на Т-Банк. К 12 октября в списки сбоев добавились Wildberries, «Дом.ру», «Додо Пицца», Lamoda, «Магнит» и другие компании; проблемы фиксировались и за пределами России. Список выборочный, но он показывает главное: сбой вышел далеко за границы самих сервисов «Яндекса».

Документация Yandex Cloud делит ресурсы на зональные (виртуальные машины, диски) и глобальные (облачная сеть, бакеты). Зоны изолированы и расположены примерно в 300 км друг от друга; в регионе ru-central1 их три: a, b и d. Провайдер советует размещать ресурсы в нескольких зонах, чтобы отказ одной не остановил приложение. В октябре недоступными оказались две зоны: ru-central1-b (Сасово) и ru-central1-a, физически расположенная во Владимире. После остановки владимирского ЦОДа Yandex Cloud признал оставшуюся конфигурацию ресурсов неустойчивой и рекомендовал клиентам использовать планы восстановления на внешних площадках; каналы поддержки и статус-борд могли отвечать с задержками.

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

Фундамент: облако, домен, почта, файлы

Схема: домен, DNS, почта и хостинг связаны одной цепочкой

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

Второй слой — домен. Документация Yandex Cloud DNS описывает правило переноса зоны: все ресурсные записи (A, CNAME, MX, TXT и другие, кроме NS) переносят заранее, иначе сайт, почта и подтверждения на сторонних сервисах могут перестать работать; обновление делегирования у провайдеров обычно занимает до 24 часов. Это правило переноса, а не описание того, как DNS вёл себя в октябре. Но практический вывод из него очевиден: переезжать в разгар сбоя поздно, список записей и доступ к управлению доменом нужны до него.

С почтой и файлами картина смешанная. Почта вернулась вечером 11 октября, но работала не полностью. Позже компания сознательно ограничила часть функций «Яндекс 360», включая Диск, чтобы сохранить работу основных сервисов: в веб-версии отключили массовое скачивание файлов, а до этого часть файлов отображалась в интерфейсе, но не скачивалась. Файлы вроде бы на месте, а забрать их в нужный момент нельзя. Выгружать документы, договоры и шаблоны нужно заранее, а не во время сбоя.

Деньги и данные: оплата, аналитика, реклама, карты

Оплата

Яндекс Пэй, по сообщениям СМИ, оставался недоступен более 18 часов после атаки: пользователи не могли открыть платёжную форму, оплатить или перевести деньги. Компания заверила клиентов, что деньги в сохранности, и пообещала не считать просроченными платежи по Сплиту, Супер Сплиту и кредитам, которые не удалось внести из-за сбоя. Эти заявления адресованы покупателям; что получат магазины и сервисы, принимающие Пэй, там не говорилось. Если у турагентства или отеля Пэй — единственный способ оплаты на сайте, на время сбоя продажи просто останавливаются.

Метрика и Вебмастер

После атак на ЦОДы Метрика и Вебмастер перестали работать, сроков восстановления «Яндекс» не называл. Тут стоит различать потерю данных и потерю функции. Вебмастер не влияет на ранжирование: это инструмент наблюдения, без него сложнее проверять индексацию и отправлять страницы на переобход. А провал в Метрике в дни сбоя не равен падению реального трафика.

Владельцам сайтов советовали пометить 8–9 и 11–12 октября как дни с неполными данными, опираться на access-логи сервера и не менять robots.txt, sitemap и структуру адресов, пока Вебмастер не сможет предупредить о поломке. Для выгрузки сырых данных у Метрики есть Logs API: он отдаёт таблицы визитов и событий, ограничен периодом до одного года и объёмом до 10 ГБ на счётчик, не отдаёт данные за текущий день и требует токена. Но это часть той же Метрики, и в дни недоступности получить через него данные вряд ли удалось бы. Значит, выгрузку нужно настроить заранее, а access-логи сервера от Метрики не зависят.

Директ и Карты: что проверять самим

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

С Картами и Геокодером то же правило. Найдите на сайте все места, где они подключены: страницу контактов, выбор офиса, карточку отеля. Посмотрите, как страница выглядит и работает, если виджет не загрузился. Скрипт Метрики, по разбору независимого издания, подгружается асинхронно и не блокирует разбор страницы; считайте это гипотезой и проверьте на своём сайте, отключив скрипт в браузере.

Если подвести итог по слою: для продаж критична оплата, а аналитика и вебмастер в основном «слепнут». Решения принимать труднее, но сам сайт продолжает работать.

Туристический кейс: зависимость через подрядчиков

11 октября АТОР предупредила о возможных задержках выписки ваучеров и авиабилетов у клиентов отдельных турагентств из-за сбоя сервисов «Яндекса». Вылеты по уже выписанным билетам и оплаченные услуги сохраняются. Большинство сайтов туроператоров работало нормально, но сбой затронул сайт PEGAS Touristik, а бронирование на двух крупных агрегаторах пакетных туров было недоступно. Часть документов в период сбоя туроператоры запрашивали и передавали по дублирующим каналам связи, в обход затронутых сервисов.

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

Сбой на день и недоступность на месяцы

Два сценария: короткий сбой и длительная недоступность сервисов

Чем дольше недоступность, тем иначе ставится задача. Сроков полного восстановления компания не называла; по сообщениям СМИ, отрасль говорила о месяцах, а CNews оценил восстановление инфраструктуры примерно в полгода. Это оценка издания, не официальный срок. Эксперты допускают и рост цен на облачные услуги из-за дефицита мощностей, но это прогноз, а не факт.

10 октября «Яндекс» добавил в пользовательское соглашение положение об обстоятельствах непреодолимой силы, включив удары БПЛА и ракет. По оценке CNews, это сняло с компании ответственность перед пользователями при атаках; сама компания, по сообщениям СМИ, заявляла, что такие положения предусмотрены законодательством и меняются лишь формулировки. Юридические последствия для конкретных клиентов лучше уточнять у юриста, но строить планы в расчёте на компенсацию рискованно.

12 октября глава Минцифры Максут Шадаев назвал атаку на «Яндекс» беспрецедентной и отметил, что основные сервисы продолжают работать благодаря резервированию оборудования и распределению мощностей между площадками. Минцифры и Минобороны обсуждают защиту дата-центров; конкретные меры и сроки не объявлены.

Если горизонт — недели и месяцы, вопрос меняется. Уже не «как пережить день», а «какие функции должны работать независимо от Яндекса».

Что проверить на своём сайте уже сейчас

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

Прямые зависимости

Сервис Что затронуто Как проверить Что подготовить
Хостинг и зона размещения Сайт и база, если они в одной или двух пострадавших зонах. Выясните, у кого хостинг и в какой зоне, где лежат бэкапы. Копия вне одного облака и инструкция по развёртыванию.
DNS и домен Сайт, почта и подтверждения сторонних сервисов. Выпишите все записи A, CNAME, MX, TXT и узнайте, кто управляет зоной. Выгрузка записей под рукой; помните, что делегирование обновляется до 24 часов.
Почта и файлы Ящики и документы в «Яндекс 360» и на Диске. Узнайте, какие ящики и документы живут в «Яндекс 360» и на Диске. Регулярная выгрузка копии вне сервиса.
Платёжная форма Приём платежей на сайте. Проверьте, единственный ли это способ оплаты на сайте. Второй канал приёма платежей.
Метрика, карты, виджеты Отображение страницы и аналитика, если скрипт или карта не загрузились. Посмотрите, что показывает страница, если скрипт или карта не загрузились. Заранее настроенная выгрузка через Logs API и доступ к access-логам сервера.

Косвенные зависимости

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

Как готовиться

  • Храните бэкапы и копию DNS-записей вне одного облака.
  • Регулярно выгружайте данные Метрики через Logs API и сохраняйте access-логи сервера.
  • Заведите второй канал связи с клиентами на случай недоступности почты.
  • В дни сбоя помечайте данные как неполные и не меняйте robots.txt, sitemap и структуру адресов, пока Вебмастер не работает.

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

Скрытая зависимость

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