🔒 CommuniGate Pro: почта, телефония и мессенджер в одном продукте с сертификатом ФСТЭК

Для госсектора и объектов критической информационной инфраструктуры выбор почтовой платформы упирается в документы. CommuniGate Pro закрывает оба уровня: реестровая запись Минцифры № 7112 и сертификат ФСТЭК по 5 уровню доверия.

Архитектурно это монолитное ядро: корпоративная почта (SMTP, IMAP, ActiveSync), мессенджер, IP-телефония (SIP/VoIP), календари и видеосвязь в одном продукте. Для администратора это означает одну точку управления и одну модель безопасности вместо разрозненных почтовика, XMPP-сервера и телефонной АТС. Платформа поддерживает более 15 операционных систем, включая Astra Linux, РЕД ОС и ALT Linux, то есть разворачивается на той же сертифицированной ОС, что и остальная инфраструктура. По данным вендора, в России развёрнуто 3 млн рабочих мест, из них около миллиона в госсекторе.

⚡ Миграция с Exchange строится через режим сосуществования: обе системы работают параллельно с обменом данными о занятости (Free/Busy), а ящики переносятся группами. Почта, календари и контакты переезжают в рамках проекта, мобильные клиенты переключаются через ActiveSync. Административная модель и интеграции проектируются заново, это полноценный проект, а не замена сервера один в один. Главные риски: переподключение мобильных, недонастроенные интеграции и просадка доставляемости. Все снимаются пилотной группой и поэтапным переключением.

✅ Если задача только корпоративная почта из реестра без телефонии, практичнее смотреть на RuPost. Если требований реестра нет и важна близость к Zimbra-стеку, подойдёт Carbonio. CommuniGate Pro оправдан там, где нужен полный набор коммуникаций с подтверждёнными регуляторными документами.

Пошаговый план миграции и критерии выбора между CommuniGate Pro, RuPost и Carbonio — в полном разборе от IT For Prof

⚡ Zimbra Network Edition больше не продлевается. Что дальше?

С 2022 года российские компании лишились продления коммерческих лицензий Zimbra NE и вендорской поддержки на инциденты. Серверы продолжают работать, но обновления безопасности, кластерные сценарии и корпоративные функции ActiveSync фактически заморожены. Open Source Edition жива, но без коммерческого SLA и с неровным развитием. Миграция перестала быть теоретическим вопросом.

Путей два: Carbonio от итальянской компании Zextras и RuPost от Группы Астра. Развилка решается одним вопросом: реестр Минцифры обязателен или нет?

Carbonio: та же команда, другой стек

Zextras годами выпускала расширения для Zimbra. Carbonio — это не форк Zimbra, а самостоятельный продукт, но инструменты миграции заточены именно под переезд с Zimbra OSE: скрипты и imapsync переносят почту, контакты и календари. Модель администрирования узнаваема для тех, кто работал с Zimbra.

Что меняется под капотом: стек строится на Consul для обнаружения сервисов и PostgreSQL 16. Команды CLI другие, zmprov и zmmailbox не перенесутся, синтаксис придётся осваивать заново.

Community Edition бесплатна и разворачивается самостоятельно. Коммерческая версия с расширенными функциями и официальной поддержкой идёт через сертифицированных партнёров Zextras. Главный ограничитель: Carbonio в реестре российского ПО не числится. Для КИИ и госсектора этот аргумент закрывает разговор.

RuPost: реестр и миграция с Exchange

RuPost включён в реестр отечественного ПО под номером 14647 (запись от 23.08.2022). Продукт входит в Группу Астра и ориентирован прежде всего на Astra Linux. По данным вендора, систему используют более 400 000 пользователей.

Встроенный мигратор RuPost заточен под Exchange: режим сосуществования с Exchange на время поэтапного перехода работает из коробки. Для переноса из Zimbra используются стандартные почтовые механизмы: IMAP-синхронизация и экспорт-импорт.

• Реестр Минцифры: Carbonio нет, RuPost да (№ 14647)
• Готовые миграторы из Zimbra: Carbonio (скрипты, imapsync), RuPost (IMAP, экспорт)
• Стоимость входа: Carbonio CE бесплатна, RuPost коммерческий продукт с поддержкой на русском
• Для кого: Carbonio для коммерческих компаний без требований реестра, RuPost для КИИ и госсектора

🔧 Что проверить при переезде

В IT For Prof мы проходим миграцию с Zimbra в несколько этапов: аудит ящиков и доменов, тестовый контур с пилотной группой, поэтапный перенос с контролем целостности, настройка SPF, DKIM и DMARC на новом сервере. Основные риски управляемы при пилотной обкатке: потеря писем на некорректных кодировках, разрыв мобильной синхронизации и недонастроенные фильтры из Zimbra. Весь домен переводим только после проверки пилота, не одним прыжком.

Матрица выбора, этапы переноса ящиков и подводные камни imapsync — как выбрать между Carbonio и RuPost

⚡ Mail и Яндекс отключают бесплатный IMAP: дедлайны 12 и 29 июня 2026

Mail (VK) закрывает бесплатный доступ по IMAP/POP3/SMTP 12 июня, Яндекс — 29 июня 2026. У всех, кто работает с почтой через Outlook, Thunderbird, The Bat или Apple Mail, программа просто перестанет получать письма. Останутся веб-версия и мобильное приложение либо платная подписка.

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

📊 Цены на июнь 2026 за ящик/сотрудника в месяц:
• Mail Space — 199 ₽ или 1 290 ₽/год, ящик остаётся на @mail.ru
• Яндекс 360 Премиум — от 166 ₽/мес при оплате за год
• VK WorkSpace на своём домене — 259/459 ₽ (207/367 ₽ при оплате за год)
• Яндекс 360 для бизнеса — 319/549/1 399 ₽, при этом минимальный тариф с 1 июля 2026 индексируется до 485 ₽

🔧 Свой сервер — другая математика: разовая настройка 15 000 ₽ и аренда 700–1 000 ₽/мес фиксированы и не зависят от числа ящиков. До 5 ящиков подписка дешевле всегда. С 4–5 ящиков свой сервер выгоден, если в штате есть системный администратор. Под ключ с сопровождением окупается с 13–20 сотрудников, и индексация Яндекса сдвигает эту точку ещё ниже. Из реестра Минцифры подойдёт RuPost.

Что сделать до дедлайна: посчитать число ящиков, проверить, кто работает в Outlook/Thunderbird, и не откладывать перенос — DNS-записи и подготовка домена требуют времени.

Расчёт окупаемости своего сервера на 1, 2 и 3 года с таблицами и сравнение по числу сотрудников от IT For Prof — в полном разборе

🔒 Корпоративный ИИ-ассистент в своём контуре: AstrBot + локальная LLM в Docker

Связка локальной языковой модели и AstrBot работает внутри периметра компании: переписка с ботом, эмбеддинги и логи остаются на вашем сервере. Это закрывает 152-ФЗ по локализации и снимает зависимость от внешнего SLA.

Когда сотрудник кидает в публичный ChatGPT фрагмент договора или выписку из CRM, он передаёт это оператору сервиса. Для персданных российских граждан сразу включается 152-ФЗ: согласие субъекта, локализация в РФ, реестровая запись оператора. Запреты тут работают плохо — пока в корпоративном чате нет легального бота, люди заводят учётки на стороне.

⚡ Из чего собирается стек:

• AstrBot — open source, 1000+ плагинов в один клик, MCP, Agent Sandbox для изолированного выполнения кода и Shell
• Мессенджеры: Telegram, Slack, Mattermost (через webhooks), Rocket.Chat, Feishu, DingTalk, WeChat для предприятий
• Слой инференса: Ollama для старта, llama.cpp с GGUF-квантизацией под скромное железо, vLLM/TGI для продакшена с батчингом
• Модели: Llama 3, Qwen 2.5, Saiga, T-lite для open source; GigaChat On-Prem и YandexGPT On-Prem там, где важно происхождение модели

📊 Железо под нагрузку:

• Пилот 5–15 сотрудников: одна потребительская GPU с 16–24 ГБ VRAM, модель 7–13B в квантизации Q4–Q5
• 50–100 активных пользователей: серверная карта 40–80 ГБ или две по 24 ГБ
• CPU-only — рабочий вариант для текстовых задач без жёстких требований к latency

RAG строится по схеме «загрузка → чанки 400–800 токенов с перекрытием → мультиязычный эмбеддер → Qdrant или Weaviate → переиндексация по расписанию». В AstrBot есть встроенная база знаний для пилота; для зрелого сценария выносим RAG в отдельный сервис и подключаем через MCP. Доступ к внутренним API (Service Desk, 1С, Jira) ассистент получает теми же MCP-инструментами.

🔧 Compose-каркас: контейнер AstrBot + Ollama + векторная БД в общем bridge-сетевом интерфейсе Docker, наружу торчит только мессенджер, WebUI закрыт reverse-proxy с корпоративным SSO и 2FA.

Сравнение Mattermost Agents / Matrix baibot / AstrBot, чек-лист сетевой изоляции и журналирования, разбор антипаттерна «бот в общем канале без правил» от IT For Prof — в полном разборе с архитектурой и конфигами

🔧 Запись звонка в Битрикс24 не перематывается: причина в режиме отдачи из S3

Бегунок плеера прыгает в начало, разговор играет только с нуля. В DevTools главный признак — сервер отдаёт 200 OK вместо 206 Partial Content, заголовок Content-Range отсутствует. Браузерный плеер физически отказывается перематывать аудио без поддержки Range-запросов.

Корень — в режиме отдачи файлов из облачного S3. По умолчанию запрос идёт через PHP: модуль clouds скачивает объект через readfile(), держит воркер PHP-FPM на всё время отдачи и заголовок Range игнорирует. Решение — флаг bx_fast_download=Y: Битрикс возвращает X-Accel-Redirect, дальше файл проксирует nginx с поддержкой 206 Partial Content и Range.

Ловушка в том, что в свежем bitrix-env файл /etc/nginx/bx/conf/bitrix_general.conf знает только AWS, Rackspace, Clodo, Google CDN и Selectel. Reg.ru (s3.regru.cloud) и FirstVDS (s3.firstvds.ru) — generic-S3 со своими доменами, в дефолте их нет. Включаешь bx_fast_download=Y — запросы доезжают до финального deny all и получают 403: запись звонка молчит, вложения в чатах и Битрикс24.Диск отваливаются вместе с ней.

Reg.ru и FirstVDS работают по path-style: имя бакета уходит в путь URL (s3.regru.cloud/bucket/key), а не в поддомен как у AWS. Копирование AWS-шаблона даёт 404 от хранилища.

📊 Ключевые различия конфигов под двух провайдеров:
• Reg.ru — more_clear_input_headers 'Authorization' (требует модуль headers_more, в bitrix-env собран по умолчанию)
• FirstVDS — proxy_set_header Authorization "" (штатная директива, дополнительный модуль не требуется)
• Оба — path-style addressing, resolver 77.88.8.8 с ipv6=off
• Endpoint в proxy_pass обязан совпадать со значением в /home/bitrix/www/bitrix/.settings.php

Проверка одной командой: curl -I -H "Range: bytes=0-1023" на URL записи. Правильный ответ — HTTP/1.1 206 Partial Content с заголовком Content-Range: bytes 0-1023/.... Если пришёл 200 OK, флаг bx_fast_download ещё в N или запрос промахнулся мимо нового location-блока. Если 403 — Битрикс отдал редирект, nginx проксировал, но S3 отказал: проверяй endpoint в .settings.php и /var/log/nginx/error.log с точным URL запроса.

✅ Готовые location-блоки nginx для Reg.ru и FirstVDS, команды включения флага через PHP-консоль со сбросом кэша опций и чек-лист проверки через DevTools — в полном разборе от IT For Prof

⚡ 260 хостов, 150 шаблонов — алерт сам создаёт задачу и закрывает её без дежурного

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

Наша боевая инсталляция: 260 хостов разных клиентов, порядка 150 шаблонов. Задачи дежурной смены ведём в ПланФикс. До автоматизации связка держалась на внимательности оператора — на таком объёме это проблема.

Как устроена интеграция

Вся механика держится на двух сущностях Zabbix: тип оповещения Webhook (скрипт на JavaScript) и действия с эскалацией. Роль «памяти» о созданной задаче играют теги события — внешней базы соответствий нет, это сознательное решение.

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

Дальше всё автоматически:
• нажал Acknowledge в Zabbix — задача переходит «В работе»
• триггер восстановился — задача закрывается
• эскалация отменена — задача отменяется, без дублей

Обратная связь тоже работает: принял задачу в ПланФикс — событие в Zabbix подтверждается через JSON-RPC API с комментарием от имени исполнителя.

🔧 Три ключевых решения, которые определили архитектуру

Шумовой фильтр через эскалацию. Операция создания задачи стоит на шаге 2 с условием «Event acknowledged = No». Проблема, мигнувшая на 30 секунд или быстро подтверждённая, задачу не создаёт.

Теги как память. При создании задачи скрипт возвращает Zabbix два тега: __zbx_planfix_taskid и __zbx_planfix_link. Все последующие операции — закрытие, подтверждение, отмена — находят задачу по этим тегам. Внешняя база не нужна.

Строгий порядок доставки. Параметр maxsessions=1 гарантирует, что закрытие задачи не обгонит её создание. Повышать нельзя — иначе операция редактирования придёт по ещё не существующей задаче.

Отмена эскалации — отдельный случай: такое событие маскируется под новую проблему, поэтому в коде скрипта эта проверка стоит первой. Без notify_if_canceled=1 оповещение об отмене вообще не придёт.

Полный код webhook-скрипта на JavaScript, пошаговая настройка медиатипа и чек-лист из 9 пунктов — в разборе интеграции Zabbix и ПланФикс от IT For Prof

⚡ BIRD v2 route-server с автообновлением BGP-префиксов: 12 категорий, один скрипт, резервный кэш на 7 дней

В продакшене мы разворачиваем route-server так: bird.conf живёт в git, локальные настройки и BGP-пиры хранятся отдельно. Фильтры и метки обновляются одной командой git pull, не задевая номер AS, router id и список пиров. BIRD v2 версии 2.16.1 держит более 1000 BGP-сессий в одном потоке при расходе менее 250 МБ RAM на два полных routing view.

Python-агрегатор bird2-bgp-prefix-updater скачивает IPv4-префиксы из RIPEstat и двух источников Antifilter, присваивает каждому одну или несколько числовых меток и пишет результат в /etc/bird/prefixes.bird. Итого 12 активных BGP community с кодами 100–112 (один зарезервирован):

• 100 — RU Combined: все IPv4-сети РФ из RIPEstat
• 101 — Blocked Smart: суммаризация списков заблокированных подсетей
• 102 — подсети из официальных списков Antifilter
• 103 — Gov Networks: сети государственных структур
• 104 — Custom User: Telegram, Cloudflare, Google и custom.lst
• 105 — Reserved: зарезервировано
• 106 — Blocked IP: список ip.lst Antifilter
• 107 — Stripe IP: сети Stripe (API, вебхуки)
• 108 — ByteDance AS396986 (TikTok)
• 109 — Akamai AS20940
• 110 — Roblox AS22697
• 111 — Pinterest AS53620
• 112 — Fastly AS54113

MikroTik, Linux-роутеры и edge-маршрутизаторы получают маршруты с метками и сами решают, что с ними делать. Нужен клиенту только Stripe API через отдельный аплинк — фильтр if (bgp_community ~ [(MY_AS, 107)]) then accept; направит только его, не задевая остальной трафик.

🔧 Ловушка, в которую попадают при первом развёртывании: российская сеть может одновременно лежать в RIPEstat (community 100) и в списке заблокированных подсетей (community 101). Фильтр export_only_ru в bird.conf сначала отбрасывает 101–112, затем разрешает 100 — порядок принципиален. Кэш скачанных ответов хранится 6 часов, повторный запуск агрегатора не порождает сетевого трафика. Если все источники недоступны дольше — скрипт не обнуляет prefixes.bird, а берёт последнюю успешную копию из резервного кэша со сроком жизни до 7 дней. BGP-сессии клиентов продолжают работать без изменений. Для диагностики конкретного адреса команда prefix_updater.py --check 194.67.72.31 за секунду показывает источник и присвоенный community ID.

Архитектуру и команды развёртывания под Debian/Ubuntu и RHEL, полную таблицу кодов community, механику атомарной записи и интеграцию с мониторингом разобрал IT For Prof в детальном техническом руководстве — схема фильтров, шаги установки и диагностика.

⚡ Битрикс24 встаёт по утрам? Виноват модуль «Почта»

Симптом коварен: процессор холодный, MySQL без длинных запросов, swap пуст — а портал отдаёт 502 каждое утро в часы синхронизации IMAP. Мониторинг показывает «всё ок», админ добавляет память — без эффекта. Узкое место сидит в архитектуре PHP-FPM.

Чтение из IMAP-сокета — блокирующая операция: fgets() ждёт ответа Яндекса или Exchange десятки секунд. В стандартном bitrix-env все скрипты крутятся в одном пуле www с pm.max_children порядка 50. Запустились синхронизации десятка ящиков — и воркеры намертво заняты ожиданием почты, живым пользователям обслуживать запросы физически нечем. Перезапуск php-fpm по крону каждые 15 минут (встречали и такое) только убивает сессии и причину не лечит.

🔧 Лечение — изолировать check_mail.php в отдельный пул [mail] с жёсткими лимитами:

Ключевые параметры:
• pm.max_children = 3–12 — по объёму почты, больше бессмысленно (внешний IMAP быстрее не ответит)
• request_terminate_timeout = 40–70s — убивает зависший на сокете воркер
• request_slowlog_timeout на 10 секунд ниже terminate — успеть записать трейс до kill
• pm.max_requests = 100 — страховка от утечек памяти при парсинге писем
• memory_limit = 512M на Debian — вложения с base64-картинками раздувают воркер до сотен МБ
• отдельный mail-slow.log — основной www-slow.log остаётся чистым для диагностики реальных тормозов CRM

Маршрутизация — ровно один URL /bitrix/tools/check_mail.php. На bitrix-env (nginx + Apache) правило кладём в /etc/httpd/bx/custom/check_mail.conf через SetHandler. На nginx-only — точный location = /bitrix/tools/check_mail.php обязательно выше общего location ~ \.php$, иначе общий перехватит запрос раньше. Расширять правило на /bitrix/tools/ целиком запрещено: там лежат скрипты других модулей, webhook-и CRM попадут в маленький почтовый пул и получат 503.

📊 На CentOS-портале с парой ящиков хватает 3 воркеров под пользователем bitrix и сокетом /run/php-fpm/mail.sock. На нагруженном Debian с десятками активных ящиков — 12 воркеров под www-data и /run/php/mail.sock. Принцип универсальный: любой блокирующий внешний интегратор (выгрузка в маркетплейс, опросы API, экспорт в 1С) выносится в свой пул по той же схеме.

Готовые конфиги pool [mail] для CentOS и Debian, правила Apache и nginx, разбор каждого параметра — в полном разборе от IT For Prof

⚡ iVentoy: 34 рабочих места с миграцией на Windows 11 за 7 часов одним инженером

В одном из проектов IT For Prof мы заменили парк из 34 ноутбуков с переходом на Windows 11 и включением в домен. Раньше такое делали два инженера за два дня. С iVentoy уложились в один рабочий день силами одного человека.

iVentoy — PXE-сервер «всё-в-одном»: один бинарник поднимает DHCP, TFTP и HTTP без отдельной настройки сервисов. ISO кладётся в каталог и сразу появляется в загрузочном меню — без распаковки install.wim, правки BCD и SMB-шары. В одном меню держим Windows 10 22H2, Windows 11 24H2, Server 2022, Astra Linux, РЕД ОС, WinPE, Clonezilla и ESXi — поддержка 110+ типов ОС.

🔧 Что важно знать инженеру:
• Установка машины ~20 минут до экрана логина, параллельно ставятся 8–10 штук
• Версия 1.0.35 от 9 июня 2026, один бинарник под Windows и Linux на x86_64 и arm64 — поднимается даже на Raspberry Pi
• Режим «без DHCP»: боевой DHCP контроллера домена не трогаем, отдаём только TFTP+HTTP через option 66/67. В 80% корпоративных внедрений используем именно этот сценарий
• Legacy BIOS, IA32 UEFI, x86_64 UEFI и ARM64 UEFI обслуживаются одним сервером — без отдельных конфигов под pxelinux.0 и bootx64.efi
• Фильтр по MAC отсекает гостевые ноуты от unattend-сценария, который затрёт диск
• Для Linux iVentoy сам решает проблему отсутствующих драйверов NIC и RAID-контроллеров — пересобирать initramfs не приходится

Один инженер запускает 10 машин одновременно — и пока они ставятся, занимается следующей партией.

📊 Подводный камень из практики: запуск iVentoy со встроенным DHCP в общем VLAN с боевым контроллером домена — часть рабочих станций получит IP с «левого» сервера и потеряет шлюз. Правило: либо изолированный сегмент со своим DHCP, либо режим без DHCP через option 66/67 на основном.

Команды запуска, шаблоны unattend.xml и kickstart для Astra Linux/РЕД ОС, разбор Secure Boot и переключения UEFI/Legacy PXE — в полном разборе с кейсом на 34 машины

🔧 GLPI: Service Desk и CMDB в одной open-source системе на своём сервере

GLPI закрывает заявки с SLA и инвентаризацию ИТ-активов в одном веб-интерфейсе, без лицензионных платежей Teclib' — но в реестре Минцифры его нет, поэтому для госзаказчиков и субъектов КИИ путь закрыт.

Для коммерческого сектора это рабочая замена Naumen Service Desk, ManageEngine ServiceDesk Plus, JIRA Service Management и BMC Helix. Данные остаются в контуре заказчика — закрывается 152-ФЗ без облачной обработки третьей стороной. Финансовый блок (бюджеты, поставщики, лицензии) встроен в ядро, а не продаётся отдельным модулем.

Стек минимальный: Linux + PHP с расширениями mysql, xml, gd, intl, mbstring, curl, ldap, zip + MariaDB или MySQL + Apache либо Nginx с PHP-FPM. Для парка до нескольких сотен активов и десятков техников хватает виртуалки на 2–4 vCPU и 4–8 ГБ памяти. Узкое место — не CPU, а скорость диска под MariaDB и настройки PHP-OPcache.

📊 GLPI Agent ставится через GPO или пакетный менеджер на Windows, Linux и macOS — собирает серийники, модели дисков, установленное ПО и патчи. Для коммутаторов, принтеров и точек доступа работает agentless-режим по SNMP: один агент-сборщик закрывает сегмент сети филиала. Без правил дедупликации (Rules → Inventory) по серийнику, UUID и MAC парк за полгода вырастает в полтора раза — один ноутбук после переустановки ОС превращается в новый актив.

Каталог форм самообслуживания снимает 60–70% «свободных» обращений: вместо абстрактной очереди — кнопки «Заявка на доступ», «Новый сотрудник», «Заявка на технику» с маршрутом согласования.

Типовые грабли при установке от инженеров IT For Prof: забытое расширение PHP роняет проверку окружения; дефолтные memory_limit, upload_max_filesize и post_max_size режут импорт инвентаря и вложения в заявках; SELinux в enforcing не даёт веб-серверу писать в каталоги GLPI.

✅ Пошаговая установка на Debian, подключение LDAP/AD, рабочий набор плагинов (Formcreator, Fields, Behaviours, DataInjection) и сценарии интеграции с Zabbix для автосоздания тикетов из алертов — в полном разборе

🔧 Zammad: open-source тикет-система на своём сервере за час в Docker

Официальные пакеты Zammad доступны только для CentOS, Debian и Ubuntu — Windows и macOS остаются вне поддержки вендора. На Linux-хосте docker-compose стек поднимается примерно за 60 минут: четверть времени уходит на подготовку ВМ, четверть на образы, остальное — TLS и первичная настройка.

Под капотом Ruby on Rails, PostgreSQL для базы, Elasticsearch для полнотекстового поиска и Memcached для кэша. Минимум для пилота: 4 vCPU, 8 GB RAM, 80 GB SSD, Ubuntu 22.04 LTS или Debian 12. Узким местом чаще становится Elasticsearch — индекс перерастает JVM heap и вычитывается с диска, поиск тормозит. Лечится расширением heap и выносом ES на отдельный SSD.

Сравнение стеков с близкими альтернативами:
• osTicket — PHP+MySQL, акцент на email, разворачивается быстрее всех
• GLPI — PHP+MySQL, сильный CMDB и учёт техники
• OTOBO — Perl+PostgreSQL, классический ITIL-движок
• Zammad — Rails+Elasticsearch+PostgreSQL, омниканальность из коробки

Каналы заводим по очереди: email через IMAP/SMTP на отдельный ящик support@, Telegram-бот (первое сообщение клиента должно начинаться с /start, иначе тикет приходит без контекста), веб-форма с reCAPTCHA, LDAP/AD с узким фильтром по OU. Один клиент пустил всю AD без фильтра — после первой синхронизации в helpdesk легли тысячи лишних учёток, интерфейс зависал от автодополнений.

Типовая засада docker-инсталляции: переменная TZ не проброшена в docker-compose.yml. Хост в UTC, Zammad настроен на Europe/Moscow — SLA-таймеры считают со сдвигом в час. Проверяйте часовой пояс до того, как заведёте живые тикеты.

Архитектура отказоустойчивого развёртывания, импорт из osTicket через встроенный мастер и миграция с GLPI через REST API — в полном разборе от IT For Prof

🔧 Rocket.Chat на своём сервере: MongoDB в replica set обязательна даже для одного узла

В продакшене Rocket.Chat откажется стартовать без MongoDB в режиме replica set — платформа использует change streams для распространения событий между подами. Это правило срабатывает даже при одном узле БД.

Развёртывание на своём сервере оставляет переписку, файлы и учётные записи внутри периметра компании. На проектах в банке и производстве платформа закрывает сразу два сценария: внутренний корпоративный чат и обращения клиентов через виджет на сайте.

📊 Расчёт ресурсов по нашему опыту:

• 50 сотрудников — один узел, MongoDB на той же машине, SSD под полугодовую переписку, резервные копии на отдельное хранилище
• 200 сотрудников — MongoDB выносим на отдельный сервер, replica set из 3 узлов, 2 контейнера приложения за Nginx, общий S3-бакет для uploads
• 500+ сотрудников — кластер: 3 узла MongoDB, минимум 3 экземпляра приложения, выделенный TURN-сервер для голоса и видео, Prometheus с node-exporter и mongodb-exporter, алерты на репликацию

Грабли из практики: Rocket.Chat на виртуалке с thin provisioning и снапшотами гипервизора без согласования с MongoDB. За 3 месяца база раздулась, снапшот не удалялся, ВМ остановилась по нехватке места на датасторе. С тех пор для MongoDB — только eager-zeroed диск и отдельный том под журнал.

⚡ Первый запуск выполняем поэтапно: сначала поднимаем MongoDB → инициализируем replica set → проверяем rs.status() (PRIMARY, health: 1) → только потом запускаем приложение. docker compose up -d всем стеком сразу в 3 случаях из 10 приводит к тому, что Rocket.Chat успевает записать первые документы до инициализации replica set — после этого базу приходится чистить.

✅ Docker Compose оправдан для 1–2 узлов приложения. От 500 пользователей переходим на Kubernetes с Helm-чартом вендора. SSO через Active Directory, интеграции с Jira, GitLab, Zabbix через webhooks и Apps-Engine — закрывают типовые требования ИБ и DevOps без обучения админов.

Команды инициализации replica set, требования к серверу под 50/200/500 пользователей и docker-compose.yml от команды IT For Prof — в полном разборе

⚡ Open-source тикет-системы: GLPI vs Zammad vs OTOBO vs Chatwoot vs osTicket

GLPI — единственная из пяти систем, которая закрывает связку «тикеты + активы + финансы» в одной установке: Helpdesk, CMDB, бюджеты поставщиков, лицензии и agentless-инвентаризация работают из одного интерфейса.

Облачные SaaS-хелпдески тарифицируются за каждого агента в месяц. При росте команды поддержки с 5 до 50 инженеров счёт растёт линейно, тогда как self-hosted решения по основной лицензии бесплатны: платите только за сервер и администрирование. На горизонте 3–4 лет разница в стоимости владения расходится тем сильнее, чем больше агентов в поддержке.

🔧 Разбор по стеку и зоне применения:

• GLPI — PHP+MySQL, GPLv3. Внутренний ИТ-отдел 200–2000 рабочих мест: связка хелпдеска с CMDB ощутимо экономит время первой линии на заявках по железу
• Zammad — Ruby on Rails+PostgreSQL+Elasticsearch+Redis, AGPLv3. Смешанная поддержка с почтой, Telegram, чатом и Twitter из коробки
• Chatwoot — Ruby on Rails+PostgreSQL+Redis, MIT. Контакт-центр на WhatsApp, Telegram, Facebook, Instagram для розницы и e-commerce
• OTOBO — Perl+PostgreSQL/MySQL, GPLv3. Миграция с OTRS с сохранением процессной модели
• osTicket — PHP+MySQL, GPLv2. Простой почтовый хелпдеск, разворачивается за полдня

📊 Главная ошибка при оценке — считать только лицензию. Реальные статьи расходов: инфраструктура (Rails+Elasticsearch требуют в разы больше RAM, чем PHP), администрирование (Ruby-стеку нужен отдельный DevOps на четверть ставки), коммерческая поддержка, обучение операторов и кастомизация. У GLPI есть 45-дневный пробный период для первой инсталляции — хватает на оценку под реальной нагрузкой.

Небольшая компания внедряла GLPI ради CMDB «на будущее», а позже активы всё равно велись в Excel — некому было заполнять карточки. Система «на вырост» оправдана, только когда рост реальный, а не гипотетический.

Пять типовых сценариев выбора, расчёт стоимости владения за 3 года и схемы интеграции с Active Directory, Zabbix и мессенджерами — в полном разборе от IT For Prof

⚡ Битрикс24: −9 ГБ памяти и TTFB 5,2 → 0,8 с за один день без апгрейда сервера

Клиент: оптовая торговая компания, 120 сотрудников, коробочный портал. Проблема: по утрам карточки сделок открывались 5–15 секунд, в пиковые часы портал отдавал 502 Bad Gateway, отдел продаж терял по 10–20 минут. Внутренний админ добавил серверу RAM — через две недели всё вернулось.

📊 Экспресс-аудит за 60–90 минут по логам nginx, PHP-FPM и медленному логу MariaDB показал четыре независимые причины, и ни одна не про мощность железа:

• Пул PHP-FPM в динамике держал десятки простаивающих воркеров, которые впустую занимали гигабайты
• Модуль «Почта» синхронизировался по блокирующему IMAP прямо в общем www-пуле — в часы синхронизации воркеров не оставалось живым пользователям
• Файлы из S3 Reg.ru шли через PHP, на каждое вложение — отдельный воркер и TLS-рукопожатие
• MariaDB работала на дефолтных значениях, буферный пул InnoDB не вмещал рабочие данные

🔧 Что сделали: перевели www-пул на статический режим с расчётом воркеров под реальную память, вынесли IMAP-синхронизацию в отдельный пул с жёстким таймаутом, добавили в nginx прямое проксирование S3 и Brotli, затюнили InnoDB buffer pool и таймауты в отдельном конфиге, который переживает обновления окружения.

Потребление RAM веб-стеком: 9,3 ГБ → 1 ГБ. TTFB на тяжёлых страницах CRM: 5,2 → 0,8 с. Утренние 502 прекратились. Медленный лог PHP-FPM: ~21 МБ мусора в неделю → десятки килобайт.

✅ Освободившиеся 8 ГБ ушли под буферный пул базы, апгрейд сервера не понадобился. Все работы — один рабочий день.

Формулы расчёта воркеров PHP-FPM, параметры изолированного пула для IMAP и регламент еженедельной профилактики от IT For Prof — в полном разборе кейса.

🔧 Chatwoot: омниканальная поддержка на своём сервере вместо Intercom и Zendesk

Открытая платформа поддержки клиентов с 25 000+ звёзд на GitHub. Объединяет WhatsApp, Telegram, Instagram, email и веб-виджет в одну ленту разговоров — без передачи переписки в чужое облако.

Ключевое отличие от классических тикет-систем: базовая единица здесь — разговор с контактом. Каналы склеиваются по email, телефону или внешнему ID. Для веб-виджета это закрывает identity validation: залогиненный пользователь приходит в Chatwoot с HMAC-подписью, и его чат, почта и WhatsApp с тем же номером автоматически попадают в одну карточку. Где общего ключа нет (Instagram отдаёт только внутренний ID профиля), карточки объединяются вручную через merge.

📊 Архитектура и железо для команды 5–10 операторов:
• Rails-приложение + Sidekiq-воркеры + PostgreSQL + Redis + reverse-proxy (Caddy или Nginx)
• минимум 2 vCPU и 4 ГБ RAM на проде
• SSD под PostgreSQL — поиск по разговорам упирается в IOPS
• от 20 операторов и активного WhatsApp/Telegram-трафика PostgreSQL выносится на отдельный сервер с репликой и регулярным pg_dump

Развёртывание из официального docker-compose занимает около получаса, если DNS и TLS-сертификат готовы заранее. В .env правятся FRONTEND_URL (полный HTTPS-адрес, иначе в письмах битые ссылки), параметры PostgreSQL и Redis, SMTP и S3-совместимое хранилище для вложений. Reverse-proxy должен отдельно проксировать websocket ActionCable, иначе интерфейс грузится, но новые сообщения появляются только после F5.

⚡ Встроенный AI-агент Captain работает в двух режимах: автономно отвечает на типовые вопросы из help center и FAQ или подсказывает оператору варианты ответа и переводит реплики на язык клиента. Для контура без выхода данных наружу подключается локальная модель по OpenAI-совместимому API. Контрольный тест перед продом — 30–50 реальных вопросов с известными ответами; запуск на клиентов оправдан, когда «не знаю» уверенно преобладает над «уверенно ошибся».

Chatwoot не подходит для внутренней ITSM-поддержки, контрактов с SLA уровня «P1 — реакция 15 минут» и contact-центра с предиктивным набором. Это платформа живых разговоров, а не учёта инцидентов.

Подключение WhatsApp Business API через 360dialog и Cloud API, связка с Bitrix24 через вебхуки, мониторинг очередей Sidekiq в Zabbix и чек-лист от инженеров IT For Prof — в полном разборе

Frisbee: российский мессенджер держит 300 000 пользователей на одну инсталляцию и обрабатывает 100 000 сообщений в секунду

Компании, которые до 2022 года вели переписку в Telegram и Slack, всё чаще получают запрос от юридического отдела: нужен мессенджер из реестра российского ПО — этого требует 152-ФЗ и приказ по импортозамещению. Frisbee — собственная платформа разработчика KLAUD ATLAS с записью в реестре под номером 7378, публичным сайтом frisbee.chat и клиентами в RuStore и App Store.

По данным Frisbee, продукт получил TAdviser IT Prize 2026 и обслуживает около 1 млн корпоративных пользователей. Одна инсталляция рассчитана более чем на 300 000 пользователей, серверная часть держит 100 000 сообщений в секунду, а видеоконференции — более 1000 участников одновременно, с гостевым доступом по ссылке без регистрации.

✅ Что входит в платформу помимо чата:
• AI-ассистент ведёт протоколы видеовстреч и присылает отчёты прямо в общий чат
• FrisbeeTube — собственный видеохостинг для записей обучений и регламентов
• FrisbeeFlow — таск-менеджер без выгрузки задач в стороннюю систему
• SIP-телефония — звонок сотруднику или добавление в конференцию по номеру телефона

Поставка — по двум моделям: облачный SaaS или on-premise на сервере заказчика. On-premise закрывает требование «данные внутри периметра»: шифрование при хранении и передаче, удалённый выход из аккаунта и очистка данных с устройства при потере или увольнении. Публичного прайс-листа у Frisbee нет — и SaaS-пакеты, и on-premise считают индивидуально, под число пользователей, набор модулей и SIP.

🔧 В IT For Prof мы разбираем такие внедрения на практике: когда Frisbee выгоднее собственного сервера на Matrix, какие три вопроса задать вендору на пресейле и по какому критерию оценивать переход с Telegram, Slack или Teams без потери истории переписки.

Критерии выбора между Frisbee и open-source, чек-лист миграции с Telegram без потери истории переписки и три вопроса вендору на пресейле — как выбрать и внедрить без ошибок

🔒 WireGuard на уровне протокола не знает ни логинов, ни паролей — только пары публичных ключей. При штате 80+ человек это превращает увольнение в квест «найти, какой ключ чей», а туннель уволенного отвечает ещё долго после того, как ему закрыли почту.

Разрыв закрывает wg-portal с LDAP-провайдером: доменная учётка становится единственным источником истины, а VPN синхронизируется следом по расписанию. Заводить и блокировать людей вы продолжаете в оснастке AD, портал перечитывает конфиг WireGuard сам.

Механика отзыва спрятана в LDAP-фильтре (!userAccountControl:1.2.840.113556.1.4.803:=2) — это битовая проверка флага ADS_UF_ACCOUNTDISABLE. Отключили учётку в AD → пользователь перестаёт проходить фильтр → на следующем цикле sync_interval (по умолчанию 15 минут, на чувствительных контурах снижаем до 5) пир уходит в disabled. Для мгновенного отзыва — ручная деактивация в интерфейсе портала, разрывает активные сессии сразу.

Сегментация сети — через interface_filter: группа VPNUsers пускается в wg0 (офисная подсеть), Contractors — в изолированный wg1 (только таск-трекер и один RDP). Пользователь в обеих группах получает два пира, портал их не «схлопывает».

Windows Server 2025 включает LDAP signing по умолчанию — простой bind на 389 без шифрования контроллер отклонит. Нужен STARTTLS на 389 или LDAPS на 636, сертификат CA должен лежать в доверенном store сервера с wg-portal.

⚡ Второй фактор на LDAP не навешивается — только через OIDC-прокладку (Keycloak или Authentik), которая федерирует ту же AD и требует TOTP/WebAuthn поверх пароля. В IT For Prof включаем 2FA точечно на группе wg-critical для доступа к финансовым системам, обычные сотрудники ходят в офисный сегмент по доменному паролю.

Разбор field_map, типовые ошибки bind и чтение логов при no entries returned — в полном разборе

🔧 Cisco приостановила бизнес в РФ ещё в 2022 году: продлить лицензии AnyConnect легально нельзя, обновлений безопасности для ASA/FTD нет, замены железа по гарантии тоже. AnyConnect работает по инерции — пока не кончилась лицензия и не сломался шлюз.

WireGuard закрывает разрыв как открытый протокол без лицензий на пользователя: число пиров ограничено только ресурсами сервера. Для СМБ без ГОСТ-обязательств это прямая замена — доступ к 1С, RDP и файловым по привычному сценарию «запустил клиент — попал в корпоративную сеть».

Ключевой принцип миграции — параллельная работа двух VPN, а не «выключили в пятницу, включили в понедельник». WireGuard поднимается на отдельном сервере, слушает свой UDP (обычно 51820) и не мешает ASA. Пилот — ИТ-отдел на неделю, потом волны по группам доступа: сначала простые политики (одна подсеть), в конце — финансы и дежурная смена. ASA держат ещё две недели в горячем резерве после последнего подключения — за это время всплывают подрядчики раз в квартал и скрипты, ходящие через VPN как транспорт.

Политики переносятся не буквально. Split-tunnel ACL из group-policy превращается в AllowedIPs на пирах, а L4-фильтрация — в nftables на сервере. Десятки индивидуальных политик ASA сводятся к 3–5 интерфейсам wg-portal с маппингом на группы Active Directory: wg-office, wg-finance, wg-devops, wg-contractors.

Постуре-контроль (проверка антивируса, домена, версии ОС) чистый WireGuard не воспроизводит — это архитектурное отличие, а не пробел настройки. Компенсация: OIDC перед wg-portal или MDM.

📊 Честная граница: банкам, госорганам, операторам КИИ и медицине с ЕГИСЗ WireGuard юридически не подходит — там нужен сертифицированный ГОСТ-шлюз (С-Терра, ViPNet, «Континент»). Никакой аудит открытого кода сертификат ФСБ/ФСТЭК не заменит.

Порядок волн, шаблоны peer-конфигов и разбор трёх граблей маршрутизации DNS/split-tunnel — в полном разборе от IT For Prof.

🔒 Отзыв VPN у уволенного: одна блокировка в AD вместо отдельного пункта в чек-листе

WireGuard проверяет только пару ключей — слова «пользователь» и «уволен» для протокола ничего не значат. Пока публичный ключ бывшего сотрудника лежит в конфиге сервера, туннель поднимается, а файловый сервер и 1С отвечают ему так же, как вчера.

Ручная модель — гонка со временем. Аккаунт в AD закрыли за минуту, а VPN живёт своей жизнью: вспомнить, какой из десятков пиров чей, удалить строку, перезапустить сервис. На одном контуре пир уволенного разработчика висел в конфиге несколько дней — задачу поставили не тому админу, а VPN оставался вне общего чек-листа offboarding.

Связка wg-portal + LDAP-синхронизация убирает ручной шаг. В фильтрах login_filter и sync_filter прописано условие (!userAccountControl:1.2.840.113556.1.4.803:=2) — бит ADS_UF_ACCOUNTDISABLE атрибута userAccountControl. Кадровик жмёт Disable Account в оснастке домена, на следующем цикле портал переводит пир в disabled и снимает его с интерфейса. По умолчанию sync_interval = 15 минут, на контурах с чувствительными данными снижаем до 5.

✅ Ключевые детали механики:
• Флаг disable_missing: true закрывает сценарий с полным удалением учётки или переносом в архивный OU за пределы base_dn — пир снимается и без Disable Account
• Конфликтное увольнение — ручной kick через веб-интерфейс портала, активная сессия обрывается сразу, цикла ждать не нужно
• Ротация preshared key — только для админов инфраструктуры и доступа в PCI-сегмент: обесценивает старый клиентский конфиг целиком, даже если копия осела на личном ноутбуке
• Доказательство отзыва для проверки: поле latest handshake в выводе wg show wg0 dump + журнал портала с log_user_info: true

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

Так VPN, почта, RDP и корпоративный мессенджер отзываются каскадом за одну операцию в AD. В IT For Prof схема отработана на контурах от 80+ сотрудников: блокировка учётки → снятие пира в течение цикла → запись в журнале для аудита.

Конфиг LDAP-фильтров, схема разнесения групп AD по WireGuard-интерфейсам и разбор доказательной базы через latest handshake — в полном разборе

🔧 Self-hosted мессенджер в реестре отечественного ПО — только один из четырёх зрелых

Из рабочего шорт-листа для развёртывания на своём сервере — Rocket.Chat, Element/Matrix, Nextcloud Talk и Frisbee — в реестре Минцифры значится только Frisbee. Остальные три технически сильнее, но для госзаказчика и получателей бюджета мимо: обоснование отсутствия аналогов по мессенджерам не проходит.

Реестр — это не аудит безопасности, а юридический фильтр: льготы по НДС вендору и преимущество в закупках по 44-ФЗ и 223-ФЗ. У IT For Prof был кейс, где «шифрование переписки» в реестровом продукте на деле означало TLS до сервера и открытый текст в базе. Технический аудит проводим отдельно.

Выбор между остальными тремя сводится к архитектуре, а не к «удобству интерфейса»:

• Rocket.Chat — моно-сервер, один периметр, официальный Helm chart для Kubernetes и штатный air-gapped-режим. Ставим малым командам на Docker Compose и когда важен полный контроль данных внутри контура.
• Element на Synapse — федеративный протокол Matrix: домены обмениваются сообщениями как SMTP-серверы. E2EE в приватных комнатах по умолчанию, звонки через Element Call на LiveKit. Берём, когда переписка идёт с десятком внешних подрядчиков без заведения им учёток.
• Nextcloud Talk — модуль поверх Nextcloud. Оправдан только там, где файловое хранилище Nextcloud уже развёрнуто: одна база LDAP/AD, один бэкап. Для промышленных звонков обязателен High-Performance Backend.

Наличие в реестре и «безопасно» — не синонимы. Реестр не проверяет ни архитектуру, ни E2EE, ни устойчивость к утечкам.

Отдельно про MeetVap, о котором уже спрашивают: 28 звёзд, 16 коммитов, ни одного релиза, вендор — частный разработчик из Турции. Следить — да, внедрять — нет. И не повторяйте нашу ошибку: миграция Rocket.Chat с управляемого облака вендора в свой контур на другой версии ушла в неделю простоя с ручным восстановлением из бэкапа MongoDB. Либо сразу on-premise, либо сразу облако с SLA.

Матрица выбора под размер команды, требования к E2EE и федерации + разбор архитектурной разницы Matrix vs моно-сервер — в полном разборе