Облако или свой сервер: матрица решения без архитектурной религии

Выбор размещения часто превращают в спор между «всё контролировать самим» и «ничего не обслуживать». Обе крайности вредны. Облако не отменяет ответственность за данные и настройки, а self-hosted не делает эксплуатацию бесплатной и безошибочной. Полезнее сравнить варианты по одинаковым критериям и отдельно записать, кто отвечает за каждый риск.

AiHummer доступен как управляемое облако и как установка на собственный Linux-сервер. Это два способа получить продукт, а не две разные философии. Различается прежде всего операционная граница: кто держит инфраструктуру, применяет обновления, наблюдает ресурсы и восстанавливает сервис.

Критерий 1. Скорость старта

Управляемое облако обычно сокращает путь до первого входа: не нужно заранее готовить Linux-хост и выполнять серверную установку. Это важно для пилота, когда команда хочет сначала проверить процесс, качество ответов и интеграции.

Self-hosted требует сервера, проверки требований, персональной команды установки и первого входа. Установка может быть быстрой, но подготовка сети, DNS, TLS, резервных копий и мониторинга остаётся. Не сравнивайте «создали инстанс» с «готово к промышленной эксплуатации»: критерии завершения должны быть одинаковыми.

Критерий 2. Контур и потоки данных

Свой сервер даёт контроль над местом хранения содержимого инстанса. Но он не означает, что данные никогда не покидают хост. Внешняя модель получает тот объём запроса, который нужен выбранному маршруту; интеграция получает поля операции; лицензионные и технические сервисы могут получать необходимые технические сведения. Состав зависит от конфигурации.

В облаке нужно проверить регион размещения, изоляцию, договорные условия, бэкапы и список субпроцессоров. Для обоих вариантов нарисуйте одну и ту же карту: источник данных, получатель, назначение, состав, срок хранения, шифрование и механизм отключения. Соответствие 152‑ФЗ требует отдельной организационной и юридической оценки.

Критерий 3. Эксплуатационная ответственность

Для облака уточните, какие обновления, резервные копии, наблюдаемость и реакции на инцидент входят в услугу. Слово «managed» не объясняет RPO, RTO и границы поддержки. Проверяйте тариф и SLA там, где он реально предусмотрен.

Для self-hosted назначьте владельцев Linux, PostgreSQL, TLS, DNS, бэкапов, восстановления, capacity planning и обновлений. Host-native установка без Docker делает процессы и каталоги прозрачными, но не отменяет дежурство. Если эти обязанности «принадлежат всем», на практике они не принадлежат никому.

Критерий 4. Интеграции и сеть

Self-hosted удобен, когда агенту нужен контролируемый доступ к внутренним системам. Но этот доступ следует выдавать минимально: отдельные учётные данные, scoped-права, egress-правила и аудит. Не открывайте внутреннюю сеть целиком ради одной интеграции.

В облачном варианте проверьте, как строится безопасное соединение с внутренними системами, какие адреса разрешены и кто управляет секретами. Некоторые интеграции или каналы могут зависеть от тарифа, внешнего провайдера и дополнительной настройки. Универсальной доступности всех каналов обещать нельзя.

Критерий 5. Стоимость

Облако объединяет часть инфраструктуры и эксплуатации в подписку, но лимиты тарифа, дополнительные места, каналы и внешние модели могут считаться отдельно. Self-hosted-лицензия может не зависеть от количества сообщений напрямую, однако сервер, модельный API, локальное железо, хранение, бэкапы и работа инженеров остаются.

Считайте три сценария: текущая нагрузка, рост вдвое и пиковый день. Добавьте стоимость восстановления после сбоя и время команды на обновления. Честный TCO почти никогда не равен одной строке прайса.

Критерий 6. Требования к доступности

Если процесс критичен, запишите допустимый простой и потерю данных. Затем проверьте, какой вариант позволяет это доказать: где находятся бэкапы, когда последний раз выполнялось восстановление, как переключается DNS, кто получает алерт и сколько времени занимает реакция. Наличие облака или собственного сервера само по себе не даёт гарантию.

Для пилота можно выбрать менее сложную схему, но критерий перехода в прод должен быть известен заранее. Иначе эксперимент незаметно становится критичным сервисом без соответствующей эксплуатации.

Матрица для рабочей встречи

Оцените каждый вариант по шкале от одного до пяти:

• время до первого проверяемого сценария;
• контроль размещения данных;
• допустимость внешних вызовов;
• доступ к внутренним системам;
• компетенции Linux/PostgreSQL;
• зрелость бэкапов и восстановления;
• требования к RPO/RTO;
• стоимость при базовой и пиковой нагрузке;
• тарифные ограничения;
• скорость изменений и обновлений;
• договорные требования;
• план выхода или миграции.

Рядом с оценкой запишите доказательство и владельца. «Кажется проще» — не доказательство. «Команда уже обслуживает PostgreSQL и ежеквартально проверяет восстановление» — доказательство. «Поставщик заявляет бэкапы» — только вопрос, пока не изучены условия и отчёт.

Типичные ошибки

Первая ошибка — выбирать self-hosted только из желания «не отдавать данные», не проверив внешние модели. Вторая — выбирать облако только ради скорости и забывать о соединении с внутренними системами. Третья — считать лицензирование полной стоимостью. Четвёртая — предполагать, что поздняя миграция будет бесплатной и мгновенной. Пятая — использовать один критерий для пилота и другой для production, не заметив переход.

Хорошее решение допускает пересмотр. Храните матрицу вместе с допущениями и возвращайтесь к ней после изменения нагрузки, тарифа, требований безопасности или состава команды.

Зафиксируйте решение как гипотезу

Матрица полезна только вместе с допущениями. Запишите ожидаемую нагрузку, состав команды, обязательные интеграции, чувствительные категории данных и горизонт расчёта. Рядом укажите, какие факты подтверждены тестом, какие взяты из текущих условий поставщика, а какие остаются гипотезой. Это защищает решение от ложной точности.

Назначьте дату пересмотра. Переоценка нужна после изменения тарифа, нагрузки, состава провайдеров, требований к размещению или появления новой внутренней системы. Если пилот выбран в облаке ради скорости, заранее определите условие, при котором рассматривается self-hosted. Если стартовали на своём сервере, задайте критерий, при котором операционная нагрузка заставит сравнить managed-вариант. Архитектурное решение становится управляемым, когда команда знает не только почему выбрала путь сегодня, но и при каких фактах изменит его завтра.

Источники и ограничения

Официальные материалы: введение и сравнение режимов, системные требования, тарифы и сетевые контроли. Доступность возможностей и цены меняются; перед решением перепроверьте текущие условия. Эта матрица не заменяет юридическую оценку, моделирование нагрузки и проверку восстановления.

Если выбор всё ещё неочевиден, проведите одинаковый небольшой пилот и сравните не презентации, а журнал операций, затраты и подтверждённые риски.