DevOps *

С интересом наблюдаю, как инженерные процессы и инструменты, к которым мы привыкли за десятки лет, переосмысливаются под ИИ-нативный подход. Например, классический 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 и встроенного кеша.

Привет, Хабр! Я Эдуард, в команде РСХБ.Цифра занимаюсь организацией проведения нагрузочного тестирования. В нашей команде инженеры НТ занимаются проверкой производительности как монолитных, так и микросервисных решений. Одно из больших направлений — это мобильное приложение «Свои финансы» от РСХБ. В этой статье расскажу о том, как мы проводим нагрузочное тестирование UI‑микросервисов и поделюсь ценными выводами на тему.

Когда идёт речь про микросервисы, большинству читателей представляется сложная архитектура связей между различными блоками, внешними системами, другими микросервисами и базой данных. То есть первым делом мы, конечно же, думаем о backend микросервисах. Действительно backend выполняет основную работу в современных приложениях, являясь двигателем всех процессов.

Low-code и zero-code платформы решают логику и бизнес-процессы, но не решают email deliverability. Между «платформа отправила письмо» и «получатель его увидел» лежит слой, который ни одна из этих платформ не контролирует:

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

Третья часть про DevOps-агента Oni. В первой статье я встретился с реальностью — локальные модели не справляются с простыми задачами. Во второй разбирал, как несколько дней бился с delta-merge и в итоге пришёл к dataset evolution — каждую новую модель учить с нуля на чистом Qwen3:14B, а эволюционировать только датасет. Способ рабочий, но встал вопрос: где брать сам датасет. Hand-crafting упирается в потолок — 1.5–2K трейсов на коленках, дальше надо что-то решать. Эта статья про то, как я неделю гонял локальную дистилляцию, провалился с популярным HF-датасетом, нашёл правильный источник и в итоге получил модель, которая делает realworld-тесты 10/10. И про то, что главное — не процесс, а правильные данные.

Один из самых распространённых вопросов от стартапов и разработчиков: «Нам нужно зарегистрировать программу в Роспатенте — это же обязательно для защиты?»

Нет. И это не единственное заблуждение вокруг регистрации программ для ЭВМ.

Разберём, что регистрация реально даёт, почему недобросовестный человек может зарегистрировать вашу программу на себя, и чем ситуация в России принципиально отличается от США.

Играешь или играл когда‑то в Dota? Тогда я уверен, что ты сможешь научиться DevOps и стать в нём одним из лучших. Включай внимание и вникай, если ещё не вкатился в IT, либо готовься опровергать мой спич.

Я, как, наверное, и большинство людей, своё знакомство с компьютерами начал через игры. Игры учат нас систематическому мышлению, определённым механикам. Каждая игра включает в себя обучение, например, как двигаться, как драться и, собственно, проходить уровни. В уровнях систематически встречаются маленькие проблемы, то есть лёгкие враги, которых ты пачками бьёшь, если, конечно же, разобрался в управлении. Под конец уровня ты, скорее всего, встретишься с боссом этого уровня, которого будет достаточно трудно победить, и тебе непременно нужно будет применить для победы все выученные приёмы! Прошёл уровень? Держи новый, он будет достаточно сильно похож на предыдущий, но враги и твои проблемы становятся сложнее, и ты учишься новому, чтобы стать лучше и быстрее побеждать твоих врагов!

Уже начинаете понимать, к чему я клоню? Да, это очень похоже на реальную жизнь, в принципе: наши уровни — это как минимум наши годы, с течением которых мы становимся старше и встречаем «новые» проблемы. Мне нравилось играть, и я хотел с таким же интересом работать на своей будущей работе. Пока я учился, я узнавал новые приёмы и места, где их применять. Так я изначально и познакомился с компьютерными сетями: с тем, как общаются маршрутизаторы и коммутаторы, да и с тем, как вообще устроен интернет. За любой компанией стоит инфраструктура, где запущены серверы, а серверы соединены в локальную сеть благодаря сетевому оборудованию.

Продолжаем серию про файнтюнинг и создание DevOps‑агента Oni. В прошлой части я встретился с реальностью — ни одна локальная модель не справилась с простой задачей «зайди на сервер, посмотри в контейнере backend — логи». Я решил попробовать дообучить модель на базе qwen3:14b. Раньше никогда не сталкивался с обучением моделей, и представление было такое: всё происходит по кругу — взял модель, обучил, протестировал, выявил ошибки, снова обучил, снова протестировал. И постоянно совершенствуешь одну модель, дообучая её. Как‑то так. Дошёл до oni:v8 с 11/11 на Django scaffold — а дальше любая попытка добавить новый скилл ломала старое: 11/11 → 9/11 → 4/11 → 4/11 → 3/11 → 0/11. Эта статья про то, как я сам себя дообучил в дообучении моделей.

n8n запускается одной командой docker run и через пять минут вы видите логин-форму. Это маркетинговый ролик. Реальный production-конфиг - с persistent storage, корректными webhook-URL, ретраями, бэкапами PostgreSQL и мониторингом - выглядит сильно иначе. В этой статье - конфигурация, которую я держу на 12 проектах в течение полутора лет. Плюс три грабли, на которые наступал лично.

Все примеры - community-edition, без коммерческой лицензии. На проде у меня сейчас крутится 2.19.5, но в image: стоит n8nio/n8n:latest плюс Watchtower (про него ниже) - он подтягивает свежий образ ночью. Внутри 2.x API/env-переменные стабильны, рекомендую :latest + Watchtower на проектах где простой 5 минут утром не критичен, и закреплённый минор (:2.19.5) - на проектах где даунтайм нельзя.

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

Я назвал его TLSS, или TLS Service — карманный pki сервис.

Каждый месяц с карты списываются деньги за подписки. Spotify, Яндекс Плюс, Notion, Obsidian Sync, Google One — суммы небольшие по отдельности, в сумме набегает заметно. Параллельно с этим у меня работает VPS с несколькими проектами, на роутере крутится OpenWrt с AdGuard Home, в ноутбуке стоит Docker. Инфраструктурный опыт есть. Дома при этом — никакого сервера, всё в облаке.

Это начинает раздражать не только из-за денег. Сервисы меняют каталоги без предупреждения, поднимают цены, требуют доплат за объём, периодически ломают регионы. Контроль над собственными фотографиями, заметками и медиатекой постепенно перестал быть моим.

Решил спланировать переезд на свой мини-ПК. Пока разбирался с железом и стеком, обнаружил, что нормальной системной дорожной карты «бери и иди» в 2026 году нет. Есть каталоги «50 self-hosted сервисов», восторженные посты про конкретные приложения, треды на Reddit. Структурированного маршрута для нового человека — нет.

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

Я делал AI Review как простой инженерный инструмент. Но реальный фейл оказался не в архитектуре и не в LLM — а в том, чего люди от него ждали.

В статье описаны результаты, которые получил в поисках ответа на вопрос «можно ли решать реальные задачи диагностики и исправления проблем инфраструктуры на слабом MacBook в агентском режиме (да, но)».