Когда ложится облако: чему научила авария октября 2026
Разбор · 2026-10-16 · 8 мин чтения
С 8 по 11 октября 2026 года из строя вышли три дата-центра «Яндекса», и половина рунета неделю жила в режиме «работает через раз». Мы наблюдали это с двух сторон сразу: как компания, которая держит свою инфраструктуру на собственных серверах, и как клиент чужих сервисов. Второе оказалось интереснее — и полезнее для выводов.
Что произошло
Дата Площадка Что случилось --------- 8 октября Сасово, Рязанская область пожар, дата-центр остановлен полностью 9 октября Калуга несколько модулей выведены из строя 11 октября Владимир инфраструктура повреждена, площадка остановлена
Облачная платформа перешла в аварийный режим: две зоны доступности стали недоступны целиком, выдачу новых ресурсов перевели в ручной режим, часть управляемых баз данных ушла в режим только для чтения. Клиентам публично рекомендовали «использовать любые альтернативные планы аварийного восстановления» — в переводе это значит «поднимайтесь где-нибудь ещё». Подробности — в разборе «Ведомостей» и в техническом разборе на Хабре.
Главный урок: вас задело, даже если вас там нет
Мы не держим в этом облаке ничего. Ни одного сервера, ни одной базы. И всё равно эта неделя обошлась нам дорого — потому что зависимость бывает не только инфраструктурной.
Пропала аналитика. Счётчик посещаемости три дня отдавал нули по одному из наших сайтов. Решения о рекламе и контенте принимаются по этим цифрам — трое суток мы принимали их вслепую, а часть выводов потом пришлось пересматривать.
Отвалился рекламный кабинет. Личный кабинет не открывался, а программный интерфейс отвечал пустотой на любой запрос. Это значит, что рекламу нельзя было ни остановить, ни перенастроить. У нас в эти дни шли объявления на товар, который мы временно сняли с продажи, — и выключить их было технически нечем. Деньги уходили на клики, которые заведомо не могли закончиться покупкой.
Лёг личный кабинет производителя ПО. У одного из вендоров не работал портал, где клиенты видят свои лицензии, и появилось официальное предупреждение о задержках активации. Мы на день приостановили продажи его продуктов — не потому, что у нас что-то сломалось, а потому что не могли отвечать за результат. Эту историю мы разобрали отдельно.
Ни один из трёх ударов не пришёлся по нашим серверам. Все три пришлись по внешним сервисам, на которых держится обычная работа компании. Когда составляете список зависимостей — считайте не только то, где лежат виртуальные машины.
Почему резервирование не спасло тех, кто был в облаке
Логично спросить: а как же зоны доступности, ради которых всё и затевалось? Технический разбор на Хабре даёт три ответа, и все три стоит запомнить.
Ёмкости не хватило. Уцелевшие зоны не рассчитаны на то, чтобы принять нагрузку выбывших. Переезд упирался не в настройку, а в физическое отсутствие свободных процессоров и памяти.
Управляющие узлы оказались в упавшей зоне. Рабочие серверы кластера продолжали работать, но управлять ими было нечем — а значит, нельзя было ни перезапустить, ни переразместить.
Квоты перевели в ручной режим. Даже восстановление из резервной копии упиралось в лимиты провайдера, которые в обычное время выдаются автоматически.
Добавьте к этому публичный случай, когда компания потеряла данные за семь дней: резервные копии лежали внутри того же контура, а последняя успешная была недельной давности.
Пять вопросов, которые стоит задать себе сегодня
Не про «Яндекс» — про себя.
1. Где физически лежат резервные копии? Если копия в том же облаке, что и система, это не копия, а иллюзия. Нужен независимый провайдер или собственное хранилище, физически в другом месте.
2. Когда вы в последний раз восстанавливались из этой копии? Непроверенная копия — это надежда, а не план. Проверка простая: поднять копию на чистой машине и засечь время. Большинство компаний впервые узнаёт реальный срок восстановления в день аварии.
3. Где ваш домен и DNS? Если управление доменом живёт у того же поставщика, что и сайт, при аварии вы не сможете даже перевести трафик в другое место. Мониторинг — туда же: он обязан смотреть на вас снаружи.
4. Сколько стоит ваш день простоя? Посчитайте один раз: выручка, которую не получите, плюс работа людей, которые будут сидеть без дела. Сравните с ценой холодного резерва у второго поставщика — и решение обычно становится очевидным.
5. Что из вашей работы завязано на одного поставщика? Почта, телефония, касса, платёжный шлюз, 1С, аналитика, реклама, лицензии. У каждого свой риск, и считать их надо по отдельности, а не «у нас всё в надёжном облаке».
Что можно сделать за один вечер
Полная отказоустойчивость — это проект на месяцы и серьёзные деньги. Но несколько вещей делаются сразу и закрывают большую часть риска.
- Выгрузить копию базы и файлов во второе место — другой провайдер, офисный сервер, внешний диск в сейфе. Пусть даже вручную и раз в неделю: это уже на порядок лучше, чем ничего. - Проверить восстановление хотя бы один раз, с секундомером. Записать время и список того, чего в копии не оказалось, — обычно это конфигурации, сертификаты и права доступа. - Снизить время жизни DNS-записей до 300 секунд заранее. В день аварии переключение займёт пять минут вместо суток. - Завести внешний мониторинг — он должен жить не там, где сайт, и писать вам в мессенджер. - Записать план на бумаге: кто что делает в первый час, у кого доступы, чей телефон у провайдера. В аварию никто не читает документацию, но короткий список из пяти пунктов работает.
Чем помогаем мы
Мы занимаемся ровно этим: серверами и резервным копированием, хостингом 1С с копиями в независимом хранилище и поддержкой с ответственностью по договору. Если после этой недели у вас появилось неприятное чувство, что план на случай аварии существует только в голове, — напишите нам. Посчитаем ваши риски и стоимость простоя, предложим резерв по деньгам, которые имеют смысл именно для вашего масштаба. Это бесплатно и ни к чему не обязывает.
И последнее. В эту неделю не пострадали те, кто заранее развёл данные и копии по разным местам, — не самые крупные и не самые богатые, а те, кто однажды потратил на это вечер.