Как выстроить прозрачный мост между разработкой и эксплуатацией, автоматизировать проверки до релиза и внедрить локальный ИИ в повседневные задачи? Эти вопросы сегодня волнуют всю продуктовую команду.
12 ноября пройдет онлайн-митап «IT_ONE: между кодом и продом». На одной площадке соберутся:
- Разработчики, которые хотят заглянуть внутрь DevOps-процессов и безопасно использовать LLM в работе с кодом.
- DevOps-, SRE- и QA-инженеры, ищущие готовые подходы к валидации окружений и unit-тестированию конфигураций.
- Архитекторы, тимлиды и аналитики, которым важно выстроить надежный пайплайн доставки и заложить требования к стабильности систем.
В преддверии эфира мы поговорили со спикерами митапа о двух главных темах:
- Как развернуть мощный локальный ИИ своими руками в эпоху дефицита видеокарт.
- Как сделать релизы надежными и автоматизировать проверку инфраструктуры.
Как приручить ИИ-модель на ноутбуке
Сделать токены бесконечными, обойти квоты облачных сервисов и получить мощного AI-ассистента для кода, текстов и архитектуры — звучит как мечта любого IT-специалиста. Но что скрывается за кулисами локальных моделей? Об этом мы поговорили с Русланом Кашафутдиновым, главным экспертом-программистом IT_ONE и автором доклада «Персональный ИИ своими руками».
— Какое «железо» нужно, чтобы развернуть своего ИИ-ассистента: хватит ли рабочего ноутбука разработчика или пора собирать домашний сервер?
Маленькие модели сейчас набирают эффективность. Можно на ноутбуке запустить что-то мелкое, но оно не будет работать как полноценный ИИ. Это, скорее, будет небольшой узкоспециализированный скрипт. Его можно обучить минимальному функционалу и он будет неплохо справляться. Как минимум для этого необходима либо видеокарта, либо современный ноутбук с ИИ-ускорителем — такие сейчас есть и у AMD, и у Intel.
— Может ли своя локальная модель полностью заменить условный ChatGPT или Copilot, если полностью отказаться от облачных версий невозможно?
В таком масштабе — пока нет. Но если запустить модель класса 32B (32 миллиарда параметров), то в целом это уже вполне себе рабочая история. Если создать условия, в которых будет достаточно много контекста — а это хотя бы 64 гигабайта видеопамяти, — то получается рабочая схема. Именно такие модели в основном и используются в корпоративной среде. Там они кластеризованы: их несколько сотен, и они параллельно используются через балансировщик.
— В чем главный технический подвох «бесконечных токенов» — мы платим за эту свободу скоростью генерации, качеством ответов или счетами за электричество?
Качество аналитики, которую проводит локальный ИИ сильно ниже. У него меньше база знаний и чаще всего короткий контекст, кроме упомянутых выше случаев. Проблема в том, что его можно использовать, например, только для кода, только для отладки или еще каких-то простых операций. Если смешивать контекст — как мы привыкли с облачными системами, когда просим написать целиком программу, — токены, конечно, не кончатся, но на выходе будет, мягко говоря, каша.
У маленьких моделей объем знаний небольшой. В каких-то локальных аспектах, под которые их можно дообучить, они будут работать неплохо, но «за забором», дальше собственного носа, как говорится, уже ничего не увидят.
— Почему инструкция по развертыванию своего ИИ сегодня пригодится не только DevOps-инженерам, но и бэкендерам, тестировщикам и даже аналитикам? Кому точно стоит прийти на ваш доклад и почему?
Всем, кто хочет работать с ИИ без риска утечки рабочих данных, но упирается в стоимость железа. В начале года на вторичном рынке еще можно было найти доступные видеокарты, а сейчас там чудовищный дефицит и рост цен — даже старые серверные ускорители NVIDIA уже почти не достать. Я пошел другим путем и собрал домашний кластер — по сути, небольшой суперкомпьютер из нескольких узлов, где компоненты общаются друг с другом напрямую.
Технология несложная, ее реально повторить дома на базе доступных ускорителей прошлых поколений, например AMD Instinct MI50 на 16–32 ГБ. В моем кластере 4 ноды по две карты — в сумме 128 ГБ видеопамяти на восьми GPU. На таком железе спокойно крутятся модели на 32B, 72B и даже 128B параметров с большим окном контекста. На докладе как раз разберем, как собрать такую локальную схему для обучения и безопасной работы.
Инфраструктура как полноценный код
Один сломанный релиз обходится команде куда дороже, чем пара часов на настройку автоматических проверок конфигураций. Но как внедрить валидацию и unit-тестирование Helm-чартов без бюрократии и глобального проекта «покрыть тестами вообще всё»? Об этом мы поговорили с Андреем Слатимовым, старшим техническим экспертом IT_ONE. Вместе с коллегой Виталием Перваковым на митапе они детально разберут архитектуру конфигураций, валдацию данных и практику работы с helm-unittest.
— Разработчики привыкли писать unit-тесты для кода, но тестировать инфраструктурные шаблоны — всё ещё редкость. Почему индустрия так долго к этому шла?
Helm-чарты долго воспринимали просто как конфигурацию для развертывания, а не как полноценный код, который стоит покрывать тестами. Их правят реже, чем само приложение, и привычный цикл был простым: изменил параметры конфигурации (values), развернул на тестовом стенде, посмотрел на результат. Для продуктового кода unit-тесты давно стали нормой, а вот удобные инструменты для шаблонизаторов появились позже. К тому же, ошибка в чарте часто маскируется под проблему кластера или окружения, а не выглядит как сломанный шаблон. В итоге к необходимости тестирования приходили уже после пары болезненных инцидентов при релизе. Хорошая практика здесь та же, что и с кодом: находить ошибки как можно раньше, а не после установки.
— Как внедрение helm-unittest влияет на жизнь всей продуктовой команды, которая ни разу не заглядывала внутрь папки с чартами?
Прямо на ежедневную работу разработчика, который не касается инфраструктуры, влияние небольшое. И это нормально, не стоит ждать магии. Но косвенно команда чувствует другое: становится меньше сюрпризов при развертывании, когда кто-то всё-таки меняет чарт или переменные в values. Ошибки отлавливаются раньше, на этапе CI (непрерывной интеграции), а не вечером на тестовом стенде. Ревью инфраструктурного кода становится прозрачнее: вместо оценки на глаз («визуально YAML корректен») появляются конкретные автоматические проверки. Для команды, которая живёт релизами, это означает более спокойную поставку, а не появление новой обязанности лезть в Helm-чарты.
— Как убедить команду и менеджмент потратить время на написание тестов для чартов прямо сейчас?
Не через абстрактную «культуру качества», а через оценку стоимости инцидентов и ручных проверок. Минимальный набор тестов на критичные компоненты пишется быстро: проверка образа, портов, включения сетевых маршрутов (ingress) и правил автомасштабирования (HPA). Дальше они выполняются в CI автоматически. Один сломанный релиз или час разбирательств на стенде обычно обходятся бизнесу дороже, чем пара часов на внедрение базовых тестов. Начинать можно с одного чарта и пары целевых проверок (asserts), без глобального проекта «покрыть тестами вообще всё». Кроме того, написание тестов и поддержку покрытия сегодня можно делегировать ИИ-агенту — об этом тоже пойдет речь на докладе.
— Как helm-unittest пригодился на практике?
Был кейс с вендорским чартом. Сторонние решения часто тянут за собой общие зависимости, и под нашу инфраструктуру их всё равно приходилось дорабатывать. Мы взяли тесты с наших базовых чартов — на основные объекты Kubernetes вроде Deployment, Ingress, ConfigMap — и прогнали их на вендорском. На этих базовых проверках сразу стало видно, что требует изменений. В итоге мы адаптировали чарт под наши реалии заметно быстрее. Эта практика помогает нам и в дальнейшем. Мы стремимся к тому, чтобы в наши инфраструктурные репозитории могли безопасно контрибьютить другие команды. Чарт, покрытый тестами, гораздо проще открыть для внешних изменений: ошибки локализуются на ранней стадии, а релизы остаются стабильными.
— С какого одного простого шага стоит начать внедрять тестирование чартов сразу после митапа, если сейчас в проекте нет вообще никаких проверок?
Установить плагин helm-unittest и написать один тестовый набор (suite) для ключевого объекта Deployment: проверить тип ресурса (kind), образ (image), открытый порт или количество реплик. Запустить это локально командой helm unittest. После успешной проверки — добавить этот же шаг в CI/CD пайплайн.
— Кому из ИТ-специалистов точно стоит прийти на ваш доклад и почему?
Разработчикам, чьи сервисы разворачиваются через Helm, даже если сами чарты они почти не редактируют. Станет понятно, что именно можно проверить до попадания кода в кластер, и какие требования выдвигать к platform / DevOps / SRE инженерам при ревью инфраструктурных изменений. Доклад будет полезен тимлидам и тем, кто проводит код-ревью для charts и values: появится конкретный инструмент для проверок вместо «вычитывания YAML глазами». И, конечно, platform-инженерам, которые внедряют лучшие инженерные практики в продуктовые команды — на докладе мы разберем рабочий минимум тестов, который можно сразу брать в работу.
Подробнее про митап
На самом онлайн-митапе «IT_ONE: между кодом и продом» мы пойдем еще глубже в практику и разберем сразу три больших блока:
- 18:10 — «Персональный ИИ своими руками» (Руслан Кашафутдинов). Инструкция о создании персонального ИИ своими руками, которая поможет развернуть собственную модель, обойти квоты облачных сервисов и сделать токены бесконечными
- 18:50 — «Helm-чарты: когда это действительно нужно» (Виталий Перваков). Сценарии применения валидации, способы защиты от некорректных данных и сравнение инструментов для проверки конфигураций перед развертыванием
- 19:30 — «Стабильные Unit-тесты для Helm-чартов» (Андрей Слатимов). Как автоматизировать проверку Helm-чартов с помощью helm-unittest. Ты узнаешь, как ловить ошибки шаблонизации, проверять обратную совместимость и гарантировать стабильность инфраструктуры при каждом обновлении.
Что ждет участников митапа:
- Готовые подходы: концентрированный опыт, который можно внедрить на следующий день после эфира.
- Полезный архив: всем зарегистрированным участникам мы отправим записи докладов, презентации спикеров и дополнительные материалы.
- Живой Q&A и подарки: задавай вопросы по своим рабочим кейсам в прямом эфире — авторы лучших вопросов получат фирменную футболку, стикеры и плед от IT_ONE.
