DevOps *

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

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

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