DevOps Deflope News

ConfigHub официально запустился — это стартап от Brian Grant (оригинальный архитектор Kubernetes), Alexis Richardson (основатель RabbitMQ и Weaveworks) и Jesper Joergensen (бывший продуктовый лид Heroku и топ Twilio). Летом 2024 они были в режиме стелса и только набирали команду, теперь вышли с готовым продуктом. Проблема, за которую они взялись: управление конфигурациями в облачных системах превратилось в хаос. Настройки разбросаны по десяткам мест от Git-репозиториев и YAML-файлов до облачных сервисов и систем управления секретами. Чем больше мест, где всё это хранится, тем выше риск что-то сломать при изменениях. ConfigHub предлагает подход Configuration as Data. Традиционные DevOps-тулы требуют, чтобы все изменения шли через пайплайн. ConfigHub позволяет в критической ситуации внести изменения напрямую, а затем автоматически привести всё в порядок и синхронизировать состояние в масштабе. Продукт уже работает для пользователей Kubernetes, Helm и GitOps. Учитывая, что команда уже создала Kubernetes, RabbitMQ и популяризировала GitOps, следить за их новым проектом точно стоит. Источник — пост Alexis Richardson на LinkedIn.

4 декабря в Москве пройдёт Kuber Conf от Ассоциации облачно-ориентированных технологий. Флант, Yandex Cloud и VK Cloud создают АОТ, первую в России некоммерческую организацию для развития Cloud Native-технологий вне вендоров. И сразу делают конференцию, чтобы собрать всех, кто работает с Kubernetes и облаками. На конфе представители ассоциации расскажут о проекте. Зачем всё это нужно и что хочется делать: стандартизировать компетенции, поддерживать Open Source, объединить сообщество. Ну и, конечно, нас ждут доклады от практиков. Не про то, что мы уже много раз слышали на других конфах, а про свежие кейсы и реальные проблемы. Хотите стать спикером? Если работали с чем-то новым в Kubernetes, внедряли интересные решения в облаках или решали нетривиальные задачи — расскажите об этом. Рабочий опыт, сложные проблемы, даже провалы (они самые интересные и полезные). CFP ещё открыт. Кстати, про билеты. Коллеги постарались сделали их максимально доступными с доступом ко всем докладам, материалами конференции, обедом, нетворкингом и афтерпати. Важно, чтобы прийти мог каждый, кому интересна тема. Вся информация про билеты и регистрация здесь. Приходите, будет классно. Давно пора собраться и сделать что-то большое вместе. До встречи 4 декабря!

Быстро потестировать etcd или поковырять containerd без поднятия локального кластера? Собрали браузерные песочницы, где можно экспериментировать с инфраструктурным софтом без танцев вокруг Docker Desktop и minikube. 1. Etcd Playground — для тех, кто хочет понять мозг Kubernetes Интерактивная песочница с полноценным (но, ясное дело, учебным) кластером etcd из трёх нод. 2. Kubernetes Playground — браузерная площадка с готовым многоузловым кластером Kubernetes Кластер развёрнут через kubeadm с возможностью выбора контейнерного рантайма и сетевого плагина. Можно экспериментировать с настройками, отлаживать манифесты и тренироваться в администрировании. 3. Nerdctl Playground — containerd с человеческим лицом Площадка позволяет работать с containerd через Docker‑совместимый CLI, который упрощает работу по сравнению с нативным ctr. Можно изучать namespaces, snapshotter’ы и жизненный цикл контейнеров без установки локального рантайма. 4. KodeKloud Playgrounds — готовые среды под задачу Предварительно настроенные среды под конкретные курсы (Terraform, Docker, K8s, Ansible). Не нужно ничего поднимать, остаётся только выполнять задания. 5. LabEx — тренажёр с дорожной картой Пошаговое обучение с автоматической проверкой заданий. Много практических сценариев от базового Linux до сложных тем в K8s и Cloud. Эти площадки не заменят продакшен-кластеры со всеми их перформанс-проблемами, конечно же. Но будут весьма полезны для обучения. Используете что‑то интересное для экспериментов с Kubernetes и containerd? Пишите в комментариях :)

Наткнулись на kubesec-diagram — интерактивную карту угроз Kubernetes, созданную внутри Telenor Norway. И знаете что? Она реально хорошая :) Это интерактивная SVG-схема, визуализирующая поверхность атаки Kubernetes-кластера. Всё заточено под on-prem, так что для облачных K8s-кластеров и managed-сервисов может быть не так актуальна. Но, в целом, диаграмма может помочь, когда нужно быстро разобраться в security-контексте K8s или объяснить джуну, почему RBAC — это не просто галочка в чек-листе. Внутри живая схема с кликабельными элементами. Тыкаете на "Container Process", получаете детали про PodSecurityContext, syscall restrictions и runtime enforcement. В разделе RBAC наглядно показана работа role bindings и опасность группы “system:masters”. Думаем, что инструмент может быть полезен для DevOps/SRE-инженеров как минимум в двух основных сценариях: обучение новичков и быстрый аудит во время инцидентов. Да, большинство информации можно найти в CIS Benchmark или официальной документации K8s, но когда нужно быстро освежить тему или показать коллеге связь между компонентами — почему нет? Диаграмма местами перегружена деталями, и для продакшена все равно придется изучать каждый компонент отдельно. Но как starting point для понимания attack surface в кластере — вполне годится. Ещё можно сесть, покопаться и найти что-то новое. Проект активен, последнее обновление — v9 от августа 2025 года. Это полезный вспомогательный инструмент, но не истина в последней инстанции. Сохраните в закладки для командных обсуждений архитектуры, но, всё же, для полноценного аудита полагаться на специализированные средства, такие как kube-bench, kubeaudit или Falco. Проект на GitHub: github.com/kubesec-diagram/kubesec-diagram.github.io

Новый выпуск — и он про безопасность! В нём эксперт по Application Security из Positive Technologies Владимир Кочетков рассказывает: что будет, если вообще забить на безопасность; почему от уязвимостей бизнес-логики «никогда в жизни не защитит» даже самый крутой AF; правда ли, что хакеры теперь умнее нас из-за ИИ; как внедрить безопасность, чтобы тебя не возненавидели все разработчики. Слушать → на удобной площадке на YouTube на Яндекс Музыке в Вконтакте

«Хилы, танки и дамагеры DevOps» — каждый понимает DevOps по-своему. В новом выпуске DevOps Deflope узнаете: • Почему DevOps-инженеры сравнивают себя с героями WoW? • Как пайплайны помогают печь круассаны? • Зачем DevOps’у лезть в архитектуру приложений? • Чему учат в магистратуре по DevOps и можно ли его считать методологией? Гость выпуска Константин Дипеж — создатель магистратуры по DevOps, доцент МФТИ и автор канала DeusOps. Слушайте: на удобной площадке на YouTube на Яндекс Музыке в Вконтакте

Книги от Google по SRE весьма полезны, но не у всех есть время прочесывать 1000+ страниц принципов и философии. Автор с Medium, Magsther, решил эту проблему — он прочитал всю трилогию и превратил массив теории в 100 практических уроков. Каждый урок рассчитан на самостоятельное изучение. Есть и про философию, например, “Error budgets are the reliability currency”; и про практические правила — “No SLO? No reliability”. Нет регистрации, рекламы или paywall. Ну круто же :) Тем не менее, делимся и книгами, по которым и сделаны 100 уроков: • Site Reliability Engineering (2016), • The Site Reliability Workbook (2018), • Building Secure & Reliable Systems (2020) Мнение редакции: это не замена книгам, скорее, качественный конспект. Поможет освежить какую-то тему, посмотреть быструю справку и т.д. Он поможет сослаться на SRE by Google без рысканья по книге. Но для обучения этого не хватит, нужно подкреплять практикой и другой теорией.

DevOps Deflope теперь и на Spotify. А все (реально все, даже RSS-фид для олдскульных) другие сервисы найдёте на Mave. Будем рады вашим звёздам, сердечкам и отзывам. Stay tuned!

Помните, Apple представила открытые проекты container и containerization для нативной контейнеризации на macOS? Написано на Swift, оптимизировано для Apple Silicon и вызывает больше вопросов, чем восторга. При чуть более внимательном рассмотрении, оказалось, что Apple снова выбрали свой путь. У них не неймспейсы и общий кернел, а мини-микро-нано-виртуалка под каждый контейнер. И, внимание, нет адекватной сетевой связности между контейнерами, а вдобавок к этому ещё и сложности при работе с оперативной памятью. Вместо привычной модели с shared kernel, Apple создают отдельную ВМ для каждого контейнера через Virtualization.framework. Обещают sub-second startup и hypervisor-level изоляцию, но на практике работает только на Apple Silicon с macOS 26. Экосистемы никакой, ни сompose, ни оркестрации. Оба проекта  находятся в активной разработке. macOS 26 выйдет только в сентябре-октябре, так что сейчас это скорее preview для энтузиастов. Мы так и не смогли понять, зачем нужен эппловский container, если уже есть docker-desktop и lima с привычным докером. Непонятно, будет ли работать в docker/containerd то, что сделано в container. Возможно, это заготовка под будущие задачи Apple в области cloud/edge computing. А может, просто очередной эксперимент, который останется нишевым инструментом для узкого круга задач на macOS.

«Observability никому не нужно»

 — заявил гость нашего очередного выпуска. И ведь правда: компании годами собирают терабайты метрик, но это не помогает им уберечь сервисы от падения в самый неподходящий момент. В этом выпуске Виталий Лихачёв, автор канала «Kubernetes и кот Лихачева», и Евгений Бастрыков, тимлид команды разработки Prom++, разберут: - почему 90 % ваших алертов — мусор; - как eBPF и OpenTelemetry пытаются спасти мир; - можно ли получать метрики из… чего угодно (спойлер: да); - почему «наблюдаемость» — это не про слежку, а про то, чтобы не сойти с ума. И главное: кому вообще нужно это Observability, если Чак Норрис пишет код без багов? Слушать: на удобной площадке YouTube Яндекс Музыка

Традиционные WAF эффективны против классических веб-атак, но плохо справляются с современными угрозами API. Рассмотрим различия между WAF и WAAP подходами к защите. В I квартале 2025 г. количество DDoS-атак на API в России выросло на 74% по сравнению с аналогичным периодом 2024 г. (данные StormWall), а традиционные WAF их попросту не видят. Хакеры больше не ломают двери, они используют правильные ключи в неправильном порядке. Ваш WAF работает как охранник 90-х: проверяет документы по списку «плохих слов», но не понимает, зачем посетитель пришёл. Атакующий делает 1000 валидных запросов к /api/user/profile за секунду? WAF молчит, ведь каждый запрос синтаксически корректен. И атакующий спокойно вытаскивает персональные данные миллионов пользователей через некорректно защищенный эндпойнт. Современные API-атаки выглядят совершенно легально: скрейпинг данных через легитимные GET-запросы в больших объёмах, обход бизнес-логики через неожиданную последовательность API-вызовов, злоупотребление функциональностью через комбинирование разрешённых операций. Все эти атаки возможны потому, что злоумышленники понимают бизнес-логику приложения лучше команды, которая её создала.

Web Application and API Protection не ищет «вредоносные» запросы. Вместо этого он изучает нормальные паттерны каждого API и детектирует аномалии поведения: • ML-анализ в реальном времени. Система знает, что пользователь обычно делает 3-5 запросов в минуту, а не 300 • Контекстное понимание workflow. WAAP видит последовательности вызовов API и выявляет попытки обойти предполагаемые рабочие процессы. • Автоматическое обнаружение API. Мониторинг сетевого трафика находит «теневые» эндпоинты, о которых забыли документировать.

WAAP решает главную болевую точку CI/CD. С ним больше не нужно вручную настраивать правила для каждого нового эндпоинта. Выкатили новую версию API? WAAP автоматически анализирует трафик и настраивает защиту. Есть и бонус для разработчиков. Вместо "security review" на две недели получаете автоматическую защиту с первого деплоя. Команда безопасности видит реальное поведение API, а не гадает на кофейной гуще по коду.

Как начать

• Аудит API-ландшафта. Соберите все эндпоинты в единый каталог с OpenAPI-спецификациями • Стандартизация. Унифицируйте аутентификацию и error handling (WAAP лучше работает с консистентной архитектурой) • Correlation ID. Добавьте во все запросы для отслеживания многоступенчатых атак • Безопасность как код. Внедрите этот подход в API-фреймворки и CI/CD пайплайны

WAF защищал веб-сайты 15 лет назад, но сегодня у вас сотни микросервисов с тысячами API-эндпоинтов. WAF остается актуальным для защиты веб-интерфейсов, но API-инфраструктура требует дополнительных решений. Поэтому WAAP дополняет, а не заменяет существующую защиту, решая специфические задачи API-безопасности. Внедряйте сейчас, пока атакующие не обошли ваши текущие «правила безопасности». В начало поста ←

Чтобы каждая реплика LLM приходила за миллисекунды и не разоряла бюджет на GPU, инфраструктура должна быть столь же умной, как сама модель. Сегодня для этого есть два зрелых Open Source-движка — vLLM и SGLang. Оба уже служат базой для корпоративных продуктов Red Hat и LMSYS, поэтому технологический риск минимален. Ниже — как каждый из них помогает бизнесу экономить и в каких сценариях их применять. Почему это важно прямо сейчас? Стоимость GPU-минут растёт, а объём запросов к моделям увеличивается экспоненциально, что напрямую бьёт по TCO AI-инициатив. vLLM — максимум пропускной способности

• PagedAttention устраняет 60-80% фрагментации памяти через блочные таблицы (как виртуальная память в ОС), давая до ×24 больше throughput, чем Hugging Face Transformers. • Continuous Batching обрабатывает запросы по шагам генерации. Таким образом быстрые не ждут медленных, снижается latency и пропадает простой GPU (〜x23 прирост пропускной способности). • Совместимость с OpenAI API позволяет мигрировать SaaS-сервисы без переписывания клиентского кода. Именно vLLM лежит в основе Red Hat AI Inference Server для OpenShift, так что решение готово к production-кластерам. А ещё LMSYS сократил парк GPU на 50 %, одновременно увеличив число обслуживаемых запросов в 2–3 раза после миграции на vLLM.

SGLang — это экономия на связанных запросах

• RadixAttention строит древовидную структуру для переиспользования KV-кеша между запросами с общими префиксами. Если пользователь ведёт диалог, SGLang автоматически переиспользует уже вычисленные части контекста, ускоряя цепочки вызовов до ×5 и снижая вычислительные затраты. • Строго заданный вывод: можно жёстко задать JSON-схему или грамматику, избегая дорогой поствалидации. • Оптимальный выбор для диалоговых агентов, RAG-конвейеров и других сценариев, где соседние запросы делят контекст и важна точная структура ответа.

Как выбрать Если ваша нагрузка — множество независимых коротких запросов и вы заменяете коммерческий API, ставьте vLLM: он максимально нагружает GPU и обеспечивает низкую задержку. Когда же важны длинные диалоги, строгий формат ответа или повторное использование контекста, применяйте SGLang, который экономит вычисления там, где другие их дублируют. Итого Разверните оба движка в одной инфраструктуре: vLLM — на «горячем» пути API для массовых запросов, SGLang — в сервисах с многошаговыми генерациями. Так вы получите быстрые ответы при минимальной стоимости GPU; именно то, что нужно бизнесу здесь и сейчас.

Пока все увлечённо обсуждают очередные обновления от OpenAI и Anthropic, GitLab неделю назад запустил в публичную бету свою платформу AI-агентов. Вместо очередного чат-бота GitLab создаёт платформу GitLab Duo, где AI-агенты работают как полноценные члены команды. По сути, AI-агент выступает как младший разработчик, который требует проверки от сеньора. Благодаря тому, что GitLab объединяет задачи, код и CI/CD в одной системе, его агенты работают с полным контекстом проекта. Так агенты получают преимущество перед внешними AI-инструментами с их ограниченным контекстом. А ещё можно создавать и подключать собственных агентов под свои задачи и автоматизировать цепочки действий через Flows (например, анализ инцидентов или миграции пайплайнов) Правда, Gitlab Duo Agent Platform доступна только в бете для Premium/Ultimate клиентов gitlab.com и self-managed инсталляций, но документация, API и SDK уже есть в открытом доступе. Направление логично — превратить GitLab из платформы для DevOps в DevOps-платформу с искусственным интеллектом. Какие задачи вы уже делегировали AI-агентам?)

В свежем выпуске подкаста «DevOps Дефлопе» болтаем про пет-проекты: - Любовь Павла к сбору информации и парсинг Steam, а также его бот для конференций. - Зачем Сергей написал приложение под Android и как запускал Quake III на тормозном рабочем компе. - Как Виталий получил опыт деплоя лямбда-функций через Terraform и сделал себе погодную станцию. А ещё вспоминаем рождение NGINX и рассуждаем, зачем вообще нужна работа, за которую не платят. Слушать: на удобной площадке на YouTube

Вышел первый серьёзный отчёт State of GitOps 2025 — исследование 660 команд о том, как GitOps работает в реальности. Главное открытие неутешительное. Большинство команд думают, что делают GitOps, но на самом деле, кажется, просто коммитят скрипты в Git. 60% до сих пор используют императивную конфигурацию вместо декларативной. Отчёт показывает чёткую связь: чем больше практик GitOps внедрила команда, тем выше безопасность, стабильнее конфигурации и проще аудит. Команды, которые используют все шесть практик, показывают лучшие результаты по метрикам DORA. Они чаще деплоят, быстрее доставляют изменения и реже сталкиваются с инцидентами в проде. Интересный момент про медленный code review. Он указан как одна из основных причин, почему команды откатываются к ручным изменениям через kubectl. Ну а это подрывает принципы GitOps, потому что Git перестает быть единственным источником истины. А вы с какими проблемами при использовании GitOps сталкиваетесь?

Как вы уже заметили, мы стали чуть активнее и возродили подкаст. На всякий случай, для тех, кто только к нам присоединился, в паре слов расскажем о том, что происходит в этом канале. Каждый день в мире DevOps появляются тонны новостей, релизов и «революционных» инструментов. При этом, конечно же, в большинстве случаев это информационный шум. Но если мы видим в этом потоке что-то, что с нашей точки зрения, действительно заслуживает внимания, мы приносим это сюда для друзей и коллег. Мы — это инженеры Фланта и Экспресс42, компаний, которые стояли у истоков DevOps в России. Надеемся, что Девопс Дефлопе станет самым полезным девопс-каналом в вашей ленте!

Новый выпуск DevOps Дефлопе — про платформы на Kubernetes Готовые решения экономят время, но ограничивают. Самописные — дают свободу, но требуют ресурсов. Разбираем: - Как не ошибиться с выбором - Как выбрать платформу с минимальными рисками в будущем - Когда пора пересматривать архитектуру Также ведущие делятся реальными кейсами и обсуждают подводные камни. Слушать: на удобной площадке на YouTube

Нашли интересный проект — BLAFS — инструмент для «обезжиривания» Docker-контейнеров, который может сократить их размер на 65-95%. Основная идея простая. Большинство контейнеров содержат кучу файлов, которые никогда не используются. BLAFS отслеживает, какие файлы реально нужны приложению во время работы, и удаляет всё остальное. Процесс из трёх этапов: конвертация файловой системы в формат BLAFS, профилирование с реальными нагрузками и финальное удаление неиспользуемых файлов. Интересно, что подход работает на уровне файловой системы и сохраняет слоистую структуру Docker-образов. Это отличается от других решений вроде SlimToolkit. Пробовали ли вы инструменты для оптимизации размера контейнеров? Какие результаты получали?

«С вами подкаст DevOps Дефлопе» После перерыва разогреваемся на теме AI. В эфире — Никита Борзых и Виталий Хабаров, да не одни, а с новыми ведущими. Ребята расскажут, как ИИ помогает искать ошибки в конфигах и YAML’ах, разбираться с нагрузкой на API-сервер Kubernetes и чинить кластер OpenStack. А ещё порассуждают, какие задачи компании смогут отдать машинам и на какие ИИ-инструменты стоит посмотреть DevOps-инженерам. Слушайте на удобной площадке или на нашем YouTube

Новое исследование Google: 65 % времени разработчиков тратится впустую без платформенного подхода Google и ESG опросили 500 ИТ-специалистов. Коротко о главном в исследовании состояния платформенной инженерии: • 65 % времени разработчиков уходит на задачи, которые может решать внутренняя платформа • 55 % компаний уже поддерживают внедрение platform engineering • Только 27 % полноценно интегрировали платформенный подход во все команды • 84 % компаний признают, что внутренней экспертизы не хватает для эффективного развития платформ Разработчики продолжают тратить бо́льшую часть времени не на продукт, а на инфраструктуру. Platform engineering — ответ на эту историю. Именно здесь DevOps-команды играют ключевую роль, превращают разрозненные процессы в работающую платформу и интегрируют её в максимальное количество команд.