Почта тормозит на своём сервере в серверной: когда пора в облако

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

Корпоративная почта на своём железе когда-то выглядела разумной экономией: купили сервер, поставили Postfix или Exchange, «свои люди контролируют». Через несколько лет картина другая. Железо стареет, лицензии и обновления превращаются в лотерею, каждый сбой — ручная ночная работа, а требования к антиспаму и доставляемости растут быстрее, чем штат IT.

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

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

Как выглядит деградация «своей» почты

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

Второй — еженедельные глюки без корневой причины. Раз в несколько дней «не работает SMTP», «не синхронизируется IMAP», «календарь двоится». Админ перезапускает службы, чистит очередь, правит конфиг. Бизнес видит только симптом: снова простой и снова «подождите».

Третий — нагрузка на людей, а не на CPU. Один специалист совмещает почту, VPN, 1С и «почините принтер». В отпуске или на больничном почта оказывается без хозяина. Добавьте к этому смену SPF/DKIM/DMARC «на глаз» после жалоб на спам — и репутация домена падает так, что даже исправный сервер уже не спасает доставляемость.

Ошибки, которые удерживают компании на старом сервере

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

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

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

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

Когда облако — не каприз, а здравый смысл

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

Отдельно стоит смотреть на требования регуляторов и доступность. Свой сервер в серверной без георезерва и без понятного допустимая потеря данных и время восстановления — это риск, который сложно объяснить аудитору и страховщику. Облачный контур вроде Yandex 360 закрывает базовые ожидания по доступности, веб-клиенту, мобильным приложениям и админке для HR/IT без ночных дежурств у стойки.

Важно честно оценить объём. Если у вас сложный на своих серверах Exchange с кастомными коннекторами и жёсткой привязкой к Active Directory — миграция потребует проекта, а не «кнопки переезда». Если же почта уже близка к «ящики + календарь + общие папки» — перенос в облако обычно даёт быстрый эффект по стабильности и снижению капитальные затраты.

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

Сначала инвентаризация: список доменов, ящиков, алиасов, квот, правил, общих ресурсов, клиентов (Outlook, мобильные, веб). Затем — решение по волнам: пилотный отдел, потом основные группы, в конце — VIP и ящики с особыми правилами. Параллельно готовите DNS: MX, SPF, DKIM, DMARC, проверку доставляемости на тестовых ящиках.

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

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

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

Экономика и спокойствие, которые даёт облако

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

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

Если почта уже тормозит, сервер в серверной стареет, а админы тонут в инцидентах, имеет смысл спланировать перенос в Yandex 360 как проект с инвентаризацией, волнами миграции и контролем DNS — а не как «переключим MX в пятницу».

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