Проекты

RunGPT

RunGPT — мой проект: шлюз до LLM-моделей через сторонних провайдеров. Оплата идёт по фактическому потреблению токенов.

Моя роль в проекте: архитектура, backend и frontend, инфраструктура, CI/CD, интеграции с AI-провайдерами, биллинг и цены, юридическая часть, маркетинг и рынок.

Возможности

чат с LLM-моделью;
API для внешних приложений;
личный кабинет со статистикой расхода и использования моделей;
подсчёт расходов агентских сессий харнесов — можно оценить стоимость разработки фичи в рамках сессии;
рейт-лимиты на основе автоматически определяемых профилей, в зависимости от класса доверия пользователя;
плагины для Chrome и Firefox.

Облачные агенты

Агенты запускаются в облаке, а управление идёт через kanban-доску:

пользователь кладёт карточку с задачей в беклог;
агент забирает задачу, переносит её в «в работе» и после завершения — в «завершено»;
сложную задачу агент может декомпозировать на подзадачи и выполнять последовательно.

Проекты и память

Проекты — персональные области работы: у каждого свои инструкции и контекст для ассистента. Чаты создаются внутри проекта, и RunGPT учитывает его специфику при ответах.

Память — сервис запоминает важные факты из общения и учитывает их в ответах. Сведения можно указать вручную, а в разделе «Память» видно, что запомнено, — это можно подтвердить или удалить. Настройки типизированного профиля: язык, часовой пояс, обращение, тон и длина ответов.

Sandbox — IQ Option Software

IQ Option Software — трейдинговая платформа (теперь Quadcode). Senior developer, команда Continuous Delivery, 2015–2017.

Проблема

Команд и людей было очень много, а тестовых стендов на всех не хватало. Люди мешали друг другу: ломали стенды и тратили огромное время на поиск и решение проблем с ними.

Нужен был инструмент, который создаёт изолированные тестовые среды по требованию и повторяет реальную production-инфраструктуру. Тогда проблемы на одном стенде не затрагивают другие, а тестировщики параллельно проверяют задачи на своих стендах, не блокируя друг друга.

Это был совершенно новый проект в компании. Мне повезло оказаться первым, кто начал над ним работать, — с полной свободой действий и выбора инструментов.

Что реализовано

Сборка на лету. Сборка разворачивается в отдельной виртуальной машине во внешнем облаке по требованию; когда она не нужна, VM вместе со всеми контейнерами уничтожается.
Конструктор микросервиса. Разработчик создаёт микросервис через веб-интерфейс, указывая, из каких компонентов он состоит: за несколько минут можно собрать конфигурацию из контейнера с приложением, базы данных и брокера очередей. Часто используемые компоненты выбираются из списка; если нужного нет — можно подключить свой docker-образ из внутреннего хранилища.
Собственное хранилище docker-образов. Образы компонентов команды собирают сами через CI и кладут в общий Registry на своих мощностях — суммарно больше 5 ТБ образов.
Маппинг портов. В интерфейсе управления компонентами настраивается публикация портов на хост-машину, после чего компонент доступен извне.
Переменные окружения на уровне компонентов микросервиса, с возможностью переопределить их перед началом сборки.
Кастомизация образов перед сборкой. Можно выбрать, какой образ использовать: например, запустить сервис на другой версии Postgres и посмотреть, как приложение ведёт себя на новой БД.
Изоляция на уровне VM и контейнеров. Под каждую сборку создаётся отдельная виртуальная машина, где поднимаются сотни контейнеров — по одному на каждый компонент. Число сборок не ограничено.
Кастомные облачные провайдеры. Архитектура позволяла интегрировать любого провайдера с внешним API.
Интерактивный процесс сборки. Разработчик видит ход сборки и логи прямо в веб-интерфейсе.
Тарифные планы. При создании сборки выбирается тариф VM — от минимальной мощности до 32 ядер, 128 ГБ памяти и 512 ГБ SSD с возможностью подключать дополнительные разделы под сторадж.
SSH-доступ к сборкам. Для каждой сборки был доступ по SSH — можно управлять хостом и отлаживать.

Итог

Компания получила self-service платформу изолированных окружений: любой разработчик или тестировщик поднимает стенд, повторяющий прод, за несколько минут и так же быстро от него избавляется.

Что это дало:

параллельная работа без блокировок — у каждой команды свои стенды, поломка одного не затрагивает остальные, а время на разбор чужих проблем и поиск свободного стенда ушло;
предсказуемое окружение — сборка повторяет production-инфраструктуру, поэтому баги воспроизводятся там, где их и ждут, а не «только на моей машине»;
экономия ресурсов — виртуальная машина живёт только пока нужна и уничтожается вместе с контейнерами;
стандартизация — общий каталог компонентов и собственный Registry на 5+ ТБ вместо самодельных стендов у каждой команды;
быстрая отладка — SSH-доступ к хосту и логи сборки в веб-интерфейсе;
проверка гипотез — смена версии зависимости или нагрузочный тест на мощной VM занимают минуты.

Система не осталась внутренним экспериментом: вокруг неё выросла команда инструментов разработки, деплоймента и управления серверами, а сама платформа обросла новыми возможностями, была переписана на другом языке и ушла далеко вперёд.