Узкое место маркетплейса — не спрос, а стоимость проведения продукта на витрину
У облачного маркетплейса есть цифра, которую редко называют вслух: во сколько компании обходится один продукт, доведённый до витрины. Не выручка с него, не конверсия карточки, а стоимость самого проведения — от момента, когда кто-то заметил проект, до момента, когда вендор видит своё решение в каталоге.
Эта цифра почти целиком состоит из человеческого времени. Кто-то смотрит рынок. Кто-то собирает образ. Кто-то проверяет чужой образ руками. Кто-то пишет вендору письмо в свободной форме о том, что не так. Пока продуктов десяток, это незаметно. Дальше это и есть потолок каталога — не спрос упирается, а собственная пропускная способность.
Последние недели я разбирал эту цифру на части и по каждой смотрел, что можно снять с людей. Получился конвейер из четырёх звеньев — радар, сборщик, проверка, витрина, — и админская консоль над ними.
Воронка августа: 412 новых сигналов, 8 кандидатов, 2 в сборке, 1 на витрине. Отклонено за месяц — 41.
Смотреть на рынок непрерывно, а не по вдохновению
Первая статья расходов — внимание. Мониторинг рынка руками имеет свойство прекращаться: неделя занята, и в списке кандидатов ничего не меняется, хотя на рынке меняется.
Радар обходит источники каждое утро в 04:30: гитхаб, Hacker News, ArtifactHub, хабр и каталоги четырёх облаков-конкурентов. Фильтр на входе намеренно грубый — 300 звёзд, создан за последние 90 дней, пуш за последние две недели: задача не собрать всё, а не пропустить то, что взлетает прямо сейчас.
Дальше начинается отбор. Проекты разведены на два трека, и это решение, которым я доволен без оговорок. «Пионер» — то, чего нет ни у кого в стране, и тогда мы первые. «Паритет» — то, что уже есть у трёх конкурентов, а у нас нет, и тогда мы догоняем. Логика решения в этих двух случаях разная, а попытка свести их в один рейтинг каждый раз давала бессмыслицу: догоняющий продукт с гарантированным спросом всегда обыгрывал рискованного пионера, и в дайджест не попадало ничего нового.
В понедельник в 06:00 из этого собирается дайджест на десять карточек. В базе сейчас 489 продуктов и 2208 сигналов.
Пять полосок справа — из чего собран балл. У DBX «риски» подсвечены: лицензия зелёная, но мейнтейнер один.
Смысл дайджеста не в том, чтобы я читал его по понедельникам. Смысл в том, что из карточки выходит подписанная заявка на сборку — то есть моё решение сразу становится входом следующего звена, а не строчкой, которую надо куда-то перенести руками.
Собирать образ без людей
Вторая статья расходов — сборка. Упаковать open-source продукт в образ виртуальной машины несложно и невероятно скучно: поднять машину, поставить продукт, убедиться, что он переживает перезагрузку, вычистить ключи и пароли, снять образ. Час работы инженера на продукт, и так каждый раз.
Сборщик делает это по рецепту. Рецепт — не скрипт, а описание: какой продукт, какой версии, с каким digest, сколько ресурсов, что вычистить, что положить в карточку маркетплейса и какие вердикты проверки ожидаются на выходе.
Одно правило в нём важнее остальных: продукт обязан стартовать сам при загрузке, без шаблона первичной настройки. Причина техническая, но последствие продуктовое — проверка на своей фазе подкладывает в машину собственный конфиг, и вендорский шаблон там не исполняется. Продукт, который поднимается только через шаблон, пройдёт сборку и провалит проверку.
Дольше всего идёт не установка продукта, а создание образа из диска — 8 минут 44 секунды на шаге, где визуально ничего не происходит.
Последняя сборка: 38 минут, смета 1,9 ₽. Это стоимость машины, на которой всё собиралось, по рейт-карте.
Проверять одинаково
Третья статья — проверка чужого образа. Здесь я ожидал возражения и получил его от самого себя: образов приходит 5–10 в месяц, человек справляется, автоматизировать нечего.
Возражение снимается, если считать не пропускную способность, а качество вердикта. Ручная проверка невоспроизводима. Двух разных инженеров нельзя заставить проверить одинаково; одного и того же инженера через месяц — тоже. Вендор получает не отказ по правилу, а мнение, и спорить с мнением он будет письмами.
Проверка прогоняет двадцать шесть правил в трёх фазах: метаданные, холодная (файловая система образа смонтирована только на чтение) и живая (машина загружена, службы подняты). Полный прогон — около получаса, отчёт привязан к контрольной сумме файла.
Самое неочевидное правило в этой конструкции — не техническое. Требование, записанное в документации для партнёров, — блокирующее. Правило, выведенное из практики, — предупреждение. Иначе вендор получает отказ по правилу, о котором его никто не предупреждал, и это уже не проверка, а произвол. Закреплено тестом: блокирующее правило без ссылки на документацию роняет сборку. Тест сразу нашёл одно нарушение — моё же.
У каждого правила указано происхождение. Поднять предупреждение до блокера — решение с уведомлением вендоров, а не правка кода.
Отдать вендору руль
Четвёртая статья расходов — самая недооценённая: переписка. Вендор прислал образ, у него что-то не так, начинается обмен письмами через менеджера, и каждый круг стоит нескольких дней с обеих сторон.
Отчёт проверки написан так, чтобы этот круг не понадобился. Не «проверка не пройдена», а список: что именно нарушено, каким правилом, из какого требования оно взято и что сделать. Заявленный минимальный диск меньше самого образа — машина из такого образа не создастся. Учётная запись с паролем — образ раздаёт общий доступ всем покупателям. Ключ сборщика остался в образе.
Предупреждения лежат в той же таблице и с тем же статусом «не пройдено» — отличает их только колонка «блокирует».
Ровно та же логика в статусах: проверка идёт полчаса, и «идёт проверка» без подробностей вендора не устроит. Поэтому наружу отдаётся ход по этапам с оценкой оставшегося времени, а названия этапов написаны на языке вендора — «Подготовка окружения», а не «выпуск загрузочного диска».
Дальше это должно замкнуться на анкету публикации: карточка, ресурсы, шаблон настройки и предупреждения о рисках заполняются из рецепта, а отчёт проверки прикладывается к анкете автоматически. Тогда вендор не заполняет форму с нуля и не гадает, что от него хотят.
Из четырёх шагов пути анкеты сейчас работают два. Автозаполнение — следующий этап, а не сделанное.
Где здесь ИИ и где я его не пустил
Модель в конвейере делает три вещи. Определяет уровень лицензии и объясняет, чем он обоснован. Пишет черновик карточки продукта на русском — описание, для кого, чем полезно. Формулирует риски упаковки: что может помешать вывести этот продукт.
Перед тем как пустить модель в гейт лицензий, я прогнал её на сорока размеченных кейсах: пятнадцать заведомо разрешающих, пятнадцать запрещающих, десять пограничных. Точность 97,5 %, и главное — ноль ошибок в сторону «красное принял за зелёное». Ошибка в обратную сторону стоит одного лишнего вопроса человеку. Ошибка в эту — публикация чужого кода без права на это.
Сборкой управляет агент через движок инфраструктуры — 146 инструментов, каждый изменяющий вызов за гейтом подтверждения. Сам конвейер тоже написан агентами: три параллельные сессии, из них радар, проверка и сборщик, а консоль на скриншотах — четвёртая.
И зона, куда ИИ не пущен, ровно такая же по размеру. Вердикт проверки детерминированный: правила — это код, а не запрос к модели. Подпись заявки — HMAC, а не «модель подтвердила». Решение продвинуть проект в сборку принимает человек, и машина состояний не имеет права его отменить. Логика простая: модель работает там, где её ошибка обратима и видна, и не работает там, где ошибка означает отказ вендору или публикацию не того.
Что это даёт по стоимости
Складывать в одну цифру пока нечего, но единичные величины считаются.
Сборка образа — 1,9 ₽ и 38 минут без участия человека. Проверка — около получаса машинного времени; сам сервис проверки занимает 16 МБ образа, 64 МиБ памяти и десятую долю ядра, вся тяжёлая работа вынесена на одноразовые машины, которые удаляются вместе с прогоном. За все прогоны проверки не осталось ни одного брошенного платного ресурса — это отдельно проверялось, потому что забытая виртуалка стоит дороже, чем всё, что мы здесь экономим.
Человеческое время из цепочки не исчезло — оно переехало. Раньше оно уходило на мониторинг, сборку, ручную проверку и переписку. Теперь остаётся решение по карточке и разбор того, что проверка отметила как непонятное.
Что пока не работает
Рецептов сборки два. Три выпущенные заявки — ollama, jenkins, argocd — ждут своих рецептов, и никакая автоматизация выше по потоку этого не чинит. Универсального рецепта не будет: продукты слишком разные.
Фаза проверки безопасности — заглушка. Ни SBOM, ни CVE она не делает, и это самая честная дыра: цепочка поставки не лечится пересборкой, её надо вести как процесс.
Требования заявки не сверяются с проверками. Заявка перечисляет четыре требования к образу, проверка делает свои двадцать шесть, и связи между ними нет: одно требование не подтверждается ничем, ещё одно — только предупреждением.
Консоль на скриншотах — прототип на подставных данных. Шестнадцать экранов, один самодостаточный HTML-файл, открывается двойным кликом. Интерфейс есть, работающей консоли пока нет.
А две недели подряд дайджест просто не выходил, и выяснилось это не по алерту, а на разборе. Система, которая молчит, выглядит ровно так же, как система, у которой всё хорошо.