DevOps *

AI стал писать код быстрее, чем я успевал удерживать контекст работы. Код вроде написан, diff вроде разумный — но почему именно так, какие варианты отбросили, что обещали не трогать, куда делись follow-ups? Всё это жило в чате, а репозиторий видел только финальный diff.

Это третья статья серии про память AI-агентов. В первых двух — https://habr.com/ru/articles/1006756/ и https://habr.com/ru/articles/1033388/ — разбирал устройство Memory MCP Server: зачем агенту постоянная память, semantic search, грабли по дороге. Память помогла, но довольно быстро выяснилось, что «помнить» и «вести задачу до конца» — разные навыки.

В этой статье — про следующий слой: Solo Kanban, git-native delivery loop для одного разработчика и AI-агентов. Planning files, task workspace, risk-based gates, обязательный verify перед closure. Это не «новый Scrum для одного человека», а набор safety rails: минимальные файлы и gate’ы, которые не дают агенту потерять scope, пропустить проверку или оставить follow-up только в чате.

Внутри: pipeline с risk-based выбором tier’а, мини-пример сквозной задачи, связка с Memory MCP, антипаттерны из реальных кейсов (включая reviewer-LLM, который approveнул нулевую реализацию). Метод вынесен в отдельный фреймворк: https://github.com/ipiton/solo-kanban-framework (MIT, v1.0.0).

В начале года я рассказывал, как мы запустили программу подготовки DevOps-инженеров для вузов. Сейчас в программе участвуют почти 40 вузов, через курс прошли тысячи студентов. Некоторые выпускники уже работают в моей команде. Успех? Успех. Кажется, процессы отлажены, материалы написаны, нужно только их поддерживать. Однако прошлый год преподнес сюрприз. Обычно мы запускаем три потока обучения в год, но тогда партнеры решили иначе: один поток, но с тройным количеством участников. Больше ста преподавателей вузов, которым нужно получить актуальные знания, обновленные материалы и доступ к стенду. А у нас немного устаревший курс и мало людей на сопровождение. В общем, есть место для подвига.

Задача звучит просто: взять чистый образ Linux, засунуть туда Docker, контейнерные образы, скрипты настройки — и сделать так, чтобы при первом запуске все заработало без единого обращения в сеть. Как консервная банка: открыл — и готово.

На практике есть три проблемы. Первая — Docker при установке из репозитория хочет в интернет. Вторая — при запуске контейнеров Docker тянет образы из Docker Hub. Третья, неочевидная — даже в офлайне Docker создает сетевые мосты, и если не настроить маршрутизацию правильно, контейнеры просто не запустятся.

Первая статья из цикла о каналах обмена сообщениями. Разбираем архитектурные дилеммы, конкурирующих потребителей, message storm, гарантированную доставку и лучшие практики команд, работающих с JMS и Kafka.

Цель: сделать мобильный прокси.

Цели применения у всех разные, моя же цель в некоторых случаях преодолеть ограничения статического IP, который мне нужен для работы.

«Кто виноват и что делать?» — эти два вопроса, которые классики русской литературы адресовали обществу, сегодня как никогда актуальны для IT‑директоров и финансовых руководителей. Только «виноват» не конкретный человек, а не оптимально работающая инфраструктура, а ответ на вопрос «что делать?» — внедрять FinOps.

FinOps — это не технология, а организационная методика. Важная часть инструментария для FinOps это правильно построенная информационная система, которая собирает, хранит и дает анализировать данные о расходах и нагрузке. В этой статье мы разберем архитектурное ядро такой системы.

Что будем делать или что может быть интересного в статье:

- Пайплайн из двух независимых LLM агентов

- Запуск и анализ ошибки UI автотеста (Root Cause Analysis)

- Фикс автотеста в цикле с его запуском.

- Кастомизация MCP инструментов чтобы оптимизировать контекстное окно.

- Система приоритетов в работе LLM агентов.

В этой статье расскажем, как мы выстроили систему мониторинга облачных затрат в корпоративном мессенджере с помощью FinOps-ботов и какой эффект это дало бизнесу.

Эта статья совсем не технический анализ, а увлекательный рассказ о том, как маленький, но очень перспективный стартап стал топовым приложением, а также о том, какие сложности встали на пути команды разработки, DevOps и тестирования X5 Tech.

Мы сразу заложили основные принципы нагруженного приложения: микросервисы как основа всего, полное покрытие метриками, асинхронность, кэширование на максималках. Какую-то функциональность разрабатывали сами, где-то задействовали сервисы других техкоманд из X5, а где-то и сторонние решения с рынка.

Весь код писали на Python, использовали FastAPI и другие популярные на тот момент фреймворки и технологии.

У Jenkins редко бывает один владелец и один простой pipeline. В больших командах он быстро становится общей точкой, через которую проходят релизы, проверки, интеграции, доступы и десятки «маленьких» доработок.

Проблема в том, что многие решения вокруг Jenkins сначала действительно помогают. Но когда автоматизация растёт, вчерашнее удобство начинает превращаться в legacy, а цена каждого изменения незаметно растёт.

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

ClearML — это целый космос, так что мы продолжаем разбирать его компоненты. В прошлой статье мы рассматривали ClearML Session и настраивали удаленную среду разработки с Jupyter Lab и VSCode. В этот раз поговорим о ClearML Agent и разберем, как с его помощью запустить обучение на удаленном сервере, в частности, Google Colab.

Итак, поехали!

Привет! Если ты, как и я, держишь инфраструктуру небольшой команды, наверняка знаком с ситуацией: разработчиков становится больше, а DevOps-отдел при этом не растёт. С приходом vibe-coding'а эта диспропорция стала особенно заметной — у нас в студии команда разработки выросла раза в полтора буквально за пару месяцев, потому что каждый продакт-менеджер захотел свой мини-аппликейшен. Параллельно подкинули головной боли участившиеся проблемы с доступностью приложения из ряда регионов.

В результате поток обращений в канал поддержки в Mattermost вырос настолько, что значительная часть рабочего дня инженера стала уходить на их разбор. И самое неприятное — далеко не каждое обращение по итогу оказывалось в зоне ответственности DevOps, но каждое требовало хотя бы поверхностной диагностики, чтобы это понять.

В этой статье расскажу, как мы строили свою линию тех поддержки на n8n.

С интересом наблюдаю, как инженерные процессы и инструменты, к которым мы привыкли за десятки лет, переосмысливаются под ИИ-нативный подход. Например, классический CI/CD, построенный вокруг pull request-ов и человеческого темпа разработки, плохо подходит для мира, где код всё чаще пишут агенты.

До работы с агентами цикл разработки выглядел так: человек медленно пишет код → оформляет PR → CI прогоняет линтеры, тесты и сборку → другой человек ревьюит изменения → изменения попадают в основную ветку.

В такой парадигме долгое время работы CI-пайплайна часто было ожидаемым и терпимым, потому что самая большая задержка всё равно была на стороне команды: разработчик писал код часами или днями, ревью тоже ждали часами или днями, PR жил долго.

С агентами всё меняется: код генерируется быстро и относительно дёшево → задач становится больше → ветки с изменениями плодятся быстрее → PR становится слишком медленной и неудобной единицей работы → валидацию изменений нужно двигать внутрь агентного цикла.

Но CI/CD вряд ли не исчезает. Скорее он перестанет быть контуром вокруг которого происходит работа с изменениями и превратится в низкоуровневый слой для быстрой проверки изменений внутри агентного цикла. Почему так?

CI/CD в текущем виде был спроектирован для мира, где человек — главный агент.

Человек держит в голове некое намерение: например, «хочу добавить кнопку оформления заказа». Потом проходит цикл: намерение → код → pull request → CI → код-ревью → merge. На каждом этапе может быть откат назад:

11 мая Anthropic выкатили в Claude Code новую фичу — agent view. Это менеджер сессий: один экран, в котором видны все запущенные параллельно сессии Claude Code, их статус и какие из них ждут ввода. Запускается командой claude agents. Звучит как мелкое улучшение, но на практике решает реальную боль — раньше для трёх параллельных задач нужны были tmux-сетка и mental ledger в голове. Обновил Claude Code, потестил неделю, рассказываю, что внутри и где границы.

В конце февраля ByteDance выложила DeerFlow 2.0 — open-source агентный фреймворк, который команда позиционирует как “super agent harness”. Релиз залетел в топ-1 GitHub Trending, набрал 67 тысячу звёзд за пару недель, попал во все технические телеграм-каналы. Развернул через Docker на своём VPS, прогнал на реальной задаче (ресёрч по рынку эспрессо-машин с генерацией отчёта), разобрался с архитектурой. Рассказываю, что внутри, чем отличается от Claude Code и OpenHands, и почему телеграм-маркетинг расходится с честным README в нескольких важных местах.

В большинстве туториалов по Telegram-ботам всё начинается с одного куска кода: получили токен у @BotFather, поставили python-telegram-bot или aiogram, написали хендлер, deploy. Это Bot API. И в 90% задач этого хватает.

А потом приходит задача которую Bot API не закрывает в принципе: программно создать супергруппу под конкретный проект и добавить туда нужных людей по @username, и сделать это десятки раз в день. Bot API такое не умеет даже теоретически - метода «создать группу» там нет, метода «добавить юзера в группу» тоже. Лезете в полную документацию Telegram API искать обход, упираетесь в раздел  channels.createChannel  /  channels.inviteToChannel под MTProto, и начинается совсем другая история - не Bot API, а user-бот через telethon.

В этой статье разбираю как мы сделали production MTProto user-бот на FastAPI + Telethon. Под капотом: Cloudflare WARP для обхода DPI (без него с российского VPS просто не подключиться), Singleton-клиент с keepalive, in-memory cache resolve-юзеров, и 5 ограничений Telegram которые знают только те кто лез туда ногами. Реальный production-сервис у клиента в нише строительства/монтажа, обслуживает связку Planfix → Telegram-группы под каждый проект.

Сервис написан на Python 3.11. Стек: Telethon 1.43.2, FastAPI 0.136.1, Uvicorn 0.46.0, Pydantic 2.13.4. На VPS под systemd, наружу через Cloudflare Tunnel. Вызывается из n8n через HTTP-ноду.

OpenClaw позиционируется как «личный ИИ-ассистент», который помогает обычным людям. Если рассуждать, для кого он полезен больше всего, то в первую очередь — для разработчиков. Во вторую — для владельцев малого бизнеса и предпринимателей, которые могут автоматизировать и решить много реальных практических задач, на которые раньше не хватало времени и ресурсов. А также для пользователей, которые работают с большим количеством контента (сортировка почты, проведение исследований, составление контент-планов и прочее): офисные работники, студенты и т. д.

Это вторая статья из цикла о том, как я пытался сделать алерты Zabbix в домашней лаборатории чуть умнее, прикрутив к ним локальную LLM и не получить на выходе архитектурного монстра Франкенштейна.

В первой части мы разобрались с постановкой задачи и ТЗ, теперь же пришло время выбрать саму модель. В этой части мы формируем критерии к LLM (отдельно от общего ТЗ), сравниваем небольшие open-weight модели для self-hosted сценария и делаем выбор одной из моделей.

В процессе написания материал разросся до неимоверных размеров, поэтому пришлось поделить его аж на четыре части. Ссылки буду добавлять по мере выпуска (примерно раз в одну-две недели).

Часть 1: Вводная и формирование ТЗ
Часть 2: Выбор локальной LLM -> вы здесь
Часть 3: Формирование HLD и немного LLD
Часть 4: Что из этого вышло

Зачем APM‑платформы, если есть Prometheus и Grafana

Всем привет! Мы разрабатываем APM‑платформу и регулярно сталкиваемся с вопросом — зачем платить, если есть стек с открытым исходным кодом вроде Prometheus и Grafana? Поэтому давайте посмотрим на достаточно интересную тему, где я как разработчик, знаю продукт изнутри и топлю за него, но и не могу отрицать стандарты индустрии на open‑source.

Вокруг наблюдаемости давно есть устойчивый стек из open‑source продуктов: Prometheus, Grafana, Loki, Jaeger/Tempo и других. Для многих команд это дефолтный выбор — гибкий и контролируемый. В то же время, когда речь идёт о мониторинге сложных, распределенных систем и более быстром внедрении, APM‑платформы (Application Performance Monitoring and Observability) предлагают другой подход: готовый продукт с уже встроенной корреляцией данных, автоматизацией и минимальной настройкой.

Буду сравнивать по четырем ключевым метрикам: функциональные возможности, скорость развертывания, поддержка и адаптация к изменениям.

Столкнулась с задачей локализации Apache Superset — и внезапно оказалось, что «из коробки» он переводится только частично.

Поделюсь пошаговой инструкцией по локализации и сборке Docker image. Бонусом — сразу подключим PostgreSQL и Redis вместо дефолтных SQLite и встроенного кеша.