DevOps *

В статье рассматривается опыт миграции сети Kubernetes-кластера на новый IP-пул (Pool IP) с использованием CNI Cilium. Особое внимание уделено процессу смены IP-адресов для Pod'ов и Service'ов в работающем кластере без длительной остановки, а также подводных камнях, с которыми пришлось столкнуться при обновлении до версии 1.20.0. Материал будет полезен инженерам по эксплуатации Kubernetes использующих уже Cilium, а так же желающим познакомиться с этим инструментом.

Claude Code History Viewer читает ~/.claude/projects и превращает машинный JSONL в нормальный интерфейс: диалоги с тулколлами и сабагентами, глобальный поиск, статистика по токенам и стоимости, плюс истории ещё 27 клиентов вроде Codex CLI и Cursor. Показываю, как поднять его headless-режим в Docker на сервере без иксов (готовый бинарь + тонкий образ), что показывает Global Overview на 3,4 ГБ истории, как дёргать те же команды по HTTP через POST /api/<имя> и на какие мелочи я наступил — от обрезанного в логе токена до лимита памяти 512 МБ в официальном compose.

Что происходит после создания сервера? Его ещё нужно настроить: установить пакеты, создать пользователей, настроить службы, Docker, Nginx и другие компоненты. В статье разбираемся, как автоматизировать эту работу с помощью Ansible — одного из инструментов, упрощающих этот процесс.

Мощная и действительно "нано" по размерам – Nano Pi R3S. Это одна из крутых плат, которую можно купить по низкой цене и реализовать на ней много проектов - особенно если на ней стоит Docker!

Мне было интересно протестировать как там работает zapret и реализовать мою задумку с двумя сетями. Свободная и без блокировок сеть, которая еще и расширяет зону покрытия основной сети.

В cloud-native-среде безопасность давно не ограничивается защитой периметра. Уязвимость может появиться в IaC-шаблоне, попасть в контейнерный образ, пройти через CI/CD и проявиться уже в продакшене.

Тема очень сложная, поэтому когда я наткнулся на большой англоязычный материал о cloud-native-безопасности в публичном репозитории Security Technical Advisory Group, то сразу решил его перевести.

Cобрал практическое саммари: какие риски возникают на этапах разработки, сборки, развертывания и эксплуатации (runtime) и какими механизмами их закрывают — от DevSecOps и защиты цепочки поставки до Zero Trust и политик для работающих нагрузок.

Привет, Хабр!

Давеча я приметил в Интернете, что коллеги отображают UID/GID своих сервисов в rootless podman контейнерах, начиная с круглого числа, например --uidmap=0:1000000:65536 для первого, --uidmap=0:2000000:65536 для другого, --uidmap=0:3000000:65536 для третьего и т.д. В общем-то, в этом нет ничего предосудительного, ведь задача таким образом решается без пересечения пространства имён. Но и причина, по которой так делают, тоже понятна - перестраховаться. Давайте разберёмся, как отображать UID-в-UID в rootless podman:

Мы выпустили NEOMSA APIM 4.6.0. Основной фокус этого релиза — повышение безопасности состава поставки платформы.

В рамках процессов безопасной разработки (SSDLC) мы сформировали SBOM, проверили компоненты и их зависимости на известные уязвимости (SCA), сопоставили результаты с БДУ ФСТЭК России и обновили проблемные библиотеки. По итогам повторной проверки количество зарегистрированных находок сократилось с 57 до 7. Уязвимостей уровней Critical и High в финальной сборке не осталось.

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

Вышел Cozystack v1.6.0. Релиз опубликован 22 июля 2026 года и включает все исправления, ранее вышедшие в патч-релизах v1.5.1–v1.5.3. Ниже — перевод официального анонса, дополненный главными исправлениями из патч-релиза v1.6.1 от 5 августа.

В этом выпуске изменилось несколько важных частей платформы. Рабочие узлы тенантных кластеров Kubernetes теперь работают на Talos Linux вместо Ubuntu, тенанты могут включать аутентификацию OIDC для Kubernetes и Grafana, а новый API SecurityGroup даёт более безопасный интерфейс для управления сетевыми политиками приложений.

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

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

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

Часть 1: Вводная и формирование ТЗ

Часть 2: Выбор локальной LLM

Часть 3: Формирование HLD и немного LLD

Часть 4: Что из этого вышло (Вы здесь)

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

13,84 млрд рублей потерялись. Моя гипотеза: заметную часть этой суммы мы тратим на повторное создание одинаковых платформенных функций. Размер этой части ещё нужно измерить, но он точно существенен. И эта часть вместо мультиплицирования технологического задела в тиражируемых решениях российских вендоров остается технологиями для одного клиента.

За последние несколько месяцев плотной работы над инфраструктурой для проекта я прошёл путь от первых команд в терминале Linux до настройки полностью отказоустойчивого K3s‑кластера с Zero‑Downtime деплоем. Шишек на этом деле я набил огромное количество, и мне определённо есть чем поделиться.

Сразу оговорюсь: в этой статье не будет монотонных гайдов, слепых копипастов YAML‑манифестов и пересказа официальной документации. С базовой настройкой вы отлично справитесь, прочитав мануалы создателей этих инструментов.

Для меня этот материал — способ структурировать собственный опыт. Хотя, не буду скрывать, обсуждения в комментариях мне тоже интересны. Я хочу разобрать реальные ошибки при переходе от простого Docker Compose к Kubernetes, показать процесс траблшутинга и критически взглянуть на проделанную работу, чтобы понять: а всё ли было сделано верно?

Уверен, статья будет интересна не только DevOps‑инженерам, но и backend‑ и frontend‑разработчикам, а также любым техническим специалистам, которые хотят понимать, что на самом деле происходит с их кодом после пуша в репозиторий, почему локальная среда так сильно отличается от реального продакшена и как заставить приложение выживать при сбоях инфраструктуры.

Я занимаюсь инфраструктурным DevOps в YADRO — кластеры, виртуализация, мониторинг, оптимизация железа. Последнее время на работе был сильный завал. Голова кипела. Захотелось отвлечься на что-то совсем другое: переключить мозги с «как ускорить сборку на три секунды» на «как это вообще работает». Пока думал, как занять подобным образом свободное от работы время, попалась мне статья про УВБ-76.
 
Знаете это чувство? Читаешь про что-то странное и загадочное, и внутри загорается лампочка: «А чего так не системно то?» Тут и родилась идея объединить свою профессиональную деятельность с чем-то новым для меня. Не просто послушать разок жужжание из любопытства, а построить целую станцию наблюдения. Сразу пришло понимание, что сидеть ночами с наушниками и слушать странный эфир я не хочу...

Для проверки сквозного трейсинга 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 раз, а в удачных случаях — до двух порядков.

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