Пилот миграции почты: кого взять и как принять результат

Пилот переноса почты я провожу до общей смены MX: выбираю ящики с разными рабочими сценариями, копирую письма и проверяю доставку, архивы, Outlook и 1С. Массовый переезд разрешаю после приёмки. Ниже — состав пилота, проверяемые результаты и причины отложить переключение домена.

Какие ящики включить в пилот переноса почты

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

Для условного поставщика «Склад снабжения» я выбираю четыре пилотных профиля: менеджера, сотрудника с объёмным архивом, общий адрес склада и отправку документов из 1С. Это набор испытаний, а не утверждение о числе почтовых учётных записей. В компании 22 рабочих места, но количество личных ящиков, общих адресов и служебных отправителей надо посчитать отдельно. Четыре профиля вполне могут потребовать больше четырёх тестовых учётных записей. Вычитать их из числа рабочих мест и объявлять остаток планом миграции я не стану.

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

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

• Личный ящик: входящее письмо, ответ, вложение, поиск по переписке.
• Архивный ящик: папки, старая история, отметки, открытие вложений.
• Общий адрес: разрешённые операции и отсутствие лишнего доступа.
• Сервисный отправитель: документ из приложения и результат у получателя.

Как проверить доставку до общей смены MX

Я заранее рисую маршрут тестового письма. MX выбирает принимающие серверы для домена; эта запись не распределяет сотрудников на пилотную и обычную группы. Простая смена MX затронет входящую доставку домена целиком, а не только выбранные ящики. Поэтому сначала копирую архивы и проверяю подключение к новому сервису, сохраняя рабочий приём на прежней стороне. Для испытания нового входящего маршрута нужен отдельный согласованный способ доставки. Запись нового сервера в настройках Outlook сама по себе этот маршрут не создаёт.

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

Пересылка со старой стороны может быть предусмотренной частью перехода. Сам факт такого маршрута не доказывает ошибку DNS. Я сопоставляю заголовки Received с согласованной схемой и проверяю, не возвращается ли письмо на предыдущий узел. Подробности разобраны в статье про пересылку в переходный период. Для каждого теста фиксирую отправителя, получателя, время отправки и получения, тему и фактический путь. Самоуспокоение «оно же пришло» не объясняет, куда уйдёт следующее письмо.

Исходящую доставку я проверяю отдельно, на внешних контрольных адресах с разрешения их владельцев. В отчёт идут результат приёма и результаты SPF, DKIM и DMARC у получателя. В базе есть конкретная ловушка: несколько SPF-записей одного домена дают permerror. При одновременной отправке со старой и новой площадок я согласую разрешённых отправителей в одной SPF-записи. Успешная аутентификация не гарантирует папку «Входящие»: учитываю и решение фильтра получателя. Задержку разбираю по очереди доставки и ответу принимающей стороны, а не объясняю автоматически закрытым портом.

Как перенести архив и проверить повторный проход

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

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

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

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

Что проверить в Outlook, календаре и телефоне

На рабочем компьютере я проверяю конкретную редакцию Outlook и способ подключения. Для IMAP с TLS с начала соединения обычно используется порт 993; для клиентской SMTP-отправки распространены 587 с STARTTLS и 465 с TLS с начала соединения. Это разные режимы, а не взаимозаменяемые числа. Окончательные настройки беру у принимающего сервиса. В пилоте проверяю имя сервера, сертификат, способ входа и поддерживаемое шифрование. Отключить проверку сертификата ради зелёной галочки — сомнительное достижение: галочка останется, достоверность проверки исчезнет.

Письма через IMAP не означают перенос календаря, контактов и задач. Это ограничение прямо отмечено в документации по IMAP-миграции. Для этих данных я составляю отдельный план и проверяю поддерживаемый способ подключения именно в выбранном клиенте. Пользователь создаёт приглашение, принимает ответ, меняет время встречи и находит нужный контакт. Если функция на новой платформе отсутствует, это должно быть известно до решения о переезде. Нельзя обещать прежнюю работу календаря только потому, что Outlook уже показал папку с письмами.

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

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

• Вход и отправка работают с согласованным шифрованием.
• Календарь и контакты проверены отдельными действиями.
• Общий адрес доступен только нужным участникам.
• Телефон получает письма в предусмотренном режиме.
• Локально сохранённые письма открываются без сети.

Как проверить отправку документов из 1С

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

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

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

Если письмо с вложением не проходит, я разделяю этапы: формирование в 1С, отправка приложением, приём почтовой системой и доставка получателю. Ограничение размера SMTP-сообщения и ограничение загрузки архива через IMAP относятся к разным операциям. Бездумно повышать лимит на одном узле бессмысленно, когда отказал другой. При нечитаемой теме или тексте смотрю исходное сообщение и его кодировку; фильтр для произвольного переписывания писем не служит универсальным лечением. «Поставили побольше» — это изменение настройки. Причина ошибки от него ещё не становится известной.

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

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

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

Срок массового переноса оцениваю после измерения первого копирования, повторного прохода и проверки участников. Эти замеры показывают узкие места, но не дают права умножить время одного ящика на число рабочих мест: архивы, ограничения соединений и занятость пользователей отличаются. Я отдельно закладываю окно на исправления и подтверждение от сотрудников. Фиксированное обещание «успеем за день» до замеров оставляю за пределами плана. Для директора полезнее список зависимостей и согласованное окно работ, чем красивая дата, которую нечем обосновать.

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

• У каждого обязательного сценария есть результат и подтверждение.
• Расхождения данных объяснены; неисправленные препятствия останавливают переход.
• Изменённые настройки прошли повторную проверку.
• Согласованы сроки, общая смена MX и финальный проход.
• Описан возврат с учётом писем на обеих площадках.

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