Статьи про самостоятельный хостинг обычно заканчиваются на том, что всё получилось: сервис поднят, домен привязан, сертификат выдан. Дальше идёт вывод про свободу и контроль над данными.
Дальше идёт третий месяц, и вот про него не пишут.
Эта статья — список того, что происходит после. Не гипотетического, а того, что случилось на этом проекте, с оценкой вероятности по каждому пункту. Оценка субъективная и означает «насколько вероятно, что вы столкнётесь с этим в первый год», а не статистику.
#Короткий ответ
Главный риск самостоятельного хостинга — не взлом. Взлом маловероятен и, если случится, будет очевиден. Главный риск в том, что вы становитесь единственным дежурным, а у дежурного бывают отпуск, командировка, грипп и сон. И большинство отказов при этом тихие: сервис отвечает, а делает не то.
#Девять рисков
#1. Тихий отказ вместо громкого · вероятность высокая
Громкий отказ — всё лежит, вы это видите. Дорогой отказ — система рапортует успех и делает не то.
Наш случай: обновление выложено, скрипт деплоя доложил об успехе, порт занят, сайт открывается — и отдаёт код прошлой недели. Причина: рабочий процесс запускался с повышенными правами в служебной сессии, а деплой шёл из обычного терминала. Команда завершения процесса печатала SUCCESS, возвращала нулевой код и не делала ничего. Скрипт добросовестно верил коду возврата.
Отдельно неприятно то, что этот отказ родился как побочный эффект правильного исправления — того, что описано в риске 2.
Лечение: деплой не имеет права отчитаться об успехе без подтверждения версии по HTTP.
#2. Значения по умолчанию, которые ломают всё · вероятность высокая
Сайт работал, пока владелец сервера был подключён по RDP. Отключился — через несколько минут лёг. Диагноз «падает приложение» был неверным: приложение не падало, задачу планировщика останавливала операционная система, потому что она была создана с типом входа «только для вошедшего пользователя» — значением по умолчанию.
Хуже другое: баг возвращался после каждой переустановки. Установщик, запущенный без повышения прав, менял настройки, на которые прав хватало, и молча пропускал три параметра, на которые не хватило. Отчитывался при этом нулевым кодом возврата.
Лечение: проверять фактическое состояние системы, а не отчёт установщика.
#3. Каналы, которые «настроены» и не работают · вероятность высокая
Почта была настроена: хост указан, галочка стоит, приложение считало отправку доступной. В реальности исходящий порт 587 на этой машине закрыт на сетевом уровне, и отправка падала примерно через шестнадцать секунд — по таймауту соединения, без внятной ошибки.
Два следствия. Любая операция, ждавшая письма, висела шестнадцать секунд, и отправку пришлось уносить в фон с собственным потолком ожидания. И вторая, более общая: проверка «можем ли мы отправить» и сама отправка должны выполняться одним и тем же кодом, иначе эти два ответа неизбежно разойдутся.
Тот же риск с любым исходящим соединением: порт закрыт, домен заблокирован, провайдер туннеля требует порта, которого у вас нет.
#4. Вы единственный дежурный · вероятность высокая
Это не событие, а состояние. Сервис ложится ночью, в отпуске, на встрече. Автоматический перезапуск закрывает часть случаев и создаёт новый: сервис, перезапускающийся трижды в сутки, выглядит работающим.
Минимальный набор проверок, который делает это состояние переносимым, — в статье про мониторинг личного сервиса. Без проверок вы узнаёте о сбоях от пользователей.
#5. Резервные копии, которые не проверяли · вероятность высокая
Копии делаются, скрипт в расписании, всё зелёное. Проверка восстановления не делалась ни разу. День, когда она понадобится, и будет днём, когда выяснится, что копия снималась обычным копированием файла базы на ходу и содержит несогласованные данные.
И вторая половина риска: копия — это ещё и хранилище секретов. В Persona ключи участников лежат в базе открытым текстом, а полный экспорт содержит ту же таблицу без изъятий. Такой файл нельзя класть в общее облако и прикладывать к обращениям в поддержку — подробности в статье про резервные копии и приватность.
#6. Секрет, попавший в коммит или в лог · вероятность средняя
Ключ, попавший в историю репозитория, остаётся в ней после удаления. У нас проверка всей истории оказалась чистой, зато рабочий пароль от тестового стенда и описание сетевой топологии нашлись в обычном документе передачи дел — там, где никто не ищет секреты.
Отдельный подвид: секрет, уехавший в журнал. Логи попадают в архивы диагностики и в обращения в поддержку. Порядок действий при утечке — в статье про что делать, если ключ утёк; и главное правило оттуда: удаление не отменяет утечку, отменяет её только отзыв.
#7. Работа, сделанная и оказавшаяся ненужной · вероятность средняя
Риск, который не выглядит риском. У нас была написана и протестирована интеграция приёма платежей — подписи, ссылки, разбор ответов платёжной системы. После этого её сознательно не подключили: проверка показала, что продавать нечего, потому что ни одна функция не закрыта платным гейтом. Продукт бесплатен целиком, тариф существует только в коде.
Подключать приём денег к продукту, у которого нет платного контура, значит брать деньги ни за что. Живая часть была снята, знание сохранено в документе.
Вывод общий: при самостоятельном хостинге вы сами себе и заказчик, и разработчик, и никто со стороны не спросит «а зачем». Спрашивать придётся самому, и иногда ответ будет «незачем» уже после того, как работа сделана.
#8. Защита, которую нельзя довести до конца · вероятность средняя
Мы внедрили политику безопасности контента и не смогли убрать из неё послабления, которые её ослабляют: слишком много исполняемого кода живёт прямо в шаблонах, а метка на скриптах не покрывает обработчики в атрибутах и вдобавок отключает то самое разрешение, на котором всё держится.
Решение — держать вторую политику, строгую, в режиме наблюдения. Она ничего не блокирует и показывает, сколько нарушений осталось: цель перестаёт быть намерением и становится измеримой величиной.
Общий вывод для самохостинга: часть защитных мер вы объективно не сможете включить полностью, и честнее знать об этом и мерить разрыв, чем считать, что защита стоит.
#9. Данные лежат у вас, значит и отвечаете за них вы · вероятность высокая
При самостоятельном хостинге вы становитесь оператором чужих данных, если сервисом пользуется кто-то ещё. Это влечёт всё сразу: удаление по запросу, экспорт, реакция на утечку. И граница между пользователями у большинства самодельных многопользовательских решений — не усиленная изоляция, а список разрешённых путей на кодовой базе, начинавшейся однопользовательской. В Persona это устроено именно так, и об этом стоит знать до, а не после того, как вы позвали на свой инстанс коллег.
Плюс отдельный класс угроз, специфичный для локального ИИ: чужие инструкции, приезжающие вместе с данными, доступ модели к файлам, инструменты с правами на действия. Разбор — в статье про угрозы локального ИИ.
#Что из этого следует на практике
Сводка по стоимости и вероятности:
| Риск | Вероятность | Обнаруживается | Стоимость |
|---|---|---|---|
| Тихий отказ деплоя | высокая | случайно | средняя |
| Автозапуск не переживает логаут | высокая | при перезагрузке | высокая |
| Канал оповещения не работает | высокая | когда нужен | высокая |
| Вы единственный дежурный | постоянно | всегда | высокая |
| Копия не восстанавливается | высокая | в худший день | наивысшая |
| Утечка секрета | средняя | иногда никогда | высокая |
| Ненужная работа | средняя | постфактум | средняя |
| Неполная защита | средняя | при аудите | средняя |
| Ответственность за чужие данные | высокая | при инциденте | высокая |
Строка про копию стоит первой по стоимости и почти первой по вероятности — это самое выгодное место для вложения часа времени.
#Где интуиция подводит
«Главное — не взломают». Взлом маловероятен и заметен. Гораздо вероятнее, что вы потеряете данные из-за непроверенной копии или неудачной миграции.
«Я поставлю мониторинг потом». «Потом» наступает после первого тихого отказа, и цена этого отказа обычно больше, чем час на настройку проверок.
«Свой сервер — значит приватно». Свой сервер даёт контроль над хранением. Запросы уходят туда, куда вы их отправляете: подключили облачного провайдера — текст запросов уходит ему напрямую. Данные остаются у вас, если приложение развёрнуто у вас и работает с локальной моделью.
«Прочитаю код и проверю сам». Для Persona этот аргумент недоступен: репозиторий закрыт, публичной лицензии нет. Мы называем это прямо, потому что иначе фраза «разверните у себя и проверьте» была бы обещанием, которое мы не можем выполнить.
«В контейнере всё то же самое». Нет: в контейнере не работает захват экрана — там нет графической сессии. Контейнерный режим это веб и приём данных извне.
#Кому самохостинг начинать не стоит
Честно и по пунктам.
- Если вас раздражает командная строка. Не «непривычна», а именно раздражает. Всё описанное выше диагностируется в терминале.
- Если нет второго носителя под копии. Тогда вы не занимаетесь самохостингом, вы играете в него до первой смерти диска.
- Если сервис нужен кому-то ещё и недоступность недопустима. Один дежурный без сменщика не обеспечивает непрерывность, сколько бы ни было автоматики.
- Если вы рассчитываете «настроить и забыть». Забыть можно, но тогда через полгода вы обнаружите просроченный сертификат, остановившиеся фоновые задачи и последнюю копию трёхмесячной давности.
- Если единственный мотив — экономия. Считайте своё время: два часа в месяц на горизонте трёх лет — почти две рабочие недели. Честный счёт домашнего варианта — в статье про домашний сервер под ИИ.
Кому стоит: тем, для кого важнее контроль над данными и возможность не зависеть от изменения чужих условий, и кто готов принять роль дежурного как часть сделки. Это нормальная сделка — просто она должна быть осознанной.
#Частые вопросы
#Сколько времени в месяц реально уходит?
В спокойный месяц — близко к нулю. В месяц, когда что-то сломалось молча, — день. Отношение этих двух чисел определяется тем, насколько рано вы поставили проверки: каждая автоматическая проверка переводит часть того дня в минуты.
#Что настроить в первую очередь?
Три вещи, в этом порядке: резервную копию с проверкой восстановления, автозапуск, переживающий перезагрузку без входа в систему, и деплой, который не может отчитаться об успехе, не подтвердив версию. Всё остальное потом.
#Безопаснее ли самохостинг, чем облачный сервис?
По-другому. Вы убираете риск чужой политики и чужой утечки и берёте на себя риск собственной ошибки. У облачного провайдера есть штат безопасности, у вас его нет; у вас есть контроль над данными, у него его нет для вас.
#Что делать, если я уже поднял сервис и всё описанное про меня?
По порядку из вопроса выше. Начните с копии и её проверки — это дешевле всего и закрывает самый дорогой риск. Общий маршрут со всеми шестью этапами — в статье о том, как поднять свой ИИ-сервис.
#Правда ли, что бесплатно навсегда?
Сегодня Persona бесплатна целиком и работает с вашей моделью или вашим ключом провайдера. Тариф Pro существует в коде, но не продаётся: карточка на странице тарифов закомментирована, оплата не реализована, ни одна функция не закрыта гейтом. Обещать, что так будет всегда, мы не можем — но данные при самостоятельном развёртывании лежат у вас, и изменение условий продукта не отбирает у вас архив.