Ночной сбой почтового сервера: как найти причину

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

Ночь совпала со сбоем — это ещё не причина

Если почта перестаёт отвечать примерно в одно и то же ночное время, расписание фоновых задач — первая гипотеза, а не готовый диагноз. Резервное копирование, проверка файлов, индексация и удаление старых данных могут одновременно читать и записывать хранилище; из-за этого растёт задержка операций, хотя процессор может выглядеть свободным. Но похожую жалобу дают обновление системы, обслуживание у провайдера, ошибка диска, сети, DNS или сбой только одного почтового клиента. Я сначала фиксирую, кто именно не может войти, какие действия не проходят и когда это началось, а затем сравниваю проверку с другого устройства и из другой сети. Для корпоративной почты важна вся цепочка — сервер, сеть и клиент, а не только процесс Postfix. Если нужна помощь с самой инфраструктурой, мы занимаемся корпоративной почтой.

Ответ SMTP 421 означает временную недоступность службы и закрытие соединения; расширенный код 4.3.2 уточняет, что система сейчас не принимает сетевые сообщения. Это не сообщает, сломался ли диск, закончилась ли память или началось обслуживание, и не доказывает, что сервер выключен. При временном отказе отправитель может повторить попытку; Postfix хранит отложенное письмо в очереди и повторяет доставку по расписанию; после неудач интервал между попытками растёт в пределах настроек. Поэтому я проверяю не только доступность SMTP, но и очередь, журнал почтовой службы и события системы за тот же промежуток. Если узел отвечает, сохраняю текущие признаки перед изменениями; если нужно срочно вернуть сервис, не откладываю восстановление ради красивого расследования. Перезапуск сам по себе не стирает сохранённые журналы, но может убрать состояние процессов, которое ещё можно было зафиксировать. Код ошибки — подсказка, а не хрустальный шар.

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

Условный разбор: бэкап спорит за диск с почтой

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

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

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

С чего начать: системный журнал, логи почты и очередь

Пути /var/log/syslog, /var/log/messages и /var/log/mail.log не универсальны. Они зависят от дистрибутива, настройки syslog, почтового стека и способа запуска; Postfix может писать через системный журнал или в настроенный файл, Dovecot тоже допускает разные места назначения. В контейнерной установке сообщения нередко уходят в журнал контейнера или стандартный вывод. На системе с systemd я начинаю с команды journalctl -k --since "yesterday" для событий ядра, затем нахожу фактическое имя службы и читаю её записи за тот же временной интервал. Если используется отдельный файл, сначала выясняю его реальный путь в конфигурации, а не копирую адрес из чужой инструкции. Важны точные отметки времени и часовой пояс: без них соседние строки легко принять за причину.

Ищу сообщения об OOM, остановке или перезапуске службы, ошибках ввода-вывода, заполнении файловой системы и сетевых отказах. Не фильтрую всё подряд по словам ERROR или CRITICAL: формат и уровни сообщений зависят от службы, а важная запись может иметь другой уровень. В Postfix очередь можно посмотреть командой postqueue -p; отдельно проверяю, растут ли отложенные сообщения, повторяется ли один и тот же отказ доставки и меняется ли его текст. По документации Postfix временные неудачи доставки получают следующую попытку по расписанию, поэтому сама очередь не означает, что письма потеряны. Если очередь забита, но сервер продолжает работать, разбираю причины именно этого состояния — есть отдельный материал о том, почему очередь Postfix растёт. Журналы рассказывают последовательность событий; они не выдают виновного без проверки.

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

Как отличить давление на память от задержки диска

Для памяти я смотрю не на занятый процент сам по себе, а на динамику: доступную память, активность подкачки, задержки процессов и события OOM в журнале ядра. Заполненная RAM не обязательно означает аварию — операционная система использует её для кэша. И наоборот, процесс может упереться в собственный лимит, даже если на машине в целом память ещё есть. Команда vmstat 1 5 выводит первым среднее с момента загрузки, а следующие строки — выбранные интервалы; для сравнения смотрю на последующие строки и обычное состояние системы. Если ядро записало, что OOM killer завершил процесс, это прямое подтверждение нехватки доступной памяти в том контексте, а не основание автоматически добавить RAM. Следующий шаг — выяснить, какой процесс и какой лимит стали причиной, и проверить, повторяется ли событие.

Для диска подойдут команды iostat -xz 1 5 и проверка свободного места на нужной файловой системе. В расширенном выводе await отражает среднее время обслуживания запроса вместе с ожиданием в очереди, а %util — долю времени, когда выполнялись запросы. Порог вроде «выше 80 процентов — диск перегружен» нельзя применять ко всем накопителям: для устройств с параллельной обработкой один этот показатель не показывает предел производительности. Я сопоставляю задержку, длину очереди, объём чтения и записи с конкретным процессом и сообщениями ядра. Растущий swap также не равен автоматически неисправной памяти: важны активный обмен страницами и заметное замедление. Диагноз складывается из нескольких согласованных признаков; один столбец в iostat его не ставит.

• Снимайте несколько интервалов vmstat, а не один показатель.
• Проверьте журнал ядра на OOM и ошибки диска.
• Сравните await, очередь и операции записи в iostat.
• Проверьте свободное место именно на разделе с почтовыми данными.

Cron, таймеры и приоритет фоновой работы

Не все задания живут в /etc/crontab. У каждого пользователя может быть собственная таблица; системные задания могут лежать в /etc/cron.d/, а часть расписаний запускается таймерами systemd или средствами программы резервного копирования. Я проверяю пользовательскую таблицу командой crontab -l от имени нужной учётной записи, системные места — по документации конкретного дистрибутива, а таймеры — через список systemd timers, если система использует systemd. Затем сверяю расписание не только по времени старта, но и по реальной длительности задания: два процесса могут перекрываться, хотя запускаются в разные минуты. В журнале задачи должны быть начало, завершение и код результата; иначе остаётся лишь гадать, закончилась ли копия штатно.

Если фоновой работе мешает конкуренция, сначала меняю расписание или разделяю тяжёлые операции. nice задаёт приоритет планирования CPU, ionice — класс и приоритет операций ввода-вывода в поддерживаемом планировщике; это способы уступить ресурсы, а не жёсткое ограничение скорости и не гарантия, что проблема исчезнет. Перед изменением проверяю, как ведёт себя конкретная файловая система и хранилище, затем измеряю результат на следующем цикле. Не ставлю копирование на «самое тихое время» по календарю, пока не посмотрел фактические пики и окно восстановления. Плановая задача должна иметь журнал, понятный результат и владельца, который проверяет восстановление. Автоматизация полезна ровно настолько, насколько её результат можно проверить.

• Проверьте таблицы cron всех нужных пользователей.
• Учитывайте системные cron-задания и таймеры systemd.
• Сверьте длительность задач и фактическое перекрытие.
• Применяйте nice и ionice как приоритеты, не как лимиты.

Что проверить после устранения ночного сбоя

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

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

• Проверьте приём, доставку и чтение тестового письма.
• Убедитесь, что очередь сокращается штатно.
• Сравните показатели до и после изменения.
• Запишите причину, действие, результат и план отката.

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