Postfix: План дій при збої черги (коли пошта раптово зупиняється)

Швидкий playbook діагностики (перші 15 хвилин)

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

Хвилина 0–2: Підтвердіть режим відмови

• Пошта не заходить в систему? (проблема з прийманням SMTP, postscreen, TLS, фаєрвол)
• Пошта заходить, але не виходить? (проблеми віддаленої доставки, ріст deferred)
• Пошта виходить, але з запізненням? (вузьке місце пропускної здатності: диск, DNS, фільтр контенту, ліміти швидкості)

Хвилина 2–5: Визначте, яка черга зростає

• Затори на етапі прийому/cleanup: багато повідомлень у maildrop або інтенсивна активність cleanup
• Затори в active: active лишається величезною; qmgr не встигає переміщувати
• Затори в deferred: віддалена доставка не працює або повільна; таймери backoff наростають

Хвилина 5–10: Знайдіть ресурс, що насичений

• Диск/IOPS: інтенсивні операції в директоріях черги; fsync-шторм; RAID-контролер тихо стогне
• DNS: повільні MX-запити, RBL-запити, таймаути DNS
• Мережа: вихідний порт 25 заблокований/фільтрується; втрата пакетів; дивний MTU
• CPU: TLS‑handshake, сканування контенту, regex-карти, milters
• Ліміти конкурентності: по‑доменні обмеження, default_destination_concurrency_limit, обмеження anvil

Хвилина 10–15: Виберіть одну безпечну дію

• Якщо диск заповнений: зупиніть «кровотечу» (тимчасові відмови), звільніть місце, не робіть flush.
• Якщо DNS повільний: виправте резолвер або тимчасово обійдіть RBL; не збільшуйте конкурентність.
• Якщо зовнішній фільтр повільний: обійдіть або масштабируйте його; не перезапускайте Postfix постійно.
• Якщо віддалений провайдер відмовляє: обмежте швидкість по домену; не намагайтесь «вибити» чергу циклом flush.

Цитата, щоб тримати себе в рамках. Парафраз ідеї W. Edwards Deming: «Без даних ви лише ще одна людина з думкою». У збої черги думки — це те, як ви отримуєте другий інцидент.

Ментальна модель збоїв черги

Postfix — це конвеєр з буферами. Коли один етап сповільнюється, буфери вище заповнюються. Ваше завдання — знайти повільний етап і або прискорити його, або зменшити вхідний потік, щоб система могла спорожнити чергу. Небезпека в тому, що сама черга перетворюється на навантаження: кожне повідомлення — це маленький файл, кожна повторна спроба дає додатковий дисковий IO, кожен bounce — ще більше пошти.

Що насправді означає «meltdown»

Справжній злам черги — це не просто «багато листів». Це «система витрачає більше часу на керування чергою, ніж на доставку пошти». Ви бачите це як:

• швидке зростання deferred і/або active черг
• середнє навантаження зростає без відповідного корисного throughput
• зростання використання диску і IO wait
• повторювані рядки логів з однаковими тимчасовими помилками
• накопичення поштових процесів: smtp, qmgr, cleanup, trivial-rewrite, tlsmgr

Три категорії зупинки

1. Зупинка прийому: збої вхідних з’єднань, невдачі submission або неможливість поставити в чергу.
2. Зупинка планування: повідомлення в черзі, але qmgr не може розподіляти/доставляти достатньо швидко.
3. Зупинка доставки: віддалена доставка не працює, повільна або обмежена, тому домінує deferred.

Головне — встояти перед спокусою «заспамити flush». Це як вирішувати затор, відкривши всі заїзди і наказавши водіям їхати швидше. Затор просто переміститься далі, зазвичай на диск.

Жарт №1: SMTP означає «Інколи Пошта Трохи Припиняється». На жаль, пауза завжди під час робочих годин.

Цікаві факти та історичний контекст

Пошта старша за брендинг вашого cloud-провайдера, і багато її гострих країв — це історичні артефакти. Декілька конкретних фактів, що допомагають під час інцидентів:

1. Postfix створювався як безпечна альтернатива Sendmail, з багатьма невеликими процесами щоб зменшити зону ураження при проблемах.
2. SMTP розроблявся для дружнього Інтернету: тимчасові помилки і повтори — це фундаментальна властивість, а не виняток — ваша черга це передбачена функція.
3. Поведінка backoff — навмисна: Postfix не буде безпереервно бити по віддаленому домену; він розносить повтори, щоб бути ввічливим і уникнути само-DDoS.
4. Дизайн «черга як файли» означає, що продуктивність зберігання значно важливіша, ніж багато команд очікує; тисячі дрібних файлових операцій можуть розбити повільний диск.
5. DNS — частина критичного шляху для віддаленої доставки. Коли резолвери повільні, пошта «зупиняється», хоча сам Postfix цілком здоровий.
6. Greylisting повернувся в епоху спаму: він навмисно створює тимчасові відмови, що може вибухнути розміром черги, якщо не планувати потужність.
7. RBL-запити — прихована залежність: один повільний або зламаний постачальник чорного списку може гальмувати SMTP-сесії і голодувати пропускну здатність.
8. TLS всюди підвищив навантаження на CPU на з’єднання; на завантажених реле-handshake це реальний фактор масштабу.
9. Обмеження від поштових провайдерів — нормальне явище: великі провайдери агресивно відкладають, коли ви сплеск обсягу або підриваєте репутацію; ви не можете «перевищити» репутацію через підвищення конкурентності.

Практичні завдання: команди, що означає вивід, яке рішення приймати

Це ті завдання, які я реально виконую, коли дзвонить тревога. Кожне з них має три частини: команда, як її читати і яке рішення вона підштовхує. Використовуйте їх у порядку, а не як шведський стіл.

Завдання 1: Перевірити, що Postfix запущений і що він «думає»

cr0x@server:~$ systemctl status postfix --no-pager
● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled)
     Active: active (running) since Tue 2026-02-04 09:12:08 UTC; 2h 14min ago
   Main PID: 1243 (master)
      Tasks: 6 (limit: 18689)
     Memory: 21.3M
     CGroup: /system.slice/postfix.service
             ├─1243 /usr/lib/postfix/sbin/master -w
             ├─1301 qmgr -l -t unix -u
             ├─1302 pickup -l -t unix -u
             └─1303 tlsmgr -l -t unix -u

Значення: Якщо Postfix не активний, ви в категорії «служба впала». Якщо активний — проблема зазвичай віддалена (DNS, мережа, фільтри) або локальна (диск повний, права).

Рішення: Якщо inactive/failed — перевірте журнали journal перш ніж перезапускати. Якщо active — не перезапускайте імпульсивно; збирайте докази спочатку.

Завдання 2: Побачити розмір і форму черги одним поглядом

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5     2456 Tue Feb  4 11:23:05  alerts@example.net
                                         user1@corp.tld

F6G7H8I9J0     1879 Tue Feb  4 11:23:06  noreply@corp.tld
                                         external@bigmail.tld

-- 4821 Kbytes in 217 Requests.

Значення: Останній рядок — заголовок. Requests — це записи черги; не обов’язково унікальні листи, якщо є кілька отримувачів у повідомленні.

Рішення: Якщо requests швидко зростають — переходьте до «яка черга зростає» і «чому доставка не працює».

Завдання 3: Розділити counts active vs deferred vs maildrop

cr0x@server:~$ postqueue -p | tail -n 1
-- 4821 Kbytes in 217 Requests.

cr0x@server:~$ find /var/spool/postfix/active -type f | wc -l
53

cr0x@server:~$ find /var/spool/postfix/deferred -type f | wc -l
10241

cr0x@server:~$ find /var/spool/postfix/maildrop -type f | wc -l
0

Значення: Великий deferred з малим active часто означає, що віддалена доставка не працює/обмежена. Великий maildrop може вказувати на проблеми pickup/cleanup або уповільнення фільтрів контенту.

Рішення: Великий deferred: фокусуйтеся на віддалених відповідях і мережі/DNS. Великий maildrop: перевірте локальний pipeline (cleanup, milters, диск, права).

Завдання 4: Прочитати останні 15 хвилин поштових логів по‑дорослому

cr0x@server:~$ journalctl -u postfix --since "15 min ago" --no-pager | tail -n 80
Feb 04 13:18:02 server postfix/smtp[22190]: connect to bigmail.tld[203.0.113.10]:25: Connection timed out
Feb 04 13:18:02 server postfix/smtp[22190]: A1B2C3D4E5: to=<external@bigmail.tld>, relay=none, delay=620, delays=0.1/0.1/620/0, dsn=4.4.1, status=deferred (connect to bigmail.tld[203.0.113.10]:25: Connection timed out)
Feb 04 13:18:05 server postfix/qmgr[1301]: warning: private/anvil: connection refused
Feb 04 13:18:05 server postfix/master[1243]: warning: process /usr/lib/postfix/sbin/anvil pid 22144 exit status 1

Значення: «Connection timed out» вказує на проблеми з мережею egress, блокування провайдера або маршрутизацією. Anvil, що падає — локальний симптом (виснаження ресурсів, ліміти або проблеми файлової системи).

Рішення: Для таймаутів — перевірте вихідну підключеність і політику порту 25. Для помилок anvil — перевірте диск/іноди і обмеження процесів перед перезапуском.

Завдання 5: Перевірити підключення до порту 25 у світі

cr0x@server:~$ nc -vz -w 5 203.0.113.10 25
nc: connect to 203.0.113.10 port 25 (tcp) timed out: Operation now in progress

Значення: Якщо це таймаут для багатьох хостів — мережевий шлях заблокований або зламаний. Якщо працює до деяких хостів, але не до інших — можливо блокування/маршрутизація специфічні для провайдера.

Рішення: Якщо вихідний 25 заблокований — припиніть налаштовувати Postfix і починайте розмову з мережею або хмарним провайдером. Жодне налаштування черги не вирішить політику.

Завдання 6: Перевірити здоров’я DNS і затримки запитів

cr0x@server:~$ dig +tries=1 +time=2 MX bigmail.tld
;; communications error to 10.0.0.53#53: timed out
;; no servers could be reached

Значення: Якщо DNS не відповідає швидко, Postfix не зможе надійно маршрутизувати пошту. Ви побачите deferrals, повільні сесії і зростаючі черги.

Рішення: Спочатку виправте резолвери (доступність, продуктивність, кешування). Розгляньте тимчасове зменшення DNS-залежних перевірок (RBL) під час інциденту — обережно, з планом відкату.

Завдання 7: Визначити топ причин відкладання

cr0x@server:~$ grep -h "status=deferred" /var/log/mail.log | tail -n 2000 | sed -E 's/.*deferred \((.*)\)$/\1/' | sort | uniq -c | sort -nr | head
  312 connect to bigmail.tld[203.0.113.10]:25: Connection timed out
  141 host mx.other.tld[198.51.100.25] said: 451 4.7.1 Try again later
   88 lost connection with mx.slow.tld[192.0.2.77] while receiving the initial server greeting

Значення: Це перетворює скаргу «пошта впала» на ранжовані причини. Таймаути відрізняються від 451 deferral; виправлення теж різні.

Рішення: Таймаути: мережа. 451 try later: віддалене обмеження/репутація — тому обмежуйте швидкість. Втрачене привітання: віддалений сервер повільний/перевантажений або ваша мережа нестабільна; зменшіть конкурентність і таймаути.

Завдання 8: Перевірити, чи звужена вузьким місцем CPU або IO

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  1      0 184320  22112 612300    0    0   120   980  900 1400 12  8 55 25  0
 3  2      0 182900  22120 612400    0    0   110  2200 1100 1800 10  7 40 43  0

Значення: Високий wa означає IO wait: диск — вузьке місце. Високі us/sy — CPU-звуження (TLS, milters, сканування).

Рішення: Високий IO wait: зменшіть churn черги, уповільніть прийом, розгляньте перенос черги на швидше сховище. CPU високо: зменшіть TLS-навантаження, масштабируйте сканування або знизьте конкурентність до стабілізації.

Завдання 9: Перевірити простір на файловій системі спулу та вичерпання інодів

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        20G   19G  700M  97% /

cr0x@server:~$ df -i /var/spool/postfix
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2      1310720 1299900 10820   100% /

Значення: Черги дуже «голодні» до інодів. Можна мати вільний простір і все ще бути мертвим, або мати іноди і бути мертвим. Для користувача обидва відчуття — «пошта зупинилась».

Рішення: Якщо простір/іноди на межі: припиніть приймати неважливу пошту, очистьте непоштовий сміття і плануйте контрольоване спорожнення. Не запускайте flush цикл на файловій системі, що заповнена на 97%.

Завдання 10: Перевірити, які процеси Postfix накопичуються

cr0x@server:~$ ps -eo pid,comm,pcpu,pmem,args --sort=-pcpu | head -n 15
 22501 smtp       22.4  0.2 postfix/smtp
 22480 smtp       18.1  0.2 postfix/smtp
 22310 cleanup    12.5  0.1 postfix/cleanup
 1301  qmgr        6.2  0.2 qmgr -l -t unix -u
 1243  master      0.1  0.1 /usr/lib/postfix/sbin/master -w

Значення: Багато smtp може означати віддалені уповільнення або надто велику конкурентність. Високий cleanup може вказувати на header_checks, milters або дискову конкуренцію.

Рішення: Якщо smtp домінує і дефери — віддалені: обмежте і зменшіть конкурентність. Якщо cleanup домінує: перевірте фільтри контенту, карти і стан диску.

Завдання 11: Підтвердити, які ліміти реально використовує Postfix

cr0x@server:~$ postconf -n | egrep -i 'queue|concurrency|recipient|timeout|anvil|milter|smtpd_client|stress|dns'
default_destination_concurrency_limit = 20
smtp_destination_concurrency_limit = 20
smtp_connect_timeout = 30s
smtp_helo_timeout = 30s
smtp_data_xfer_timeout = 180s
smtpd_milters = inet:127.0.0.1:8891
milter_command_timeout = 30s
minimal_backoff_time = 300s
maximal_backoff_time = 4000s

Значення: Це показує, чи ви налаштовані на здорову пропускну здатність або на хаос. Таймаути milter і DNS — часті тихі вбивці.

Рішення: Якщо конкурентність висока, а віддалені повільні — зменшіть її. Якщо таймаути надто короткі, ви можете спричиняти власні дефери; налаштовуйте обережно і тестуйте.

Завдання 12: Знайти топ доменів-отримувачів, що засмічують чергу

cr0x@server:~$ postqueue -p | awk '/^[A-F0-9]/ {id=$1} /@/ {print $NF}' | sed -n 's/.*@//p' | tr -d '><,' | sort | uniq -c | sort -nr | head
  842 bigmail.tld
  317 other.tld
  205 slow.tld

Значення: Часто один домен отримувач домінує. Це ваш важіль: обмежте саме цей домен замість того, щоб карати всіх.

Рішення: Застосуйте по‑доменні ліміти конкурентності або transport maps, щоб ізолювати проблемний домен. Не збільшуйте глобальну конкурентність, щоб «докомплектувати» чергу.

Завдання 13: Безпечно переглянути історію одного файлу черги

cr0x@server:~$ postcat -q A1B2C3D4E5 | sed -n '1,80p'
*** ENVELOPE RECORDS active A1B2C3D4E5 ***
message_size:            2456
message_arrival_time: Tue Feb  4 11:23:05 2026
sender: alerts@example.net
named_attribute: log_ident=postfix/smtp
recipient: external@bigmail.tld
*** MESSAGE CONTENTS A1B2C3D4E5 ***
Received: from app01 (app01 [10.10.10.21])
        by server (Postfix) with ESMTP id A1B2C3D4E5
        for <external@bigmail.tld>; Tue,  4 Feb 2026 11:23:05 +0000 (UTC)
Subject: Alert: job failed

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

Рішення: Якщо час надходження старий і спроби постійно не вдаються — припиніть вважати це транзитним; можливо це політика (заблокований IP, репутація, зовнішнє фільтрування).

Завдання 14: Заміряти поведінку менеджера черги і попередження

cr0x@server:~$ postqueue -j | head -n 5
{"queue_name":"deferred","queue_id":"A1B2C3D4E5","arrival_time":1707055385,"message_size":2456,"sender":"alerts@example.net","recipients":["external@bigmail.tld"]}
{"queue_name":"deferred","queue_id":"F6G7H8I9J0","arrival_time":1707055386,"message_size":1879,"sender":"noreply@corp.tld","recipients":["external@bigmail.tld"]}

Значення: JSON-вивід зручний для скриптів. Можна відбирати й робити швидкі підрахунки без парсингу людського формату.

Рішення: Використовуйте це для цілеспрямованого втручання (по‑доменні обмеження, знаходження великих повідомлень) замість випадкових flush.

Завдання 15: Безпечно обмежити за призначенням (хірургічно, не глобально)

cr0x@server:~$ postconf -e "smtp_destination_concurrency_limit=10"
cr0x@server:~$ postconf -e "default_destination_concurrency_limit=10"
cr0x@server:~$ systemctl reload postfix

Значення: Зниження конкурентності зменшує тиск на диск, DNS і віддалені сервери. Reload безпечніший, ніж restart під час великої черги.

Рішення: Якщо ви отримуєте таймаути або 451 defers — throttling часто покращує throughput, зменшуючи повтори і churn з’єднань.

Завдання 16: Призупинити прийом, коли спул вмирає

cr0x@server:~$ postconf -e "smtpd_soft_error_limit=5"
cr0x@server:~$ postconf -e "smtpd_hard_error_limit=10"
cr0x@server:~$ systemctl reload postfix

Значення: Це не повна зупинка, але примусить злі/поламані клієнти відступити. Для реальної паузи прийому можна тимчасово налаштувати фаєрвол або master.cf, але почніть з м’яких гальм.

Рішення: Якщо диск/іноди майже вичерпані — потрібно зменшити вхід. Спорожнення не виграє гонку з нескінченним потоком.

Завдання 17: Запустити контрольований requeue (тільки коли відомо чому)

cr0x@server:~$ postqueue -f
cr0x@server:~$ postqueue -p | tail -n 1
-- 4809 Kbytes in 214 Requests.

Значення: Flush каже Postfix спробувати знову скоріше. Це допомагає після виправлення DNS або мережі. Також це може підривати диск, якщо корінь проблеми ще присутній.

Рішення: Виконуйте flush лише після усунення вузького місця і зниження конкурентності за потреби. Flush — це «спробуй зараз знову», а не «зроби так, щоб зникло».

Завдання 18: Перевірити затримки файлової системи, що вбивають throughput

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.12    0.00    7.44   41.20    0.00   41.24

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              8.10  210.30   220.1  5400.7  58.4   3.9   92.1

Значення: Високий await і висока %util вказують на насиченість пристрою. Операції черги Postfix чутливі до затримок, а не до пропускної здатності.

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

Де Postfix «тане»: поширені вузькі місця

1) Сховище: ваша черга — це benchmark з дрібними файлами, якого ви не просили

Postfix використовує файлову систему як надійну чергу. Це означає, що операції метаданих, пошук по директоріях, поведінка fsync і доступність інодів мають значення. Коли черги зростають, Postfix виконує більше файлових операцій: create, rename, unlink, stat, open, close. Помножте на тисячі — і ви вже не «відсилаєте пошту». Ви навантажуєте ext4/XFS і все, що під ним.

Шаблон відмови: IO wait зростає, qmgr і cleanup виглядають зайнятими, throughput падає, черга зростає швидше, потім диск наповнюється deferred-поштою і логами. Система перетворюється на машину, що стрибає навколо диску у формі пошти.

2) DNS: тиха залежність, що може зупинити всю доставку

Кожна віддалена доставка потребує DNS: MX-запит, A/AAAA, інколи PTR, плюс будь-які політики, що ви підключили. Збої DNS часто виглядають як таймаути і deferred-пошта, що відчувається як «Postfix зламався», коли насправді це ваш резолвер, шлях до нього або перевантажений кеш.

Типовий винуватець: RBL або перевірки репутації. Це також DNS‑запити. Один повільний upstream може додати секунди до кожної SMTP-сесії, що при масштабі перетворюється на повну зупинку.

3) Мережева політика: реальність порту 25

Багато середовищ блокують вихідний порт 25 за замовчуванням. Дехто робить це тихо. Якщо ваш relay у хмарній мережі з жорсткою політикою egress, ви можете отримати «connect timed out» до багатьох призначень. Це не Postfix. Це реальність.

Інший режим мережевої відмови: асиметрична маршрутизація, stateful фаєрволи, що відтинають ідучі SMTP-сесії, або NAT-шлюзи з межами таблиць з’єднань. У випадку meltdown ви створюєте багато з’єднань. NAT таблиці не люблять це.

4) Фільтри контенту та milters: податок на пропускну здатність

Якщо ви запускаєте Amavis, ClamAV, SpamAssassin, OpenDKIM, OpenDMARC або кастомні milters — вітаю: у вас розподілена система. Будь-яка її частина може уповільнитись, заблокуватися або впасти, і Postfix сумлінно поставить вашу біль у чергу.

Типовий симптом: зростає maildrop, процеси cleanup нарощуються, логи показують таймаути milter або «queue file write error». Повільне оновлення антивірусу може відчуватись як повна поштова відмова.

5) Віддалене обмеження і репутація: «451, try again later» — це політика

Коли великий провайдер повертає 4xx відповіді, він каже вам «сповільніться». Це може бути rate‑limit, виявлення сплесків або покарання за репутацію. Найгірша реакція — підвищити конкурентність і запустити flush. Це збільшує спроби з’єднання, збільшує дефери і ще більше шкодить репутації.

Краще: throttle по домену, розтягнути повтори, виправити SPF/DKIM/DMARC, і перестати відправляти сміття. Якщо ви надсилаєте легітимну пошту — стабілізуйте шаблон відправлення.

Жарт №2: «Ми просто перезапустимо Postfix» — це еквівалент електронної пошти команді включити/вимкнути ноутбук — але ноутбук не має deferred-черги жалю.

Сценарії відновлення, що не роблять гірше

Спочатку стабілізуйте: зменшіть вхідне навантаження перед «оптимізацією»

Збої черги часто трапляються під час сплесків: розсилки маркетингу, хвилі скидання паролів, шквал алертів або скомпрометований акаунт, що надсилає спам. Якщо ви продовжуєте приймати у повному обсязі, ви ставитеся до честі, що ваше сховище зможе надолужити сплеск. Це погана ставка.

Варіанти стабілізації від найменш інвазивних до найсерйозніших:

• Обмежити конкурентність, щоб зменшити churn з’єднань і активність диску.
• Тимчасово відключити дорогі перевірки (наприклад повільний RBL), якщо це явно вузьке місце і ви приймаєте ризик.
• Обмежити швидкість зловмисних клієнтів через postscreen/anvil або правила фаєрвола.
• Тимчасово відхиляти некритичну пошту (для певних відправників/доменів), зберігаючи основні потоки.

Спорожнюйте розумно: націлюйтеся на «хворих»

Коли deferred черга домінована одним або двома доменами (часто з великими провайдерами), слід їх ізолювати. Якщо ви ставитесь до всіх однаково, здорові домени постраждають через хворого.

Практичний підхід:

• Знайдіть топ доменів у черзі.
• Застосуйте по‑призначенню throttling (через transport maps або налаштування конкурентності).
• Дайте всьому іншому текти нормально.

Обережно з flush і операціями requeue

Flush доречний після виправлення тимчасової інфраструктурної проблеми: DNS, мережа, рестарт резолвера, відкат фаєрвола. Це недоречно, якщо віддалений сервер все ще відкидає або ваш диск «горить».

Уникайте звички «requeue everything». Requeue торкається кожного повідомлення і може створити більше IO, ніж початкове накопичення. Якщо вузьке місце — диск, requeue — це фактично кардіо для вже виснаженого ресурсу.

Знайте, коли розділяти ролі: relay vs mailbox vs submission

Одна з найнадійніших профілактик — архітектура: відокремити inbound submission від outbound relay, або ізолювати масову розсилку від транзакційної пошти. В разі збоїв, черга масових повідомлень не повинна задушити скидання пароля.

Якщо немає фізичної можливості розділити — можна розділити логічно: окремі IP, окремі транспорти, окремі директорії черг (просунуте), або окремі інстанси сервісу. Мета — містити зони відмови.

Ходи відновлення, специфічні для сховища (те, чого SRE бояться в 3 ранку)

Якщо IO — вузьке місце:

• Не погіршуйте ситуацію: зменшіть конкурентність і вхідний потік. Кожен цикл повторів — додатковий IO.
• Розгляньте перенос черги на швидше сховище (NVMe, краща політика RAID cache, виділений том). Це не робиться «під час інциденту», якщо ви не відрепетирували.
• Шукайте зовнішніх споживачів IO на тому самому томі: логи, бекапи, антивірусні сканування спулу (так, таке буває).

Поширені помилки: симптом → корінь → виправлення

1) Симптом: зростає deferred, в логах «connect timed out»

Корінь: вихідний порт 25 заблокований, проблема маршрутизації, фаєрвол/NAT ліміти або віддалений IP недоступний.

Виправлення: перевірте підключення за допомогою nc до кількох MX; перевірте політику egress; зменшіть конкурентність; припиніть цикли flush; залучіть мережеву команду/провайдера.

2) Симптом: зростає maildrop, процеси cleanup стрибкоподібно ростуть

Корінь: повільний milter/фільтр контенту, повільний диск або важкі перевірки заголовків/тела.

Виправлення: перевірте таймаути milter у логах; тимчасово обходьте некритичні milters; масштабуйте фільтр; підтвердіть IO wait; зменшіть прийом.

3) Симптом: черга велика, але active мала і постійно циклірується

Корінь: віддалене throttling або політика, що викликає повільний cadence retry; або по‑доменна конкурентність занадто мала для вашого шаблону трафіку.

Виправлення: визначте топ домени і повідомлення про дефери; застосуйте по‑доменне throttling і адекватну стратегію повторів; покращте репутацію і шаблони відправлення.

4) Симптом: логи Postfix «queue file write error» або «No space left on device»

Корінь: диск повний або вичерпання інодів на файловій системі спулу.

Виправлення: негайно звільніть простір/іноди; тимчасово припиніть приймати великі/пакетні відправлення; перемістіть логи; очистьте непотрібні файли; потім поступово спорожнюйте чергу.

5) Симптом: CPU високе, багато процесів smtp, логи пов’язані з TLS

Корінь: наклад TLS handshake, занадто багато одночасних вихідних з’єднань або VM, яку бракує CPU.

Виправлення: зменшіть конкурентність; переконайтесь, що немає дорогих пер‑повідомлення операцій; розгляньте налаштування повторного використання сесій; додайте CPU або перемістіть навантаження.

6) Симптом: все повільно, таймаути DNS, нестабільна доставка

Корінь: зламаний/перевантажений резолвер, misconfigured resolv.conf, недоступні DNS-сервери або повільні RBL-запити.

Виправлення: виправте досяжність резолверів і кешування; тимчасово вимкніть найповільніші DNS‑перевірки; підтвердіть затримки і помилки за допомогою dig.

7) Симптом: користувачі бачать «sent», але нічого не приходить; черга не зростає

Корінь: проблема на рівні submission (auth, TLS, фаєрвол), додаток вказує на неправильний relay або пошта маршрутується інакше.

Виправлення: перевірте логи submission (smtpd), помилки аутентифікації і конфіг додатка; підтвердіть, що повідомлення з’являються в черзі за допомогою postcat або логів.

Контрольні списки / покроковий план

Контрольний список A: інцидент «Пошта зупинилась» (30–60 хвилин)

1. Підтвердіть охоплення: тільки вхідні, тільки вихідні чи обидва. Перевірте чергу і логи.
2. Визначте тип черги, що росте: maildrop vs active vs deferred. Використайте підрахунок файлів у директоріях.
3. Ранжуйте причини відмов: розпарсіть останні N деферів з логів.
4. Перевірте місце і іноди на диску: спочатку файлову систему спулу.
5. Перевірте DNS: здоров’я резолвера і швидкість MX-запитів.
6. Перевірте вихідний порт 25: тест підключення до кількох IP MX призначень.
7. Перевірте насичення: vmstat/iostat для IO wait vs CPU.
8. Виберіть один важіль: throttle, обхід фільтра, виправлення DNS, виправлення egress, зупинка прийому.
9. Застосуйте зміну через reload: надавайте перевагу systemctl reload postfix над рестартом.
10. Переглядайте кожні 5 хвилин: тенденції черги, причини деферів, IO.
11. Лише потім розгляньте flush: після усунення вузького місця і приведення конкурентності в адекватний стан.
12. Комунікуйте чітко: що зламалося, що пом’якшено, що далі і очікуваний час спорожнення.

Контрольний список B: контрольоване спорожнення після DNS/мережевого фіксу

1. Тимчасово зменшіть конкурентність, щоб уникнути stampede.
2. Одноразово виконайте flush.
3. Слідкуйте за IO wait і тенденцією черги 10–15 хвилин.
4. Якщо стабільно — підвищуйте конкурентність поетапно невеликими кроками.
5. Зупиніться, коли IO wait різко зростає або дефери повертаються.

Контрольний список C: коли сховище — вузьке місце

1. Припиніть приймати необов’язкові джерела пошти (масові/оповістки), якщо можете.
2. Зменшіть конкурентність глобально.
3. Знайдіть і зупиніть сторонні IO на томі спулу (бекапи, сканування).
4. Звільніть простір/іноди; обертайте логи; перемістіть великі файли з файлової системи.
5. Спорожнюйте повільно; уникайте requeue, що переписує весь спул.
6. Плануйте редизайн зберігання черги після інциденту.

Три корпоративні міні-історії з практики

Міні-історія 1: Відмова через неправильне припущення

Компанія мала «просту» архітектуру: додатки надсилали пошту на Postfix‑relay, relay відправляв у Інтернет. Relay жив на VM з достатнім CPU і, здавалося б, достатнім дисковим простором. Усі припускали, що пошта — низькошвидкісний трафік, тому вона не може навантажити сховище.

Одного понеділка хвиля скидання паролів після зміни SSO накрила систему. Relay приймав пошту, але deferred почав рости. Користувачі кричали. Інженер on‑call перезапустив Postfix двічі — бо так зазвичай роблять, щоб відчути, що вони щось роблять.

Справжня причина була вичерпання інодів. Файлова система мала вільний простір, але не мала інодів на кореневому розділі, де жив /var/spool/postfix. Черга складається з дрібних файлів; кожне повідомлення — податок на іноди. Система не була «впала», вона задихалася через метадані.

Після перевірки df -i виправлення було буденним: очистити непоштові артефакти і перемістити спул на файлову систему з адекватним числом інодів. Перезапуск не зашкодив, але втратився дорогоцінний час — те, що неможливо поповнити під час інциденту.

Міні-історія 2: Оптимізація, що обернулась проти

Інша організація мала високопродуктивний relay і вирішила «дренувати черги швидше». Хтось підняв destination concurrency limits і скоротив backoff retry. У тихих тестах це виглядало круто. Повідомлення полетіли.

Але потім upstream DNS резолвер почав мати інтермітентну латентність. При високій конкурентності Postfix відкривав більше SMTP-сесій, що викликало більше DNS-запитів і ще більше навантаження на резолвер. Доставка сповільнилась, повтори накопичились, черга збільшилась. Диск вийшов на високий IO wait, і логи перетворились на стіну повторюваних дефеїв.

Вони оптимізували під ідеальні умови і випадково створили петлю зворотного зв’язку під неполадками. Висока конкурентність посилила нестабільність DNS; коротший backoff збільшив churn; спул став фабрикою зайвої роботи.

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

Міні-історія 3: Нудна практика, що врятувала день

Фінансова компанія мала строгий контроль змін і звичку, яку інженери люблять висміювати: вони документували «known good» налаштування Postfix і зберігали легкий runbook для поштових інцидентів. Ніхто не хвалився цим — просто воно було.

Одного дня вихідна пошта почала відкладатися з «Try again later» у великого провайдера. Черга росла, але не вибухово. Інженер on‑call відкрив runbook і виконав простий скрипт: знайти топ доменів, застосувати по‑доменне throttling, уникати глобальних flush-циклів і зберегти транзакційну пошту.

У них також були передналаштовані дашборди для заповнення спулу і латентності резолверів. Протягом кількох хвилин вони підтвердили, що DNS в порядку і провайдер throttling-ує. Вони обмежили домен, сповістили про очікуваний час спорожнення і не дали інциденту перерости в кризу.

Провайдер відновився пізніше того вечора. Черга спорожнилася за ніч. Ніякої героїки, ніяких requeue-штурмів, ніяких «перезапустили пошту і все запрацювало» казок. Найкращий інцидент — той, що залишається нудним.

FAQ

1) Чи слід перезапускати Postfix під час збоїв черги?

Рідко. Reload зазвичай безпечніший. Restart може обірвати активні сесії і спричинити більше повторів, а отже — більше churn у черзі. Перезапускайте лише якщо процес завис і ви знаєте, чому.

2) Чи безпечно запускати postqueue -f, коли черга величезна?

Безпечно для цілісності даних, ризиковано для стабільності системи. Flush різко підвищує тиск повторів. Використовуйте його після виправлення тимчасової причини (DNS відновлено, фаєрвол виправлено) і розгляньте зниження конкурентності спочатку.

3) Чому deferred величезний, а active малий?

Тому що Postfix планує обмежену кількість активних доставок і відкладає решту, особливо коли віддалена доставка не працює або обмежена. Малий active може бути ознакою ввічливості, а не слабкості.

4) Який найшвидший спосіб знайти корінь проблеми?

Ранжуйте причини деферів з логів, потім перевіряйте відповідні залежності: вихідний 25 для таймаутів, DNS для проблем із запитами, сховище для IO wait і inode/простору. Не вгадуйте.

5) Як зрозуміти, що вузьке місце — DNS?

Якщо dig таймаутить або повільний, і логи показують помилки DNS або довгі затримки перед «no route to host». Також якщо SMTP-сесії зависають ще до підключення до віддалих MX — часто це DNS.

6) Чи може сама черга спричинити вичерпання диску навіть після початкового сплеску?

Так. Черга створює постійний IO від повторів, записів логів і bounce-повідомлень. Якщо ваш backoff агресивний або конкурентність занадто висока, черга стає самоутримуваним навантаженням.

7) Що робити, якщо лише один провайдер мене відхиляє?

Це поширено. Ізолюйте його: обмежте по домену, зменшіть конкурентність для цього домену і дайте іншим потокам текти. Паралельно працюйте над репутацією, аутентифікацією і стабільним шаблоном відправлення.

8) Чому мені важливі іноди, якщо є вільний простір?

Тому що черга складається з багатьох дрібних файлів. Якщо закінчуються іноди — ви не зможете створити файли черги, навіть маючи байти вільними. Це класична «система виглядає нормально, поки не ні» проблема.

9) Як зрозуміти, що milter — проблема?

Шукайте повідомлення про таймаути milter, зростання maildrop і підвищену активність cleanup. Тимчасове обходження milter (якщо дозволено) — швидкий тест підтвердження.

10) Чи можна видалити чергу, щоб відновитись швидше?

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

Наступні кроки (нудна частина, що запобігає драмі)

Якщо ви в середині інциденту: припиніть сліпо робити flush, визначте тип черги, що росте, ранжуйте причини деферів і перевірте три великі залежності — сховище, DNS, вихідну мережу. Потім застосуйте одну контрольовану зміну і вимірюйте тенденцію. Повторюйте. Інциденти закінчуються, коли черга зменшується, а не коли хтось каже «тепер все має бути добре».

Після інциденту зробіть нудну роботу:

• Виставте моніторинг і алерти для місця у спулі та inode.
• Моніторте латентність DNS і частоту помилок з поштового хоста, а не зі «щасливих» probe.
• Документуйте і застосуйте з’єздні дефолтні налаштування конкурентності і процедури по‑доменного throttling.
• Розділіть транзакційні і масові потоки, якщо пошта важлива для бізнесу (це так).
• Практикуйте контрольоване спорожнення у вікні обслуговування, щоб не імпровізувати о 3-й ранку.

Postfix стабільний. Ваше середовище може бути не зовсім таким. Черга — місце, де ця істина стає видимою.