Коли говорять про масштабування GLPI, зазвичай згадують MySQL, Redis, PHP-FPM або продуктивність сервера. Але на практиці одним із перших вузьких місць часто стає зовсім інше — електронна пошта.

GLPI активно використовує email практично для кожної події в системі:

  • створення заявки;
  • призначення виконавця;
  • додавання нового коментаря чи рішення (Follow-up);
  • зміна статусів та погодження (Validation);
  • контроль SLA та автоматичні правила;
  • повідомлення про закриття тикету.

У невеликій компанії це можуть бути десятки повідомлень на день. У великій інсталяції — вже десятки тисяч листів щомісяця.

Саме з цією проблемою я зіткнувся кілька років тому.

Моє навантаження

У моїй інсталяції GLPI щомісяця реєструється приблизно 6 000–7 000 нових заявок. Але це зовсім не означає 6 000–7 000 листів. Кожна заявка генерує щонайменше п'ять повідомлень за своїм життєвим циклом:

  • підтвердження створення заявки для заявника;
  • повідомлення про призначення виконавцю та групі підтримки;
  • повідомлення призначеним спостерігачам;
  • повідомлення про виконання заявки заявнику;
  • повідомлення про виконання заявки спостерігачу.

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

У результаті GLPI без проблем генерує десятки тисяч транзакційних email-повідомлень щомісяця.

Чому звичайний SMTP перестає працювати

На початку більшість використовує стандартний SMTP-сервер корпоративної пошти або хостинг-провайдера. Це працює до певного моменту, поки не починають з'являтися типові проблеми:

  • жорсткі денні або погодинні ліміти на відправлення;
  • погіршення репутації спільної IP-адреси через розсилки сусідів по хостингу;
  • тимчасові блокування з боку поштових сервісів отримувачів;
  • обмеження на кількість одночасних з'єднань.

І якщо GLPI використовується як критичний корпоративний Service Desk, ці обмеження рано чи пізно стають помітними, призводячи до затримок у комунікаціях.

Чому я не використовую власний SMTP

У моїй інфраструктурі працює власний поштовий сервер на базі Mailcow. Тому справа не в тому, що я не можу адмініструвати поштовий сервер. Навпаки, саме досвід роботи з Mailcow допоміг мені зрозуміти, що корпоративна пошта і транзакційна пошта — це дві абсолютно різні задачі.

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

  • стабільна доставлюваність (high deliverability);
  • кришталева репутація IP-адрес відправника;
  • автоматична обробка Bounce (помилок доставки) та Complaint (скарг на спам);
  • еластична масштабованість без навантаження на диски та процесор;
  • мінімальні витрати часу на підтримку.

Саме тому для GLPI я використовую AWS Simple Email Service (SES).

Чому саме AWS SES

AWS SES я використовую вже понад три роки. За цей час сервіс відправив сотні тисяч повідомлень. За весь цей період:

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

Раз на місяць я відкриваю AWS Console, переглядаю основні метрики (Delivery Rate, Bounce Rate, Complaint Rate, Reject Rate) і просто закриваю вкладку. За три роки мені жодного разу не довелося вручну розгрібати поштові черги. Для мене це одна з найкращих характеристик будь-якого інженерного рішення.

Вартість

Часто можна почути, що сервіси AWS — дорогі. У випадку з SES мій досвід зовсім інший. При навантаженні 6 000–7 000 нових заявок на місяць витрати становлять приблизно 5–6 USD на місяць. Для мене це значно дешевше, ніж витрачати власний час на підтримку та очищення репутації власного SMTP-сервера.

Production Access — єдиний складний етап

Після створення Amazon SES акаунт спочатку працює у режимі Sandbox. Це означає, що можна відправляти повідомлення лише на підтверджені email-адреси, а ліміти відправлення є мінімальними. Використовувати сервіс у production на цьому етапі неможливо.

Щоб отримати production-доступ, потрібно подати окремий запит. Підтримка AWS дуже уважно ставиться до таких заявок, щоб запобігти спаму, і просить детально описати сценарій використання сервісу. У моєму випадку вони попросили пояснити:

  • як часто будуть надсилатися повідомлення та їхній очікуваний об'єм;
  • хто є отримувачами повідомлень;
  • як формується список адрес і чи давали користувачі згоду;
  • як обробляються Bounce та Complaint повідомлення;
  • надати приклади реальних повідомлень.

Рекомендую відповідати максимально детально. Формальні відповіді лише затягують отримання production-доступу.

Що допомогло пройти модерацію

З власного досвіду можу порадити кілька речей:

  • Чітко зазначте, що це TRANSACTIONAL email, а не маркетингові розсилки чи спам.
  • Поясніть, що повідомлення генеруються системою Service Desk і надсилаються лише співробітникам або клієнтам, які вже зареєстровані в системі та взаємодіють із тикетами.
  • Додайте приклад повідомлення. При цьому я рекомендую надсилати простий текстовий лист (Plain Text) без складних HTML-шаблонів — це виглядає зрозуміліше і викликає менше питань у модераторів.

Додаток: приклад запиту на отримання Production Access

Нижче наведено приклад запиту, який успішно пройшов модерацію AWS. Перед використанням обов'язково адаптуйте його під власний сценарій використання та інфраструктуру:

Production access request
Service: SES Sending Limits
Region: eu-north-1

Please enable production access.

Use case:
Transactional email notifications generated by GLPI Service Desk.

Mail Type:
TRANSACTIONAL

Website:
https://example.com

Our service desk sends notifications to registered employees, contractors and customers based on ticket lifecycle events.

Typical events include:
- new ticket created;
- engineer assigned;
- observer assigned;
- ticket status changed;
- ticket resolved.

Recipient addresses belong only to users registered in our service desk according to existing contracts and internal processes.

We process bounce and complaint notifications and monitor Amazon SES reputation metrics.

Attached is a sample transactional message generated by our service desk.

Після переходу в Production

Після схвалення заявки AWS автоматично збільшує ліміти. У моєму випадку було надано ліміт у 50 000 повідомлень на добу при швидкості 14 повідомлень на секунду. Для більшості інсталяцій GLPI цього більш ніж достатньо.

Після цього ви отримуєте SMTP Endpoint та SMTP Credentials, які вказуєте у налаштуваннях пошти в GLPI. З боку GLPI інтеграція нічим не відрізняється від підключення до звичайного поштового сервера.

Не забудьте про моніторинг

Після переходу в production я рекомендую одразу налаштувати:

  • AWS Budget: для контролю витрат та миттєвих сповіщень про перевищення ліміту бюджету;
  • CloudWatch Alarms: сповіщення про перевищення критичних лімітів Bounce Rate (бажано тримати нижче 2-5%) та Complaint Rate (має бути нижче 0.1%).

Це допоможе дізнатися про проблеми (наприклад, зациклення відправки повідомлень через помилку налаштування правил в GLPI) значно раніше, ніж SES тимчасово призупинить відправлення через падіння репутації.

DNS теж має значення

Перед початком надсилання листів обов'язково пропишіть для вашого домену записи SPF, DKIM та DMARC для домену AWS SES. Це критично важливо для того, щоб ваші листи не потрапляли в спам у Gmail, Outlook чи інших корпоративних поштових сервісах отримувачів.

Висновок

Я не вважаю AWS SES універсальним рішенням для всього. Але для GLPI, який генерує десятки тисяч повідомлень, він став одним із найменш вимогливих до супроводу сервісів. Кілька годин на початкове налаштування, близько 5–6 доларів на місяць та понад три роки стабільної роботи без жодного інциденту. Для мене це чудовий приклад того, як хороша інженерія допомагає обрати рішення, просте в експлуатації не лише сьогодні, а й через роки.

На завершення

У цій статті я свідомо розглянув лише сценарій використання AWS SES як SMTP-сервісу для транзакційних повідомлень GLPI.

Насправді можливості Amazon SES значно ширші. Сервіс підтримує API для відправлення пошти, обробку Bounce та Complaint через Amazon SNS, Configuration Sets, Virtual Deliverability Manager, вхідну пошту, suppression list, dedicated IP та багато інших можливостей для побудови масштабованих поштових рішень.

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

Корисні посилання