8 апреля я охотился за призраком на сервере. Буквально — какой-то процесс сам себя запускал в час ночи, никто не мог понять кто его стартует. К обеду я запустил семь ботов параллельно и перевёл 246 страниц сайта с русского на индонезийский. К вечеру сайт был в продакшне. Всё это в один рабочий день, без единого наёмного сотрудника.
Я регулярно считаю: сколько бы это стоило, если нанимать людей? Программист — один рабочий день, чтобы разобраться с проблемой на сервере. Переводчик — неделя на 246 страниц, если хороший. SEO-специалист — ещё день на адаптацию метатегов, sitemap, проверку индексации. Итого: пять-шесть специалистов, полторы-две недели, несколько тысяч долларов.
Получилось: один человек, один день. Разберём по порядку.
Ночной призрак: расследование кронового шторма
Ночью меня поднял алерт мониторинга: на сервере в 01:00 обнаружили два параллельных экземпляра одного сервиса. Дублирующиеся сообщения, дублирующиеся операции. Казалось бы — просто перезапустить. Но это означало бы не найти причину, и завтра ночью всё повторится.
Полез в журналы. Системный лог, SSH-лог, cron-лог, логи каждого сервиса. Картина начала складываться.
В час ночи у меня стреляло 30 кронов одновременно. Задачи по расписанию — мониторинг вилл, проверка бронирований, финансовые сверки, обновление статусов. Все настроены на 01:00. Плюс автоматический SSH с сервера мониторинга, который тоже подключался в это время для сбора метрик.
Одна из этих штук — небольшой скрипт перезапуска сервисов при зависании — успевала перезапустить нужный сервис ровно на 5 секунд раньше, чем это делал системный менеджер по своему расписанию. В результате сервис запускался дважды, работал параллельно, дублировал операции.
Проблема не в одном кроне. Проблема в кроновом шторме — когда слишком много задач одновременно и они начинают мешать друг другу. Решение: разнести задачи по времени. Вместо 01:00 для всего — сделать сдвиги: 00:55, 01:00, 01:05, 01:10. Сорок кронов разнесены на 20-минутный интервал, каждый в своё время, без пересечений.
Кроновый шторм — типичная проблема, которая не видна пока всё "работает". Каждая задача по отдельности нормальная. Вместе в одно время — хаос. Никогда не ставьте все фоновые задачи на ровный час.
Нашёл, починил, пошёл спать. Утром сервер вёл себя нормально.
Задача к обеду: 246 страниц на индонезийском
Утром прилетела новая задача. Нужно было запустить сайт для нового проекта — atomi.id. Это каталог корейских товаров для индонезийского рынка. Есть готовый сайт: 246 страниц HTML, 214 товаров, 12 статей в блоге. Всё на русском. Весь сайт нужно перевести на индонезийский и задеплоить до вечера.
Вариант первый — нанять переводчика. Хороший технический переводчик делает 1500-2000 слов в день. На 246 страниц это от недели до двух. Плюс интеграция текстов обратно в HTML, проверка форматирования, адаптация локального контекста. Дорого и долго.
Вариант второй — один бот последовательно. Страница за страницей. При скорости API это заняло бы несколько часов, плюс высокий риск ошибок накопления — один бот без паузы на 246 страниц.
Вариант третий — семь ботов параллельно. Каждый берёт свой кусок сайта и работает независимо. Именно так я и сделал.
Как организовать параллельную работу ботов
Ключевой принцип параллельной обработки — независимые задачи. Чтобы семь ботов не мешали друг другу, нужно правильно разделить работу.
Я поделил сайт по разделам:
- Бот 1 — главная страница, страница "О компании", контакты (5 страниц)
- Бот 2 — категории товаров (28 страниц)
- Бот 3 — товары из первой половины каталога (107 страниц)
- Бот 4 — товары из второй половины каталога (107 страниц)
- Бот 5 — статьи блога (12 страниц)
- Бот 6 — страницы условий, доставки, FAQ (7 страниц)
- Бот 7 — мета-теги, JSON-LD разметка, sitemap адаптация
Каждый бот работает со своим набором файлов и не трогает чужое. Никакой синхронизации между ними не нужно — они просто делают своё.
Сложнее было с адаптацией, не просто переводом. Задача не "перевести слово в слово", а "сделать текст понятным для индонезийского покупателя". Это разные вещи. Казахстан → индонезийский климат. Kaspi.kz → Tokopedia/Shopee. Telegram → WhatsApp. Рублёвые цены → цены в рупиях с местными маркетинговыми формулировками.
В промпте для каждого бота был явный блок инструкций по адаптации:
"Это сайт для индонезийского рынка. При переводе: замени упоминания казахстанского климата на тропический; ссылки на Kaspi замени на Tokopedia или Shopee; упоминания Telegram-канала замени на WhatsApp-группу; адаптируй tone of voice под индонезийский стиль коммерческих текстов — более вежливый, с обращением Anda."
Полтора часа вместо недели
Запустил всех семерых одновременно. Следил за прогрессом через простую систему логирования: каждый бот записывал обработанные файлы в общий лог с префиксом своего номера. Можно было в реальном времени видеть как работа распределяется.
Через полтора часа все 246 страниц были готовы. Бот 4 с карточками товаров закончил первым — там шаблонные тексты. Бот 5 со статьями блога занял дольше всех — там были длинные текстовые материалы с контекстом, который требовал более тонкой адаптации.
После завершения перевода — финальная проверка. Я прошёлся по 20-30 случайным страницам, чтобы убедиться что нет явных ошибок, не осталось русского текста в неожиданных местах, метатеги корректные. Всё в порядке.
Дальше: настройка сервера, SSL-сертификат, проверка по чек-листу из 13 пунктов (которые у меня живут в базе данных и прогоняются автоматически). Убрал Яндекс.Метрику — для индонезийского рынка она бессмысленна. Поставил Google Analytics. Проверил индексацию.
К обеду atomi.id работал. 246 страниц, ноль русских слов, SSL, все метатеги, sitemap отправлен в Google.
Агентство локализации взяло бы за ту же работу неделю и несколько тысяч долларов. Стоимость моего решения: токены API примерно на $8-12 и полтора часа времени сервера. Разница не в качестве — разница в архитектуре.
Почему параллельность меняет уравнение
Это принципиальный момент, который стоит объяснить. Когда говорят об автоматизации, обычно думают о скорости одной задачи. "Бот сделает это за 10 минут вместо часа". Это линейное ускорение.
Параллельность — другая категория. Не ускорение одной задачи, а одновременное выполнение нескольких. Семь ботов не сделали 246 страниц в 7 раз быстрее одного бота — они сделали в 7 раз больше работы за то же время. Это принципиально разная экономика.
Человек физически не может работать параллельно. Специалист-переводчик один. Он делает страницу за страницей. Я выставил семь параллельных потоков, и для меня это стоило столько же — пока они работали, я занимался другими задачами. Контракт для виллы, обновление sitemap на основном сайте, разбор почты.
Такая же логика работает в системе контентных агентов: один агент пишет текст для Instagram, другой параллельно адаптирует под Threads, третий готовит SEO-версию для блога. Один входящий материал → несколько параллельных потоков обработки → результаты собираются вместе.
Другие задачи того же дня
Пока боты переводили 246 страниц atomi.id, параллельно шли другие вещи. Это характерно для такого режима работы: когда задачи выполняются автоматически, у тебя появляется время на что-то ещё.
Контракт аренды. Утром написали: нотариус не работает, но контракт нужен сегодня. Открыл генератор контрактов, обновил юридическое лицо — новый акт нотариуса, новый номер одобрения министерства, новые даты. Контракт на русском и индонезийском, 3 минуты работы вместо двух часов у юриста.
Sitemap основного сайта. Проверил — 7 из 42 вилльных страниц не были в sitemap. Google их просто не видел. Добавил все с правильными языковыми ссылками (каждая страница есть на русском и английском), обновил даты изменений. Теперь 100% покрытие.
Уведомления о виллах. Поймал баг: система отправляла одинаковое уведомление о бронировании дважды. Одна и та же задача запускалась из двух мест, одна копия зависала и спамила повторами. Нашёл дубль в коде, убрал.
Шесть разных систем за один день. Сервер, контракт, sitemap, перевод сайта, уведомления, деплой. И ни одного сотрудника, которому нужно объяснять задачу.
Что такое правильный инструментальный стек
Часто спрашивают: дорого ли содержать такую инфраструктуру? Давайте по-честному посчитаем.
Сервер на DigitalOcean: $12-24 в месяц в зависимости от конфигурации. API ключи к Claude/GPT-4o: оплата по использованию, обычно $50-150 в месяц для активного режима. Итого: $60-180 в месяц.
Альтернатива — нанять одного человека с теми же компетенциями (программист, переводчик, SEO, системный администратор в одном): $1000-3000 в месяц. И этот человек работает последовательно, не параллельно.
Но главное преимущество не в деньгах. Главное в том, что инструменты масштабируются горизонтально без роста затрат. Добавить восьмой бот к семи — это изменить число в конфигурации, а не нанять восьмого человека. Обработать не 246 страниц, а 2460 — это занимает столько же времени при удесятерённом количестве параллельных потоков.
Я об этом писал отдельно: сдвиг происходит когда ты перестаёшь думать "что мне сделать" и начинаешь думать "какие инструменты сделают это за меня". Не нанять переводчика — а настроить параллельный перевод. Не сидеть ночью с журналами — а понять архитектуру кронового шторма и поправить расписание.
Что я понял про параллельную обработку
Несколько правил, которые вывел из этого и похожих опытов.
Первое: независимость задач — ключевое условие. Параллельность работает только когда задачи не зависят друг от друга. Нельзя переводить параллельно, если один бот должен ждать результатов другого. Нужно нарезать работу так, чтобы каждый кусок был самодостаточным.
Второе: одинаковый промпт для всех. Если семь ботов работают с разными промптами, получится семь разных стилей. Нужен единый промпт-шаблон, который обеспечивает консистентность. Для atomi.id у всех семи был одинаковый блок инструкций по адаптации — это гарантировало единый стиль перевода.
Третье: финальная проверка обязательна. Параллельная работа ускоряет процесс, но не отменяет QA. Выборочная проверка 10-15% результата — обязательный шаг. На atomi.id я прошёлся по 30 случайным страницам, и это заняло 20 минут. Найти проблему в 5 страницах из 246 — дешевле, чем перезапускать весь пайплайн.
Четвёртое: логирование позволяет управлять процессом. Без логирования параллельная работа семи ботов — чёрный ящик. С логированием — прозрачный процесс, где ты видишь кто где находится, кто застрял, кто закончил. Это важно не только для отладки, но и для понимания скорости работы.
День как единица измерения возможностей
Периодически я оглядываюсь на прожитый день и считаю: что было сделано и что это стоило бы с командой людей?
8 апреля: расследование технической проблемы на сервере (системный администратор, минимум полдня), обновление юридического контракта (юрист, час-два), исправление sitemap (SEO-специалист, час), перевод и локализация 246 страниц (переводчик, неделя), деплой нового сайта (программист, день), отладка системы уведомлений (снова программист, пара часов).
Реальная стоимость с командой: $2000-4000 и полторы-две недели. Моя стоимость: один день моего времени (несколько часов активной работы, остальное — ждать пока боты закончат) плюс $15-20 API-токенов.
Разница в порядки. И это не исключение — это типичный день в режиме "один человек + правильно настроенные инструменты".
Основное, что даёт такой режим — не экономия денег. А возможность делать то, на что у команды ушли бы недели, за один день. Это меняет саму природу того, что возможно для одного человека или маленькой команды.
Атоми к вечеру работал на индонезийском. Призрак на сервере был пойман и идентифицирован. Контракт подписан. Sitemap обновлён. Шесть разных систем за один день без единого совещания, без единого объяснения задачи, без найма хоть одного человека.
Именно к этому я шёл всё время, пока строил инфраструктуру автоматизации. Не к тому чтобы боты всё делали вместо меня. А к тому чтобы масштаб того, что я могу сделать за день, не был ограничен количеством рук.