Как составить ТЗ на миграцию корпоративной почты без простоя

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

1. Зафиксируйте исходное и целевое состояние

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

Для исходной системы зафиксируйте:

• тип размещения: собственная инфраструктура, облачная служба или гибридная схема;
• перечень почтовых доменов и поддоменов;
• количество активных, заблокированных, архивных и общих ящиков;
• объём данных по каждому ящику и суммарный объём;
• наличие архивов, календарей, контактов, задач, правил, подписей и делегирования;
• протоколы и клиенты: веб-интерфейс, SMTP, IMAP, POP3, ActiveSync или собственные API;
• источники авторизации: локальные учётные записи, каталог, единый вход, многофакторная аутентификация;
• связанные системы: CRM, ERP, сервис-деск, сканеры, МФУ, приложения и устройства, отправляющие почту;
• политики хранения, архивирования, журналирования и расследования инцидентов;
• текущие DNS-записи, влияющие на доставку и аутентификацию сообщений.

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

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

2. Определите границы миграции

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

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

3. Проведите инвентаризацию до утверждения сроков

Сроки нельзя рассчитывать только по числу пользователей. В ТЗ включите обязательный этап обследования, результатом которого становится реестр объектов миграции.

Минимальные поля реестра:

Идентификатор пользователя
Основной адрес
Дополнительные адреса
Тип ящика
Статус учётной записи
Объём данных
Количество элементов
Наличие архива
Наличие делегирования
Критичность пользователя
Подразделение
Миграционная волна
Результат предварительной проверки
Результат итоговой проверки
Примечание об исключениях

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

4. Опишите стратегию миграции без остановки работы

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

1. Подготовка. Создаются целевые учётные записи, проверяются домены, права, лицензии, адреса и политики доступа.
2. Предварительная синхронизация. Основной объём исторических данных копируется до переключения пользователей.
3. Пилот. Переносится ограниченная группа с типовыми и сложными сценариями: обычный пользователь, руководитель, общий ящик, делегат, мобильный клиент и технический отправитель.
4. Миграционные волны. Пользователи переносятся группами с учётом подразделений, зависимостей и критичности.
5. Переключение маршрутизации. Изменяется направление новых входящих сообщений и параметры клиентского доступа.
6. Финальная синхронизация. Копируются изменения, появившиеся после предварительного переноса.
7. Период сосуществования. Исходная система сохраняется доступной в согласованном режиме до завершения проверки.
8. Вывод старой системы. Выполняется только после подписания приёмки и истечения срока отката.

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

5. Задайте требования к DNS и почтовой аутентификации

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

Необходимо предусмотреть:

• инвентаризацию действующих MX-записей;
• проверку SPF с учётом всех легитимных источников отправки;
• настройку DKIM на стороне целевой системы;
• проверку политики DMARC и адресов для отчётов;
• согласование времени жизни DNS-записей до переключения;
• сохранение исходных значений для сценария отката;
• контроль внешней доставки после изменения маршрутизации.

ТЗ не должно требовать механического добавления всех старых и новых отправителей в одну SPF-запись без проверки. SPF имеет ограничения, определённые стандартом, а ошибочная конфигурация способна ухудшить доставляемость. Итоговые записи должны быть проверены ответственным специалистом применительно к фактической инфраструктуре.

6. Опишите пилотную миграцию

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

Проверки пилота должны охватывать:

• вход через веб-интерфейс и корпоративные клиенты;
• отправку внутри организации и во внешние домены;
• получение сообщений от внешних отправителей;
• ответы, пересылку и работу с вложениями;
• календарные приглашения и повторяющиеся встречи;
• общие ящики, делегирование и отправку от имени;
• мобильные устройства;
• системные уведомления от приложений, МФУ и серверов;
• антиспам, карантин, журналирование и правила хранения;
• корректность отображения адресов, папок и временных меток.

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

7. Установите измеримые критерии приёмки

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

Пример набора критериев:

• все учётные записи из утверждённого реестра созданы в целевой системе;
• для каждого ящика сформирован отчёт миграции со статусом и перечнем исключений;
• контрольные сообщения успешно проходят между внутренними и внешними адресами;
• после переключения новые входящие сообщения поступают в целевую систему;
• пользователи из контрольной выборки видят согласованные папки, сообщения, календари и контакты;
• общие ящики и делегирование работают для перечисленных ролей;
• технические отправители проходят отдельный тест;
• SPF, DKIM и DMARC соответствуют утверждённой схеме;
• все пропущенные или неподдерживаемые элементы зарегистрированы и согласованы;
• служба поддержки получила инструкции и доступ к журналам диагностики.

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

8. Добавьте сценарий отката

Откат должен быть подготовлен до начала переключения. В ТЗ укажите событие, при котором принимается решение об откате, лицо с правом такого решения и максимальное время ожидания исправления.

Сценарий должен содержать:

1. возврат предыдущей маршрутизации входящей почты;
2. восстановление прежних параметров доступа пользователей;
3. сохранение сообщений, поступивших в целевую систему до отката;
4. повторную синхронизацию после устранения причины;
5. уведомление пользователей и службы поддержки;
6. фиксацию инцидента и решение о новом окне миграции.

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

9. Распределите ответственность

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

Для каждого этапа укажите:

• кто выполняет действие;
• кто предоставляет данные и доступы;
• кто согласует результат;
• кто принимает решение о продолжении или откате;
• какой документ подтверждает завершение этапа.

10. Зафиксируйте результаты проекта

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

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

Итоговый чек-лист ТЗ

• описаны исходная и целевая архитектуры;
• составлен полный реестр ящиков, адресов и интеграций;
• определены переносимые и исключённые данные;
• выбрана поэтапная схема с предварительной и финальной синхронизацией;
• запланирован пилот с критериями допуска;
• описано переключение MX, SPF, DKIM и DMARC;
• установлены измеримые критерии приёмки;
• подготовлен проверяемый сценарий отката;
• назначены ответственные за DNS, системы, безопасность и поддержку;
• определены отчёты, инструкции и документы закрытия проекта;
• указаны ограничения конкретных платформ со ссылками на их официальную документацию;
• вывод старой системы разрешён только после завершения проверки и периода отката.

Источники

• RFC 5321: Simple Mail Transfer Protocol
• RFC 5322: Internet Message Format
• RFC 7208: Sender Policy Framework
• RFC 6376: DomainKeys Identified Mail
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance