Сбои сервисов «Яндекса» 8–11 октября 2026: что было с почтой и что сделать компаниям

Октябрь 2026 года показал, чем оборачивается почта на чужом сервере: когда у провайдера горят дата-центры, клиенты могут только ждать. Сбой Яндекс 360 8 октября 2026 года затронул почту: пользователи сообщали о трудностях, компания заявила, что проблемы оперативно устранены. В те же дни «Яндекс» сообщал о повреждении дата-центров в Сасово, Калуге и Владимире после атак беспилотников. Ниже — хронология только по официальным сообщениям и СМИ со ссылками, разбор того, что происходит с корпоративной почтой при недоступности сервиса, и конкретный план на неделю и месяц: копия ящиков, резервный канал связи и выбор между резервом и переездом.

Урок октября: облако не ваше

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

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

Хронология: что известно из официальных сообщений и СМИ

Ниже — только то, что сообщили сама компания и крупные СМИ, со ссылками. Мы сознательно не пересказываем слухи о масштабах и причинах и не делаем выводов о том, какие сервисы и как долго были недоступны, если это не подтверждено.

По всем трём площадкам компания сообщала, что пострадавших нет. Официальные сообщения «Яндекса» обновляются; перед тем как принимать решения, сверяйтесь с актуальными заявлениями компании и статусной страницей Yandex Cloud.

Что это значило для компаний с почтой в Яндекс 360

Для бизнеса, у которого корпоративная почта размещена в Яндекс 360, по сообщениям 8 октября был период, когда работать с почтой было затруднено. Компания заявила, что проблемы оперативно устранены. Сколько именно длились трудности у конкретных организаций, по открытым данным сказать нельзя, и мы этого не оцениваем.

Полезнее разобрать, что происходит с почтой компании, когда почтовый сервис временно недоступен, — от этого зависит, какие меры имеют смысл.

Входящие письма в большинстве случаев не теряются. Если сервер получателя не отвечает, сервер отправителя ставит письмо в очередь и повторяет попытки доставки; по RFC 5321 срок, после которого отправитель отказывается от доставки, обычно должен быть не меньше 4–5 дней. Письма придут с задержкой, когда сервис снова станет доступен.

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

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

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

Главный вывод: риск не в конкретном провайдере, а в единственном

Любой облачный сервис может быть недоступен — из-за аварии, проблем с электропитанием, ошибки при обновлении или внешнего воздействия. Это не упрёк конкретной компании: у крупных провайдеров есть резервирование, и, судя по сообщениям, нагрузку переключали на другие зоны. Вопрос в другом — что делает ваша компания, пока сервис восстанавливают.

Если ответ «ждём», то стоит хотя бы заранее знать, сколько бизнес может ждать без почты и что за это время теряется: заявки клиентов, письма от банков, сроки ответов госорганам. Если ждать нельзя — нужен план Б: копия переписки, способ быстро переключить приём почты и другой канал связи с сотрудниками и клиентами.

Те же события показывают ещё один риск — концентрацию. Когда почта, документы, календари, DNS домена и мессенджер находятся у одного поставщика, недоступность его площадки затрагивает всё сразу. Разнести хотя бы самое критичное по разным поставщикам — разумная мера, даже если вы довольны текущим сервисом.

Если почта недоступна прямо сейчас: порядок действий

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

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

Третье — для срочных писем клиентам и банку использовать заранее согласованный резервный канал. Если компании ждут документы с жёстким сроком, позвоните и предупредите о задержке.

Четвёртое — после восстановления проверить, что входящие письма за период недоступности дошли. Отправители, у которых доставка не прошла окончательно, получат уведомление о недоставке; попросите ключевых контрагентов перепроверить отправленное в эти часы.

Пятое — зафиксировать, что не сработало, и решить, нужен ли резерв. Лучшее время для плана Б — сразу после инцидента, пока последствия понятны всем, но без спешки с переездом.

Что сделать в ближайшую неделю

Эти шаги не требуют переезда и больших затрат, но заметно уменьшают последствия следующего сбоя.

• Сделать копию всех ящиков на свой сервер или другую площадку через IMAP — например, imapsync; повторять по расписанию
• Выгрузить контакты (vCard) и календари (iCal) и хранить копию вне облака
• Проверить, где обслуживается DNS-зона домена, и сохранить список всех записей — MX, SPF, DKIM, DMARC, записи сайта
• Составить список критичных адресов: банки, ключевые клиенты, госорганы — с телефонами, на случай если почта недоступна
• Договориться о резервном канале связи с сотрудниками (телефон, мессенджер другого поставщика)
• Назначить ответственного, который решает, когда переключаться на резерв, и записать порядок действий

Что сделать в ближайший месяц

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

Резервный контур рядом с текущей почтой. Почта остаётся в Яндекс 360, но копия ящиков регулярно синхронизируется на ваш сервер, где сотрудники могут работать при сбое. Заранее подготовлен порядок переключения MX на резервный сервер и обратного переноса писем. Подробно — в статье серии «План Б для корпоративной почты».

Перенос почты на другую площадку — в другое облако, на свой сервер или в гибридную схему. Как это сделать без потери писем и с минимальным простоем, разобрано в нашем руководстве по переносу почты с Яндекс 360.

Гибрид: критичные ящики (руководство, бухгалтерия, приём заявок) — на собственном сервере, остальные — в облаке. Это снижает зависимость, не перенося всех сотрудников.

Какой вариант подходит, зависит от числа ящиков, наличия администратора и требований к хранению данных. Не принимайте решение в спешке сразу после сбоя: сначала инвентаризация и копия данных, потом выбор.

Как сделать копию почты, не меняя провайдера

Самая доступная мера — регулярная синхронизация ящиков по IMAP на сервер под вашим контролем. Яндекс 360 поддерживает доступ по IMAP: по справке это сервер imap.yandex.ru, порт 993, SSL, вход по полному адресу ящика и паролю приложения. В настройках ящика нужно включить доступ по IMAP, а пароль приложения создаётся в Яндекс ID и, по справке Яндекс ID, начинает действовать через 2–3 часа.

Синхронизацию удобно делать утилитой imapsync: повторный запуск переносит только новые письма и не создаёт дублей. Мы проверили это на тестовом стенде — второй проход по ящику на 755 писем занял 4 секунды и ничего не продублировал. Пошаговая инструкция с командами — в статье «Перенос почты через imapsync».

Копию стоит держать на площадке другого поставщика, чем основная почта: иначе одна авария затронет и оригинал, и копию. Отдельно о том, почему облачные сервисы не заменяют собственный бэкап писем, — в статье «Бэкап Яндекс 360 и Google Workspace: кто отвечает».

Чего делать не стоит

Не переносить почту в спешке в первый попавшийся сервис. Переезд без инвентаризации и подготовки DNS приводит к потерянным письмам и попаданию в спам — проблем станет больше, чем от сбоя.

Не пересылать всю почту автоматически на личные ящики сотрудников «на всякий случай». Это утечка корпоративной переписки и персональных данных из-под контроля компании.

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

Не делать выводов по слухам. Опирайтесь на официальные сообщения провайдера и проверенные СМИ; если информации нет — исходите из худшего разумного сценария для своего плана Б, а не из прогнозов в чатах.

Как оценить, сколько компания может работать без почты

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

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

Чек-лист непрерывности для почты

Короткий список, который стоит пройти после любых новостей о сбоях.

• известно, у какого поставщика почта, DNS, документы и календари
• есть актуальная копия всех ящиков вне основного сервиса
• контакты и календари выгружены и хранятся отдельно
• сохранён список DNS-записей домена
• назначен ответственный и записан порядок перехода на резерв
• у сотрудников есть резервный канал связи
• клиенты знают альтернативный способ связаться с компанией
• раз в квартал резерв проверяется на практике

Частые вопросы