Клиентские окружения + агенты
Как правильно посадить каждого клиента в собственную изолированную песочницу, где живут его агенты: Yelp-ассистент (леды + follow-up), GBP-монитор отзывов и SEO/блог-агент для его сайта. Один клиент — одна среда, никто друг друга не видит и не мешает.
01 Изоляция: один клиент = одна песочница
- Контейнер на клиента. Каждому — свой Docker-контейнер (позже на облачном флоте). Внутри: браузер-профиль с сессией Yelp, конфиг агента, зашифрованный сейф доступов, воркер.
- Полная изоляция. Свой network namespace и том. Клиенты не видят друг друга; блок одного не роняет остальных.
- Свой IP на клиента (критично). У каждого контейнера отдельный исходящий IP/прокси. Иначе Yelp видит десятки клиентов с одного IP и банит — самый частый провал.
- Оркестратор. Наш backend поднимает/гасит контейнеры, раздаёт задачи по расписанию, знает какой клиент в каком контейнере.
- Источник правды. Центральный multi-tenant Postgres+pgvector: клиенты, доступы (шифр), расписания, логи ледов/отзывов, очередь подтверждений.
- Доставка. Подтверждения владельца — в его личном Telegram-боте (наша готовая модель «команда-в-Telegram»).
02 Схема системы
Наверху — общий control plane. Внизу — изолированные песочницы клиентов. Внутри одной раскрыты её агенты.
03 Как даём доступ к каналам клиента
| Канал | Как получаем доступ | Риск/нюанс |
|---|---|---|
| Yelp (леды+отзывы) | Разовый логин владельца в Yelp for Business внутри контейнера → сессия хранится в сейфе | против ToS нужен свой IP, темп, подтверждение |
| Google (GBP) | OAuth business.manage — владелец даёт права нашему приложению | чисто одобрение API ~2 нед., домен почты = домен сайта |
| Сайт · WordPress | REST API + application password (спец-пользователь) | ок самый частый кейс SMB |
| Сайт · статик/кастом | git-доступ или deploy-hook, агент коммитит контент | зависит как у USC на Cloudflare |
| Сайт · конструкторы | Wix/Squarespace/GoDaddy — слабые API | частично иногда только вручную — честно клиенту |
| Аналитика визитов | Ставим сниппет: self-hosted Umami/Plausible или GA4 | ок видим трафик мы и владелец |
04 Риски и как держим
Yelp: автоматизация ледов и отзывов против правил
Публичного API у Yelp нет ни для ответов на отзывы, ни для сообщений с лидами — только браузер залогиненного дашборда, а это запрет ботов по ToS. Follow-up ×4 к не ответившим — вдвойне рискованно (похоже на спам, ловит фильтры). Держим: отдельный IP на клиента, человеческий темп, обязательное подтверждение владельцем, скромный график follow-up, стоп при ответе. В лоб авто-рассылку не делаем. Риск проговариваем клиенту.
Общий IP = массовый бан
Если все контейнеры ходят с одного адреса, Yelp/Google быстро свяжут аккаунты. Держим: отдельный исходящий IP/прокси на контейнер — обязательное условие, не опция.
Секреты клиентов
Мы держим доступы к чужим Yelp/Google/сайтам — это ответственность. Держим: шифрованный сейф на клиента, секреты не в логи, least-privilege (узкий OAuth-scope, app-password вместо мастер-пароля), изоляция контейнеров.
05 Внедрение по фазам
GBP-агент отзывов (чистый API) + SEO/блог на WordPress
Стартуем с безопасного: Google-отзывы через API на USC как флагман, и SEO-агент если у клиента WordPress. Никакого риска ToS.
Yelp-отзывы через браузер — пилот 1 клиент
Разовый логин, черновик ответа, подтверждение владельцем. Отдельный IP, человеческий темп. Замеряем риск.
Yelp-леды + follow-up ×4 — осторожный пилот
Только после того как отзывы прошли гладко. Консервативный график, стоп при ответе, персонализация.
Контейнеризация на клиента + оркестратор
Docker-песочница на клиента, свой IP, сейф, control plane. Онбординг-пайплайн. Берём 3 платящих.
Переезд на облачный флот
С Mac Mini на дешёвый флот (Hetzner/Fly.io) по мере роста числа клиентов и IP.