Часть 2. Ранее рассказал об ИИ-диспетчере: сотрудник пишет в Telegram или MAX, а система регистрирует заявку в GLPI. Но за этой схемой скрывалась инженерная головоломка. ИИ физически работает у меня дома. А боты, база сотрудников и GLPI — в инфраструктуре компании. Как связать сети без публикации домашнего сервера в интернете? Решение оказалось неожиданным: мы использовали электронную почту как транспорт для API-запросов. 📩 Не для переписки людей, а как двусторонний канал между сервисами. Как устроена архитектура 🏢 На рабочем сервере maxbot работает мост: он принимает обращения из Telegram/MAX, определяет контекст диалога и готовит запрос к ИИ. 📨 Запрос сериализуется, подписывается HMAC и отправляется через SMTP. Домашний сервер слушает выделенный ящик через IMAP IDLE — поэтому не нужно каждые несколько секунд опрашивать почту. 🏠 Дома Proxmox, виртуальная машина Ubuntu, RTX 3050 8 ГБ и Ollama с локальной моделью Qwen3. Сервис Support-AI анализирует обращение, обращается к базе знаний и выбирает действие: уточнить проблему, дать ответ или подготовить регистрацию заявки. 🔁 Результат тем же способом возвращается на рабочий сервер, а тот уже взаимодействует с GLPI и мессенджерами. Прямого входящего соединения к домашнему ИИ нет: обе стороны сами подключаются к почтовому серверу. Что пришлось решать по пути? 1. Почта — не очередь сообщений. Письмо может задержаться, прийти повторно или не отправиться с первого раза. Поэтому добавили уникальные идентификаторы запросов, HMAC-подпись и защиту от повторной обработки. А вычисленный ИИ-ответ сохраняется до отправки: если SMTP временно недоступен, не нужно заново «думать» над тем же запросом. 2. Диалоги начали смешиваться. На тестах сообщения разных пользователей пересекались из-за ошибки изоляции conversation_id. Исправили разделение сессий и пересобрали контейнер со свежим кодом. Для диспетчера это критично: чужое сообщение не должно продолжать предыдущую заявку. 3. Не всякое обращение требует тикета. Однажды ИИ корректно классифицировал запрос как информационный, но почтовый мост не знал действия INFO_ONLY и отбросил ответ. Запрос завис, а резервный механизм позже создал лишнюю заявку. Нашли несовпадение форматов, расширили список действий и исправили обработку ответа. Оказалось, проблема была не в нейросети. 4. А если ИИ недоступен? Предусмотрели fallback: обращение не должно бесследно теряться, если домашний сервер выключен или ответ не пришёл. Для защиты от дублей учитываем состояние запроса. Эти сценарии ещё проверяем. 5. Контекст оказался сложнее, чем генерация текста. Нужно правильно связать аккаунты Telegram/MAX с пользователями GLPI, заполнить поля инициатора и местоположения, не добавляя ФИО в описание заявки. Подготовили справочник из 89 сотрудников и 99 привязок аккаунтов. Дополнительно отрабатывали изображения: файл остаётся на рабочей стороне, а ИИ получает сведения о вложении. Не всё нужно передавать модели целиком. 6. Даже TLS устроил сюрприз. Почтовое соединение упиралось в недостающий промежуточный сертификат GlobalSign. Исправили цепочку доверия, а не отключили проверку TLS. И что получилось? Мы проверили полный цикл «рабочий сервер → почта → домашний ИИ → почта → рабочий сервер». В одном из тестов обработка ИИ заняла около 6 секунд, а весь почтовый маршрут — около 7 секунд. Это не SLA: последние изменения ещё проверяем на реальных заявках. Главный вывод: для внедрения локального ИИ не всегда нужны дорогие GPU-серверы в офисе, публичные API и сложная сетевая перестройка. Иногда помогает нестандартное использование привычного сервиса — при продуманной надёжности. А вы бы решились использовать почту как транспорт между двумя сервисами? 🙂 #ЛокальныйИИ #Сисадмин #Python #GLPI #ITSM #Автоматизация #Gor_dan