Резервная почта для компании: как составить план Б на случай сбоя провайдера, взлома или потери домена

Ваш план Б на случай отказа почты — «подождать, пока починят»? Это не план, это капитуляция. Облачный провайдер не обязан думать о вашем бизнесе в момент аварии — это должна сделать сама компания, и лучший план Б — переписка на своём сервере. Резервная почта для компании — это не второй ящик на всякий случай, а план Б: копия всей переписки на другой площадке, готовый к работе резервный сервер, порядок переключения MX и люди, которые знают, что делать. Для большинства небольших и средних компаний достаточно копии ящиков и отрепетированного переключения: это решает сценарии сбоя провайдера, взлома и массового удаления писем и разворачивается за несколько дней. Ниже — шесть сценариев, которые должен покрывать план, как определить допустимый простой, четыре уровня резерва, роли, документ и учения.

Облако не даст вам плана Б

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

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

Ждать — это не стратегия

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

План Б — это когда в такой день у вас есть копия всей переписки на своей площадке, сервер, готовый принять почту, и человек, который знает, какие пять шагов сделать. Это стоит дешевле одного дня простоя. Компании, у которых он был, в октябре 2026 года работали. Остальные — ждали.

Что такое план Б для почты и зачем он компании

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

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

Ниже — как составить план Б: какие сценарии учитывать, как определить допустимый простой и потерю данных, какие уровни резерва бывают, сколько они стоят, кто за что отвечает и как проверить, что план работает. Технические инструкции — копия ящиков, переключение DNS, перенос — вынесены в отдельные статьи серии, здесь — общая конструкция.

Чем план Б отличается от резервного копирования

Резервная копия отвечает на вопрос «можем ли мы вернуть данные». План Б отвечает на вопрос «можем ли мы работать». Это разные вещи: копия переписки на сервере, к которому никто не знает, как подключиться, не поможет в первые часы сбоя.

План Б включает копию, но к ней добавляются люди, порядок действий, каналы связи и проверки. В хорошем плане копия — один из пяти-шести пунктов, а не единственный.

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

Шесть сценариев, которые должен покрывать план

Чаще всего о плане Б думают в контексте сбоя провайдера. Но почта компании перестаёт работать и по другим причинам, и хороший план покрывает их все.

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

Почта и другие сервисы того же поставщика

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

Составьте короткий список: какие сервисы компании у какого поставщика. Для каждого, кроме почты, ответьте на тот же вопрос — что делаем, если он недоступен. Иногда достаточно перенести один-два элемента, например DNS и хранилище важных документов, к другому поставщику, чтобы сбой одного не останавливал всё.

О переносе диска и документов — в отдельной статье серии про Яндекс Диск компании.

Сценарий: недоступен провайдер почты

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

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

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

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

Сценарий: взломана учётная запись

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

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

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

Затем — разбор: как получили доступ (фишинг, повторно использованный пароль, утечка), и что изменить, чтобы не повторилось.

Сценарий: массовое удаление писем

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

Порядок: остановить источник удаления (отключить правило, программу, скрипт), оценить, что пропало и за какой период, восстановить из копии нужные папки в ящик. Восстановление делается тем же imapsync в обратную сторону с ограничением по папке; повторов не будет, потому что уже существующие письма пропускаются.

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

Сценарий: истёк домен или проблемы с DNS

Если домен не продлили вовремя, перестают работать и почта, и сайт: DNS-записи домена перестают отвечать. Это одна из самых обидных причин простоя, потому что она полностью предотвратима: автопродление и контроль срока у двух ответственных.

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

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

Сценарий: домен в чёрных списках

Письма компании начинают отклоняться или попадать в спам. Частые причины: с вашего сервера или учётной записи рассылали спам после взлома, сервер оказался открытым релеем, на тот же IP-адрес попали чужие рассылки, неправильно настроены SPF и DKIM.

Первые действия: найти и устранить источник (взломанная учётная запись, открытый релей, скомпрометированный сайт с формой), проверить IP и домен по основным спискам, проверить SPF, DKIM и DMARC. Затем — запросить исключение по процедуре каждого списка, после того как причина устранена.

На время, пока доставляемость не восстановилась, срочные письма можно отправлять через другой сервер, разрешённый в SPF, — это тоже часть плана Б. О регулярной проверке — в статье «Мониторинг чёрных списков почты».

Сколько можно простаивать и сколько можно потерять

В планировании непрерывности есть два понятия, которые удобно применить к почте. Допустимое время восстановления (в англоязычной литературе RTO) — сколько времени компания может работать без почты. Допустимая потеря данных (RPO) — за какой период можно потерять письма без серьёзного ущерба.

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

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

Результат — две цифры: например, «восстановить возможность работать с почтой за 4 часа» и «не потерять письма старше суток». Они определяют, какой уровень резерва нужен и сколько разумно на него тратить.

Как оценить допустимый простой по процессам

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

В клетках — короткие оценки: «не критично», «неудобно», «теряем деньги», «нарушаем сроки». Первая колонка, где появляется «теряем деньги» или «нарушаем сроки», и есть ваш допустимый простой.

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

Порог переключения: когда включать резерв

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

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

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

Важное свойство почты: входящие письма ждут

У почты есть особенность, которая упрощает план Б по сравнению с другими системами. Когда сервер получателя недоступен, письмо не пропадает: сервер отправителя ставит его в очередь и повторяет попытки. По RFC 5321 время, через которое отправитель отказывается от доставки, как правило, должно составлять не менее 4–5 дней.

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

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

Чего этот механизм не гарантирует

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

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

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

Четыре уровня резерва

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

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

Как выбрать уровень резерва

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

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

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

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

Для любого уровня обязательно одно: кто-то должен его поддерживать. Резерв без ответственного через полгода перестаёт работать.

Уровень 0: порядок в доступах

Самая дешёвая часть плана Б и самая частая причина, по которой короткий сбой превращается в длинный. Проверьте:

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

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

Подробно про домен — в статье «Домен просрочен: сайт и почта легли — чек-лист».

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

Уровень 1: копия переписки

Копия всех ящиков на сервере под вашим контролем — основа плана Б. Она решает сразу несколько сценариев: недоступность провайдера (можно читать переписку), массовое удаление (письма остаются в копии), взлом учётной записи (удалённое злоумышленником сохраняется).

Технически это IMAP-сервер на отдельной площадке и синхронизация по расписанию утилитой imapsync. Важная деталь: без опции --delete2 imapsync не удаляет в копии письма, удалённые в исходном ящике, — мы проверили это на стенде. Именно это превращает синхронизацию в резервную копию.

Пошаговая инструкция со скриптом и таймером systemd — в статье «Как сделать резервную копию почты Яндекс 360». Если почта уже на собственном сервере, копию делают тем же способом на другую площадку или средствами резервного копирования самого сервера.

Как часто делать копию

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

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

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

Уровень 2: резервный сервер и переключение

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

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

Чтобы переключение было быстрым, TTL MX-записей держат небольшим постоянно (например, 300–900 секунд), а доступ к DNS — у тех, кто принимает решение. После восстановления основной почты MX возвращают, а письма, пришедшие на резервный сервер, переносят обратно тем же imapsync.

Как правильно менять записи и проверять результат — в статье «MX, SPF, DKIM, DMARC и TTL при смене почтового провайдера».

Что настроить на резервном сервере заранее

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

Домен добавлен, ящики созданы для всех сотрудников, квоты и лимит размера письма не меньше, чем на основной площадке. Сертификат TLS выпущен на имя, которое будет указано в MX, и продлевается автоматически. Сервер разрешён в SPF домена, его ключ DKIM опубликован в DNS со своим селектором, у IP-адреса настроена PTR-запись. Антиспам и антивирус включены. Есть веб-почта, чтобы сотрудники могли работать из браузера без настройки программ.

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

Раз в полгода проверьте, что всё это по-прежнему работает: сертификат не истёк, DKIM опубликован, вход по веб-почте работает.

Возврат после сбоя

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

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

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

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

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

Резервный MX: что он делает и чего не делает

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

Резервный MX не даёт сотрудникам доступа к почте во время сбоя — письма лежат в очереди, а не в ящиках. И он мало что добавляет к стандартному поведению почты: отправители и так держат письма в очередях несколько дней. Зато он может принять почту, если у отправителя короткий срок хранения очереди, и даёт вам контроль над письмами в период сбоя.

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

Для облачной почты резервный MX у вас обычно не настраивается: провайдер сам отвечает за приём. Поэтому для неё план Б строят на уровнях 1 и 2: копия и готовность переключить MX целиком.

Исходящая почта во время сбоя

Про входящую почту часто думают, а про исходящую — нет. Если основная почта недоступна, сотрудники не могут отправлять письма даже при наличии копии переписки: копия на сервере только для чтения.

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

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

Уровень 3: две активные площадки

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

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

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

План Б для облачной почты и для своего сервера: разница

Если почта в облаке, инфраструктура и её резервирование — забота провайдера, а ваша часть плана — данные, доступы и переключение. Резервный MX вы обычно не настраиваете, копию делаете по IMAP, а резервный сервер держите на своей площадке.

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

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

Связь на время сбоя: не только почта

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

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

Запретите заранее то, что в спешке кажется разумным: пересылку рабочей почты на личные ящики сотрудников и отправку писем клиентам с личных адресов. Это утечка переписки и подарок мошенникам, которые во время громких сбоев рассылают фишинг от имени «службы поддержки».

Приём заявок от клиентов во время сбоя

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

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

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

Роли: кто что делает при сбое

В плане Б должны быть названы люди, а не должности «ИТ-отдел». Минимальный набор ролей:

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

Если исполнитель — подрядчик: что прописать в договоре

Многие компании отдают почту на обслуживание подрядчику. Тогда план Б наполовину зависит от того, что записано в договоре. Проверьте пять пунктов.

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

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

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

Доступы: у компании есть все административные доступы и документация, а не только у подрядчика.

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

Что должны знать сотрудники заранее

Сотрудникам не нужно знать устройство резерва. Им нужно три вещи: как узнать, что почта недоступна не только у них; каким каналом пользоваться для связи на время сбоя; как открыть резервную почту, если будет команда переключиться.

Удобно сделать одну страницу «Если почта не работает» и разослать её всем — не по почте, а в мессенджер или в распечатанном виде. В ней: куда сообщить о проблеме, резервный канал связи, адрес веб-почты резервного сервера и как в неё войти.

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

Документ плана Б: что в нём должно быть

План Б — это документ на две-три страницы, а не папка регламентов. Он должен быть доступен без почты: распечатан или лежит в облачном хранилище другого поставщика.

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

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

Шаблон плана Б на одну страницу

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

1. Допустимые значения: восстановить возможность работать с перепиской за ___ часов; не потерять письма старше ___.

2. Где почта и где копия: основная площадка — ___; копия — ___, обновляется ___; подключение к копии — по инструкции ___.

3. Кто решает: ответственный за решение — ___ (телефон ___), заместитель — ___. Порог: если недоступность дольше ___ часов — переключаемся на резерв.

4. Кто делает: исполнитель — ___ (телефон, в том числе в нерабочее время), заместитель — ___; подрядчик — ___ (телефон, срок реакции по договору).

5. Связь: внутри компании — ___; ключевые внешние контакты — список в ___; текст для клиентов — ___.

6. Доступы: регистратор, DNS, почтовая админка, сервер копий — в хранилище паролей ___ у ___ и ___.

7. Проверки: последняя — ___, результат — ___; следующая — ___.

Учения: как проверить, что план работает

План, который ни разу не проверяли, обычно не срабатывает в первый раз. Проверка не требует остановки почты.

Раз в квартал: восстановить из копии одну папку в ящик сотрудника и убедиться, что письма на месте. Подключиться к копии почтовой программой и найти письмо месячной давности. Проверить, что уведомления о неуспешной копии действительно приходят.

Раз в полгода: пройти по документу плана с участниками: актуальны ли телефоны, доступы, порядок действий. Отрепетировать переключение на тестовом поддомене: изменить MX тестового поддомена на резервный сервер и проверить приём и отправку.

После каждого реального инцидента — короткий разбор: что сработало, что нет, что исправить в плане.

Сценарий учений на один час

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

Минута 0. Ответственный за решение объявляет условный сбой основной почты. Исполнитель открывает документ плана Б — именно тот экземпляр, который доступен без почты.

Минуты 5–20. Исполнитель подключается к копии переписки почтовой программой и находит письмо, названное ответственным, — например, от определённого контрагента месячной давности. Коммуникатор проверяет, что резервный канал связи работает, и рассылает по нему тестовое сообщение.

Минуты 20–45. Исполнитель переключает MX тестового поддомена на резервный сервер, отправляет письмо на тестовый ящик, проверяет приём и отправку, затем возвращает запись.

Минуты 45–60. Разбор: что заняло больше времени, чем ожидали, что устарело в документе, что исправить до следующих учений. Результат записывается в раздел «Проверки» плана.

Типичные ошибки в планах Б

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

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

Копия повторяет удаления. Синхронизация с удалением на приёмнике защищает от недоступности сервиса, но не от потери писем. Для резервной копии удаления на источнике не должны удалять письма в копии.

Копия у того же поставщика. Одна авария затрагивает и оригинал, и копию.

Нет порога для решения. Каждый сбой сопровождается спором «ждать или переключаться». Порог определяется заранее.

Переключение никогда не репетировали. В момент сбоя выясняется, что TTL записей сутки, доступа к DNS нет у дежурного, а на резервном сервере не настроен DKIM. Репетиция на тестовом поддомене выявляет это заранее.

Сколько стоит план Б

Стоимость зависит от уровня. Уровень 0 — это время на наведение порядка в доступах. Уровень 1 — сервер копий на отдельной площадке и настройка синхронизации; программное обеспечение (imapsync, Dovecot) бесплатное. Уровень 2 — добавляется настройка резервного сервера как полноценного почтового и документированный порядок переключения. Уровень 3 — отдельный проект.

У нас для таких задач: ящики на нашей инфраструктуре в ЦОД МТС — от 150 ₽ в месяц за ящик, обслуживание почтового сервера — от 7 000 ₽ в месяц; точную стоимость под ваш уровень резерва фиксируем после аудита.

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

С чего начать на этой неделе

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

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

Дни 2–3. Настроить регулярную копию всех ящиков на сервер на другой площадке и уведомления о неуспешных запусках.

День 4. Написать документ плана Б на две страницы: допустимые значения, где копия, кто решает и кто делает, резервный канал связи.

День 5. Провести первую проверку: восстановить папку из копии и найти письмо месячной давности в копии.

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

План Б и требования к хранению данных

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

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

Опишите копию в документах о защите информации так же, как основную почту: где она, кто имеет доступ, как защищена.

Когда план Б нужно пересматривать

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

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

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

Как понять, что план Б у вас уже есть

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

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

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

План Б и переезд: как они связаны

План Б и переезд почты — не альтернативы, а этапы. Резервный контур — это уже половина переезда: все письма лежат на вашем сервере, сервер умеет принимать почту, сотрудники знают, как к нему подключиться. Если компания решит уйти от текущего провайдера, останется переключить MX и перенастроить устройства.

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

Как переезжать — в руководстве по переносу почты с Яндекс 360; куда — в статье «Куда перенести корпоративную почту».

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