Первая статья цикла обещала отдельный разбор главного сюжета месяца — переезда инфраструктуры с арендованных виртуалок на собственное выделенное железо. Снаружи он не виден: те же сайты, боты и статус-дашборд. Поменялось основание под ними, и оно объясняет почти все цифры второго месяца Arcanada.
Новых продуктов снаружи почти нет. После Coworker, Disk Arcana и Transcribator месяц ушёл не вширь, на витрину, а вглубь — на фундамент, который её держит.
Почему сложность задач выросла
Доля сложных задач — уровня L3 (обязателен PRD) и эпиков L4 — среди размеченных выросла с 29% до 33%. В абсолюте за второй период это 79 задач L3 и 22 эпика L4.
Оговорка про метод: поле сложности появилось в архивах только в мае, поэтому апрель размечен на 29%, а июнь на 86%. Абсолютные числа уровней между периодами сравнивать нельзя — это перекос разметки, а не усложнение в разы. Сопоставимы только доли внутри периода.
Откуда рост доли — видно на миграции базы данных. Перенос базы с облачной машины на выделенный сервер разбился на шесть этапов: бэкап схемы, репликация, тестовый прогон, переключение трафика, валидация целостности, снос старого. Каждый этап — отдельный L3-эпик со своим PRD, тестами и критериями приёмки. В облаке это одна команда в API; на своём железе — шесть эпиков.
Хвосты
Фирменный термин месяца — «хвосты». Перенос одного сервиса тянет цепочку: DNS, сертификаты, правила файрвола, подключения к базам, мониторинг-агенты. Разобран один хвост — открылись два новых.
Пример. База перенесена на новый сервер за день, но к ней обращались пятнадцать потребителей: сервисы, очереди, фоновые задачи, и каждый держал её адрес в своей конфигурации. Переключение «наживую», по одному, означало бы часы ошибок соединения по всему периметру. Вместо этого список потребителей собран из репозиториев, а переключение проведено через конвейер сборки — один согласованный шаг вместо пятнадцати разрозненных.
Видимая часть, перенос базы, заняла день; невидимая, пересадка всех зависимых, — неделю. Таких хвостов за месяц набрались десятки эпиков, и потому при сопоставимом числе закрытых задач второй месяц шёл тяжелее первого.
Сдвиг фокуса: топ-проекты
Сдвиг виден в топ-проектах по числу архивов. В первом периоде фокус был на фреймворке и коннекторах к моделям:
| Период 1 (апр→май) | Архивов |
|---|---|
| Datarim (фреймворк) | 101 |
| Model Connector | 58 |
| Инфраструктура | 48 |
| Auth Arcana | 30 |
| Transcribator | 24 |
Во втором на первый план вышли инфраструктура и управляемые пространства:
| Период 2 (май→июнь) | Архивов |
|---|---|
| Datarim (фреймворк) | 85 |
| Инфраструктура | 37 |
| Управляемые пространства | 25 |
| Ядро Arcanada | 23 |
| Статус-дашборд | 22 |
Доля инфраструктурных проектов выросла. Управляемых пространств и статус-дашборда в первом периоде не было вовсе — без них переезд не скоординировался бы.
Почему выделенное железо, а не больше облака
Облако удобно, пока сервисов мало. На десятках — базы, прокси, dev- и prod-окружения, очереди, кэши — аренда становится дорогой и непрозрачной: счёт идёт за пик, а не за среднюю загрузку.
Выделенный сервер — фиксированная сумма за конкретное железо, а загрузку определяешь сам. Несколько недогруженных машин дают больше запаса под автономных агентов, чем тот же бюджет, размазанный по облачным экземплярам: агент разворачивает новый сервис, не упираясь в чужой лимит.
За месяц парк сократился примерно с 24 до 19 машин: база данных и хранилище секретов переехали на новый выделенный узел, два лишних сервера снесены, две новые выделенные машины докуплены — под базу и под разработку. Счёт при этом стал выше базовых €216 первого месяца. Это осознанная инвестиция в фундамент, а не расширение.
Обратная сторона: железо не самовосстанавливается. В облаке упавшую машину поднимает соседняя; на своём сервере диагностика и восстановление ложатся на агентов с доступом и контекстом. Свой сервер требует, чтобы рядом был кто-то — человек или агент, — кто держит в голове всю цепочку.
Фундамент, на котором поводья можно отпустить
Главный тезис месяца: инфраструктура — это не расходы, а вложение в автономность. На арендованной виртуалке сервис привязан к чужому SLA, ценам и лимитам; на своём сервере контроль над железом, сетью и доступом полный.
Для агентов это решающее. Автономному агенту нельзя доверить продакшен на ненадёжном основании: задача развернуть сервис упрётся в облачный лимит на число машин, в сетевую задержку или недоступность региона — и агент зависнет в ожидании ответа. На выделенном железе эти риски минимизированы: сеть под контролем, объём ресурсов известен, загрузка видна в реальном времени.
Связка прямая: выделенное железо — предсказуемая среда — отпущенные поводья. Та же логика держит и двойную оркестрацию цикла: задача стартует локально, оркестратор на узле раздаёт её агентам в отдельных сессиях, и каждый слой стоит ровно настолько, насколько твёрдо основание под ним.
Что дальше
Переезд не финиш, а начало. Дальше — три направления:
- Добить хвосты — сервисы, ещё висящие на облачных машинах. Каждый — L3-эпик с риском уронить живую систему.
- Авторазвёртывание на железо, чтобы агенты поднимали сервисы без ручного участия, зная, что среда предсказуема.
- Метрики железа в статус-дашборд: температура дисков, загрузка процессоров, ошибки SMART — здоровье инфраструктуры агенты должны видеть так же, как оператор.
Месяц без нового продукта снаружи выглядит топтанием, и это раздражение я понимаю, потому что сам его чувствую. Но инфраструктурный долг — как процент по кредиту: не отдашь сейчас — заплатишь вдвое позже, когда автономный агент уронит прод на ненадёжном основании. Фундамент готов; следующий месяц — с автономными агентами, коммерческими проектами и открытым кодом — без этого этапа был бы невозможен.