Инфраструктура дает сбой: чему учит ситуация с Яндекс 360 и почему бизнесу нужен план «Б»
Iclect12.10.2026
12 октября 2026 года стало известно о серьезных ограничениях в работе Яндекс 360. После атак на дата-центры «Яндекса» часть пользователей потеряла доступ к письмам и файлам, перестали работать отдельные функции резервного копирования и совместной работы. Компания признала ограничения и объявила о бесплатном обслуживании до конца октября.
Для бизнеса это не просто новость о временных неудобствах. Это - сигнал.
Что произошло: хроника ограничений
Последствия атак затронули критически важные для корпоративных пользователей функции. IT-Word поделился перечнем:
Почта и файлы. В Яндекс Почте недоступен просмотр части писем. На Яндекс Диске некоторые файлы нельзя открыть или скачать. Особенно болезненным для компаний стало приостановление возможности скачать содержимое Диска одним архивом - это напрямую влияет на резервное копирование и миграцию данных.
Инструменты совместной работы. Временно не работают миграция из внешних сервисов, конспектирование встреч в Телемосте, совместное редактирование в Вики, отправка писем из Трекера и часть функций API.
Поддержка. Компания предупреждает о задержках ответов технической поддержки и не называет сроков восстановления.
Бесплатный месяц - не решение проблемы
«Средства на балансе не будут списаны», - говорится в уведомлении. Яндекс отменяет плату за обслуживание действующих клиентов до конца октября. Это снижает прямые расходы, но не решает главную проблему - недоступность данных.
Представьте: бухгалтерия не может выгрузить архив документов. Отдел продаж теряет доступ к истории переписки с клиентами. HR не может открыть кадровые файлы. Простой этих процессов не компенсируется месяцем бесплатной подписки.
Компания не сообщила, предусмотрен ли перерасчет уже внесенных платежей и будут ли компенсации за возможные потери данных.
Инженерный подход: как выглядит «настоящий» бэкап
Резервное копирование - это не «скопировал файл на флешку». Это инженерная дисциплина, которая строится на нескольких принципах.
Первый: изоляция точки отказа
Бэкап-сервер должен быть физически отделен от основной инфраструктуры. Это может быть выделенный сервер у другого провайдера, машина в офисе или защищенный узел в отдельном дата-центре. Главное - чтобы сбой у основного провайдера не затрагивал копии.
Второй: автоматизация без человека
Ручной бэкап рано или поздно перестает делаться. Регулярная синхронизация - через rsync по SSH или специализированные решения - работает без участия администратора.
Третий: ограничение доступа
Бэкап-сервер не должен быть доступен всем. SSH-ключи, выделенный пользователь с ограниченными правами, запрет интерактивного входа - базовые меры, которые превращают «файлохранилище» в защищенный контур.
Четвертый: регулярные учения
Восстановление нужно проверять. Не «файл на месте», а реальный запуск системы из бэкапа с отключением отказавших частей инфраструктуры и замером тайминга с учетом SLA.
Ноу-хау: изолированный сервер с персональным доступом
Здесь мы подходим к тому, что, на наш взгляд, становится новым стандартом для критичных данных.
Идея проста: данные переносятся на сервер, к которому нет общего доступа. Это не «облако для всех», не «корпоративный диск с правами на папки» и не «сервис, где данные лежат вместе с данными других клиентов».
Это выделенный сервер, доступ к которому предоставляется только конкретному человеку через его учетную запись. Никто другой - ни другие сотрудники, ни администраторы облака, ни техническая поддержка провайдера - не может получить доступ к данным без явного разрешения владельца, кроме случае, лично переданного ключа доступа доверенному лицу.
Такая модель решает несколько задач:Защита от внутренних угроз. Если доступ есть только у одного человека, компрометация учетной записи другого сотрудника не дает доступа к бэкапам.
Защита от внешних атак. Даже если основная инфраструктура взломана, изолированный бэкап-сервер остается недосягаемым, если он не входит в общий домен и не использует те же учетные данные.
Прозрачность владения. Данные принадлежат бизнесу, а не провайдеру. Доступ осуществляется напрямую, без посредников.
Технически это реализуется через SSH-ключи с ограничениями (command= в authorized_keys), отдельный физический или виртуальный сервер и отсутствие интеграции с корпоративным доменом. Доступ - только по ключу, только с определеннного IP, только для бэкап-операций.
Вывод
Яндекс 360 - не первый и не последний сервис, который столкнулся с катастрофой. Но его история - самая наглядная иллюстрация того, что облако перестало быть безусловной гарантией сохранности данных.
Когда три дата-центра выходят из строя за четыре дня, а сроки восстановления измеряются месяцами, единственный вопрос, который имеет значение: где в этот момент находится ваша резервная копия?
Если ответ - «в том же облаке», значит, копии нет.
Если ответ - «на диске у администратора», значит, копии тоже нет - или она устарела, или доступ к ней потерян вместе с сотрудником.
Настоящий бэкап - это не файл. Это система. Изолированный сервер, доступ к которому есть только у одного человека. Автоматическая синхронизация, не требующая ручного вмешательства. Регулярные учения, подтверждающие, что восстановление действительно работает. И полная прозрачность владения: данные принадлежат бизнесу, а не провайдеру.
Именно такой подход - изолированный сервер с персональным доступом - мы в Айселекте считаем новым стандартом для критичных данных. Не потому, что это модно. А потому, что это единственная модель, которая выдерживает проверку реальными сбоями.
Бесплатный месяц от Яндекса - жест доброй воли. Но он не вернет время, потраченное на простой. Не восстановит письма, к которым не было доступа неделю. Не компенсирует клиентов, ушедших к конкурентам.
Проверьте свою инфраструктуру сегодня. Не потому, что завтра обязательно случится катастрофа. А потому, что когда она случится - будет уже поздно.
