DevOps *

Для проверки сквозного трейсинга GenAI-приложения мы взяли OpenTelemetry Demo 3.0. В обновлённом стенде уже были сервисы chatbot, agentи mcp, а также ИИ-спаны. Оставалось направить телеметрию по OTLP в ProtoOBP и открыть готовую цепочку вызовов. Но все спаны приехали, а единой истории не получилось: один пользовательский запрос распался на два трейса на границе MCP.

Автоматическая HTTP-инструментация связь не восстановила. Мы проследили traceparent до MCP _meta, нашли место потери контекста и добавили небольшой слой над ClientSession. После исправления цепочка собралась в единый трейс из 27 спанов.

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

Когда в системе есть узел между LLM и пользователем его скорость также важна, как и скорость самой LLM. Когда этот узел сам является моделью (и иногда даже — тоже LLM) — задача ускорения становится совсем веселой и её нужно уметь решать разными способами. В этой работе я опишу процесс ускорения guardrail‑модели — узла, которые проверяет — нет ли на входе или выходе опасного контента.

Guard стоит на входе/выходе LLM‑приложения. В статье речь про небольшую модель — чуть больше 0.5 Gb. Но она вызывается дважды за один ход диалога, и сначала пользователь ждет, пока guard проверит его запрос перед отправкой в LLM, затем — пока он проверит сгенерированный ответ перед выдачей пользователю.

Моей задачей было ускорить такую небольшую guard‑модель (Locustfile, базовые benchmark‑конфиги и инструкции по воспроизведению экспериментов в репо). Я потестила пять инструментов: TensorRT, NVIDIA Triton, vLLM, Ray Serve и отдельно — переход бэкбона на Flash DeBERTa.

Про допущенные ошибки, результаты и выводы — о том, как бы я построила подобную работу сейчас — ниже. Надеюсь, это сбережет вам время.

Каждый раз при создании новой виртуальной машины проходить через ручную установку ОС, разметку дисков, создание пользователей и прокидывание SSH‑ключей — сомнительное удовольствие, забирающее кучу времени.

К счастью, в Proxmox VE можно один раз потратить 10 минут, настроить правильный «золотой» шаблон с Cloud‑Init и забыть о рутине, раскатывая свежие ВМ буквально в пару кликов. Но тут есть свои подводные камни: от правильного выбора видеоадаптера до хитростей с расширением дискового пространства через qm import.

Как собрать такой идеальный шаблон без лишней боли? Разберем по шагам.

Сетевой протокол HTTP/3 в разработке с 2016 года, а его транспорт QUIC вышел в 2013-м. На сегодняшний день оба эти стандарта поддерживаются всеми ведущими браузерами (кроме Samsung и Opera Mini) и составляют 32,5% HTTP-запросов на Cloudflare, что отражает актуальное состояние всего интернета. Но темпы внедрения HTTP/3 крайне медленные.

Что же мешает веб-мастерам перейти на современный стандарт и ускорить загрузку сайтов? Основная причина в том, что ни QUIC, ни HTTP/3 до сих пор не включены в стандартные библиотеки популярных языков программирования Go, Rust, Python и Ruby. Они не активированы по умолчанию в Node.js, веб-серверах Nginx и Apache. Прошло более десяти лет, но протокол всё ещё считается экспериментальным! Удивительно.

Три месяца я строил одну и ту же контент-машину для AI/tech-канала тремя способами: вручную с ChatGPT, в n8n и на Python через Claude Code. В статье — архитектура из трёх пайплайнов, реальные тайминги из production-логов, миграция с SubMagic на собственный постпроцесс за один день и практический чек-лист, который поможет выбрать между ассистентом, визуальным конструктором и собственным ИИ-агентом.

Привет, Хаброжители! Сегодня мы хотим рассказать вам побольше о нашем новинке: «Метрики программной архитектуры. Кейсы, повышающие качество ПО».

Это не монография, а сборник из десяти самостоятельных глав от десяти архитекторов (Форд, Фарли, Лилиенталь, Вудс, Роза и другие), объединённых темой измерения качества архитектуры. Единой теории в книге нет, но есть рабочий код, формулы и параметры оценки, которые можно перенести в проект сразу — от DORA-метрик и фитнес-функций до GQM-подхода.

По данным Stack Overflow Developer Survey, классический Visual Studio Code удерживает абсолютное лидерство среди IDE с долей 75,9%. Однако с каждым днем все больше на пятки ему наступают специализированные ИИ-форки: один только Cursor в 2025 году стремительно взлетел и забрал себе 17,9% рынка, а что покажут результаты 2026 года, нам еще предстоит узнать.

У разработчиков здесь есть два пути: полностью мигрировать на новый ИИ-ориентированный форк или прокачать привычный VS Code до его уровня. Оригинальный редактор за счет расширений хорошо адаптируется под любые современные задачи — от запуска ИИ-агентов до управления облачной инфраструктурой.

Плагинов существует огромное количество под разные задачи, и чтобы эта подборка не превратилась в топ-10 расширений, которые вы сохраните и никогда потом не используете, мы опросили инженеров Selectel и выяснили, какие плагины реально полезны и экономят часы рутинной работы.

Привет, это Антон Пионтковский из команды Monium Metrics, и вместе с коллегами мы создаём observability‑платформу для сбора, хранения и анализа телеметрии Yandex Monium. Мы храним миллиарды метрик и обрабатываем 50 гигабайт логов в секунду, а внутри Яндекса с Monium работают 16 тысяч сотрудников.

Чтобы справиться с объёмом метаданных метрик Kubernetes, мы научились фильтровать их по времени. Сначала наивно с помощью линейного сканирования, и потому только для небольшого круга пользователей. Но результат нам так понравился, что мы захотели включить фильтр для всех. Поскольку первоначальный подход нельзя было скейлить, мы использовали специальный — range encoded bit sliced — индекс, и получили ускорение в 6–20 раз, а в удачных случаях — до двух порядков.

Расскажу, как мы дошли до такой жизни, как устроен этот индекс, и что потребовалось сделать, чтобы всё в продакшн‑среде работало быстро.

Что делать, если Docker Desktop и L2 multicast живут в разных мирах, а доказать failover кластера перед тегом v1.3.0 всё равно нужно? Под капотом: SSH-контейнеры, unicast keepalived, 9 PASS / 0 SKIP и пара неожиданных багов с Alpine и CRLF.

Всем привет! Хотел бы поговорить о мониторинге наших web, да и не только web, приложений, в первую очередь, о проблемах, с которыми мы сталкиваемся. В этой статье я буду использовать язык python и популярные сервисы, чтобы содержимое было максимально понятно большинству.

У GitPython есть защита от опасных опций git. Я передал ей --upload-pack=/srv/lab/helper.sh, она отказала. Передал то же самое записью короче, -u/srv/lab/helper.sh, и она пропустила: скрипт выполнился. Это CVE-2026-67324, уязвима 3.1.50, исправлено в 3.1.51. Ниже стенд, живой вывод обеих попыток и разбор, почему шестистрочная проверка промахнулась.

Изначально это был монолитный портал на Laravel 8, где user фронт и admin фронт лежали рядом с беком в одной папке. 

Проект ставился каждому клиенту на его собственный хостинг, и единого портала «для всех» не существовало, между клиентами отличался и бек, и фронт. 

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

Хуже всего это вылезало в поддержке. Приходит баг, лезешь в код и понимаешь, у другого клиента это давно починено, просто фикс так и не доехал до этой копии. Каждая правка жила в своей репе.

Поэтому, когда появилось время, я занялся этим проектом. Сразу поставил рамку, фреймворк не меняю, остаёмся на Laravel 8. Хотелось не переходить на другой язык, не заниматься переписыванием всего огромного бека, отделить всё в модули и переписывать уже поэтапно отдельные куски.

Стандартная (для многих) история. Отдаём какие-то данные в реальном времени через server-side web-gRPC стримы.

Цепочка: балансировщик, дальше Envoy с grpc-web, дальше бэкенд. Все проверки зелёные: TCP поднят, хендшейк проходит, /healthz отвечает 200, в графане/slack'e тишина. А фронтенд у клиентов замёрз. И узнали мы об не от мониторинга.

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

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

В статье разберём, как OpenTelemetry объединяет телеметрию распределённых систем, где в этой архитектуре находится Collector и какие ошибки чаще всего мешают получить действительно полезную наблюдаемость.

В компании есть Kubernetes, GitLab с пайплайнами и стена дашбордов в Grafana. А деплоить всё равно страшно — по пятницам нельзя, релиз согласовывают в личке, о падении прода первым сообщает клиент. Если картинка знакомая, то у меня плохие новости в формате чек-листа. Ниже десять симптомов карго-культа с проверочными вопросами.

До этого момента мы изучали Terraform локально. Теперь пришло время применить эти знания в реальной среде.

В этой статье мы подключим Terraform к облачному провайдеру, создадим первую инфраструктуру, разберём процесс создания сети и виртуальной машины, а также сравним особенности AWS, Microsoft Azure, Google Cloud Platform (GCP) и Yandex Cloud. Несмотря на различия между облачными платформами, вы увидите, что принцип работы Terraform остаётся практически одинаковым.

Всем привет! Меня зовут Петрович и я работаю техлидом java команды в небольшом международном финтехе. В этой статье я хотел бы поделиться с вами опытом миграции наших сервисов с Redis на Hazelcast, а также о том какие уроки мы усвоили. Статья будет полезна тем кто рассматривает отказоустойчивые и более простые в поддержке альтернативы Redis.

Наша команда отвечает за подсистему оценки платежеспособности клиентов (в народе - скоринг). Стек - классический джентльменский набор для java команды - последняя LTS версия Java, Spring Boot (с Hibernate), база PostgreSQL, брокер сообщений RabbitMQ, авторизация через Keycloak, кэш Redis, собираем в docker контейнеры с помощью jib и деплоим в k8s через gitlab, arttifactory используем для хранения стартеров и библиотек.

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

С точки зрения кластеров k8s наша подсистема полностью изолирована и не зависит от других подсистем компании. Другими словами, все необходимые для работы подсистемы ресурсы мы хостим и поддерживаем сами. Redis, Keycloak, S3 - всё это работает внутри каждого из наших кластеров, обеспечивая достаточное резервирование. Всё, кроме Redis.

Хочу поделится с более конкретным примером и подробным описанием настройки плагинов для ArgoCD чем это описано в их офф документации.

В прошлой статье я писал о WIE - userspace эмуляторе, который через JIT позволяет запускать PE64 бинарники на Apple Silicon. Казалось бы проект шел хорошо - почему делаешь новое? Дело в том, что я уперся в ужасную скорость - 7zip реальный проект на 200+ мб сжимал в 80-100 раз медленнее, чем нативный macOS бинарник. И это исправить без радикальной переработки проекта и разрушения самой концепции невозможно. Поэтому его разработка к сожалению была приостановлена.

Но мне хотелось попробовать сделать то, что сохранит идею переноса бинарника одной OS на другую, но без JIT. И я нашел. И имя ему Kakehashi