Всем DevOps! Сегодня делимся обзором на kubara, фреймворка для построения платформы Kubernetes на GitOps. Артём Лайко в статье портала Medium рассказывает, как kubara помогает платформенным командам уйти от разрозненных Helm-чартов, Terraform-модулей и повторяющихся решений к единой структуре.
В статье kubara представлен как:
• единый бинарник CLI на Go
• фреймворк для платформы Bootstrap
• основа для hub-and-spoke мультикластерной архитектуры
• инструмент, который позволяет поднять рабочую платформу за ~30 минут
Особое внимание уделили формату:
Инструменты, дашборды, операторы и менеджеры (Argo CD, Kyverno, Prometheus, Grafana, Loki, Traefik) собираются в единый цикл GitOps для декларативного управления. С помощью kubara можно строить стек под платформу и требования вашей команды.
Желаем вам вдохновения и ровных Application-синков!
#devops #kubernetes #gitops
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍4❤1🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Модель запустили. А как теперь жить с ней в production?
26 июня в Новосибирске соберёмся на закрытой встрече DevOps Lab: ML in Production: поговорить о том, что происходит после того, как модель попадает в production.
В программе:
🟡 Как AI-агенты помогают DevOps-инженеру справляться с задачами команды из 50 разработчиков.
🟡 Как запускать приватные LLM в Kubernetes: KServe, Modelcar, OCI, оптимизация GPU и ускорение инференса.
🟡 Интерактивный разбор production-инцидентов: масштабирование, наблюдаемость и безопасность ML-сервисов.
Без маркетинга и теории — только практические кейсы, вопросы и обмен опытом.
📍 26 июня, 18:00
📍 Новосибирск, офис Nixys (офлайн)
📍 Количество мест ограничено
Регистрация: [ссылка]
#devops #mlops #kubernetes #sre #nixys
26 июня в Новосибирске соберёмся на закрытой встрече DevOps Lab: ML in Production: поговорить о том, что происходит после того, как модель попадает в production.
В программе:
🟡 Как AI-агенты помогают DevOps-инженеру справляться с задачами команды из 50 разработчиков.
🟡 Как запускать приватные LLM в Kubernetes: KServe, Modelcar, OCI, оптимизация GPU и ускорение инференса.
🟡 Интерактивный разбор production-инцидентов: масштабирование, наблюдаемость и безопасность ML-сервисов.
Без маркетинга и теории — только практические кейсы, вопросы и обмен опытом.
📍 26 июня, 18:00
📍 Новосибирск, офис Nixys (офлайн)
📍 Количество мест ограничено
Регистрация: [ссылка]
#devops #mlops #kubernetes #sre #nixys
3❤6👍6🔥4
Подвели итоги DevOps Lab: как это было
🤩 В прошлую пятницу прошел первый митап серии DevOps Lab: ML in Production. В офисе Никсис собрались инженеры, руководители команд и технические лидеры Новосибирска, чтобы обсудить работу агентов и ML-сервисов в производственной среде.
Спешим поделиться атмосферой обсуждений и споров в кругу своих. И самое важное – говорим спасибо каждому, кто стал частью первого DevOps Lab в Сибири. Надеемся, мы стали местом, где можно открыто обсуждать реальные кейсы, обмениваться опытом и искать решения вместе.
🟡 Совсем скоро выйдем в эфир с записью выступления с разбором рабочей архитектуры приватных LLM на базе Kubernetes.
А пока желаем продуктивной недели без инцидентов :)
#devops #никсис #митап
Спешим поделиться атмосферой обсуждений и споров в кругу своих. И самое важное – говорим спасибо каждому, кто стал частью первого DevOps Lab в Сибири. Надеемся, мы стали местом, где можно открыто обсуждать реальные кейсы, обмениваться опытом и искать решения вместе.
А пока желаем продуктивной недели без инцидентов :)
#devops #никсис #митап
Please open Telegram to view this post
VIEW IN TELEGRAM
3🔥8👍6❤5
👾Ловим покемонов в кластерах
Пятница, конец рабочей недели и Pokémon в Kubernetes. Разработчик Анубхав Саньял вдохновился играми для Game Boy и любовью к DevOps. Так, на свет появился Project Yellow Olive, TUI-симулятор на языке Python. Подробнее об архитектуре – тут.
Вместо покемонов, вам предстоит анализировать работу покеподов, устранять проблемы K8S в локальном кластере Minikube, продвигаясь по аркам:
⏺ Oakwood Meadows с фокусом на подах
⏺ Signal Town с практикой работы с сетью и взаимодействием между компонентами (DNS, Ingress)
⏺ Gold Rush City и упор на политики безопасности (RBAC)
⏺ Sakura Harbour с развертыванием, масштабированием и обновлениями приложений.
Последняя локация появилась недавно, и включает масштабирование реплик, работу с ReplicaSet, сценариями отката (rollback) и отладкой неудачных развёртываний.
Желаем хороших выходных и успешного прохождения!
#DevOps #kubernetes #opensource
Пятница, конец рабочей недели и Pokémon в Kubernetes. Разработчик Анубхав Саньял вдохновился играми для Game Boy и любовью к DevOps. Так, на свет появился Project Yellow Olive, TUI-симулятор на языке Python. Подробнее об архитектуре – тут.
Вместо покемонов, вам предстоит анализировать работу покеподов, устранять проблемы K8S в локальном кластере Minikube, продвигаясь по аркам:
Последняя локация появилась недавно, и включает масштабирование реплик, работу с ReplicaSet, сценариями отката (rollback) и отладкой неудачных развёртываний.
Желаем хороших выходных и успешного прохождения!
#DevOps #kubernetes #opensource
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤7🔥5👍3
Как Codex обнаружил регрессию в Kubernetes
👩💻 Начинаем рабочую неделю с фотоотчёта DevOps Lab и рабочего кейса портала HeyOnCall.
После обновления Kubernetes до версии 1.36 Майк Роббинс заметил проблему на небольшом тестовом кластере.
Проблема возникла из-за небольшого регресса в коде
🔵 В статье о том, как найти утечку памяти в
➡️ А здесь мы оставили фото участников лабы, делимся атмосферой. Отмечайте @DevOps_FM в соц.сетях и расскажите о своих впечатлениях – тут 💙
#kubernetes #devops #kubelet #никсис
После обновления Kubernetes до версии 1.36 Майк Роббинс заметил проблему на небольшом тестовом кластере.
kubelet постепенно «съедал» всю память. Поды работали нормально, но pprof обнаружил миллион объектов контекста. Проблема возникла из-за небольшого регресса в коде
startPodSync, и при каждом цикле синхронизации создавался новый context.WithCancel(), а старый никогда не освобождался. С Codex Роббинс быстро обнаружил проблемный коммит, подготовил исправление, прошёл ревью и добился включения патча в основную ветку и бэкпорта для релиза 1.36.3.kubelet с Go pprof и сократить потребление с 1 ГБ до 110 МБ, почему подобные ошибки сложно поймать на тестировании и какая строка кода может привести к утечке сотен мегабайт памяти на каждой ноде. #kubernetes #devops #kubelet #никсис
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍5❤4🔥4
Новостной дайджест от DevOps FM!
🔔 Выходим в эфир с подборкой новостей и практических разборов.
⏺ В блоге Sysdig опубликовали отчёт по безопасности. В июне среди причин инцидентов выделили ошибки конфигурации, свободный доступ к открытым ресурсам в облаке.
Также в отчёте разобрали атаки от 8 июня на Tchap с кражей 13,5 ГБ данных, и от 11 июня с выводом 1,3 ТБ данных. В первом случае в открытый доступ попали email-адреса и сведения об организациях более 73 тыс. из 600 тыс. учетных записей. Детали отчёта – здесь.
⏺ В понедельник вышел релиз OpenSSH версии 10.4. Из нового добавили экспериментальную поддержку схемы подписи ML-DSA 44 + Ed25519, включили реализацию на основе NFA и ужесточили требования к протоколу SSH при обмене ключами. Усилили безопасность и устранили уязвимости в
⏺ С релизом Docker Desktop 4.81.0 от 6 июля обновили Docker Compose до версии 5.2.0 и Docker Scout CLI v1.22.0. Также внесли исправления для работы с kind-кластерами, улучшили загрузку образов и устранили проблему с остановкой контейнеров. В новой версии Docker Desktop учитывает заданные таймауты вместо принудительного завершения через 1 секунду. Все изменения – здесь.
⏺ На портале FreeCodeCamp вышла статья о включении политик нулевого доверия в Kubernetes. Дестини Эрхабор подробно разбирает идентификацию рабочих нагрузок через SPIFFE, SPIRE и Cilium.
На примере Kind-кластера он показывает, почему традиционные политики безопасности, не работают в динамической среде Kubernetes, а также объясняет, как Cilium реализует аутентификацию (mTLS) без Sidecar. Демо – тут.
⏺ На Info Q Мэтт Сондерс разобрал архитектуру HubSpot и рассказал, как компания масштабировала платформу семантического поиска до 20 млрд векторов.
Внутренняя платформа Vector as a Service (VaaS) работает поверх Qdrant и обеспечивает контроль доступа, версионирование данных и сбор обратной связи. Сейчас система обслуживает 38+ команд, включает 200+ индексов, 140+ кластеров в пяти регионах и двух окружениях, а пиковая нагрузка достигает 100 тыс. запросов в секунду.
Как HubSpot сократил время запуска кластеров с Kubernetes Operator читайте – здесь.
#новостная_подборка #devops #kubernetes #openssh #zerotrust
Также в отчёте разобрали атаки от 8 июня на Tchap с кражей 13,5 ГБ данных, и от 11 июня с выводом 1,3 ТБ данных. В первом случае в открытый доступ попали email-адреса и сведения об организациях более 73 тыс. из 600 тыс. учетных записей. Детали отчёта – здесь.
ssh(1), sshd(8), scp(1) и sftp(1). Подробнее об улучшениях – тут.На примере Kind-кластера он показывает, почему традиционные политики безопасности, не работают в динамической среде Kubernetes, а также объясняет, как Cilium реализует аутентификацию (mTLS) без Sidecar. Демо – тут.
Внутренняя платформа Vector as a Service (VaaS) работает поверх Qdrant и обеспечивает контроль доступа, версионирование данных и сбор обратной связи. Сейчас система обслуживает 38+ команд, включает 200+ индексов, 140+ кластеров в пяти регионах и двух окружениях, а пиковая нагрузка достигает 100 тыс. запросов в секунду.
Как HubSpot сократил время запуска кластеров с Kubernetes Operator читайте – здесь.
#новостная_подборка #devops #kubernetes #openssh #zerotrust
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍5❤3🔥3
Всем DevOps! В конце недели подготовили для вас кейс прямиком из производственной среды.
После выката нового ML-инференс-сервиса в Kubernetes поды один за другим уходят в CrashLoopBackOff. На первый взгляд кажется, что проблема в приложении. Но все ли так очевидно?
STATUS: CrashLoopBackOff
При этом в событиях Kubernetes видно:
Liveness probe failed:
connect: connection refused
А в логах контейнера:
Starting model server...
Loading model weights...
Loaded shard 1/4
Loaded shard 2/4
<SIGTERM received, shutting down>
И фрагмент Deployment:
livenessProbe:
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 3
👨💻Что здесь происходит? Почему сервис так и не успевает запуститься и оказывается в бесконечном CrashLoopBackOff?
Голосуйте в опросе ниже
#devops #kubernetes #k8s #разборинцидента
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥4👍3❤2💅1
10 ошибок в CI/CD, которые замедляют работу инженеров
🔔 В этот солнечный понедельник подготовили для вас подборку ошибок, собранную инженером портала DevOps.
Процессы непрерывной поставки связаны с эффективной работой пайплайнов. По мере роста числа репозиториев и циклов тестирования процессы СI/CD, которые работали на старте проекта, требуют инфраструктурных изменений.
В статье автор собрал 10 типичных ошибок в организации CI/CD. Вы узнаете, почему монолитные пайплайны приводят к росту времени сборок и как неправильная стратегия тестирования зависимостей и окружений влияет на стабильность доставки.
Какие ошибки вы бы добавили в этот список?
#devops #ci_cd #лучшие_практики
Процессы непрерывной поставки связаны с эффективной работой пайплайнов. По мере роста числа репозиториев и циклов тестирования процессы СI/CD, которые работали на старте проекта, требуют инфраструктурных изменений.
В статье автор собрал 10 типичных ошибок в организации CI/CD. Вы узнаете, почему монолитные пайплайны приводят к росту времени сборок и как неправильная стратегия тестирования зависимостей и окружений влияет на стабильность доставки.
Какие ошибки вы бы добавили в этот список?
#devops #ci_cd #лучшие_практики
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤6👍4🔥3
Новостной дайджест от DevOps FM!
⌨️ Делимся свежими новостями, туториалами и разборами инженерных практик.
⏺ Microsoft выкатили патч с рекордным числом исправлений.
Вчера, 14 июля, компания представила релиз с 570 фиксами ОС Windows, обнаруженных искусственным интеллектом. Из них устранили 60 критических уязвимостей, включая CVE-2026-56155, ошибку сервисов активной директории, и CVE-2026-56164, уязвимость Microsoft SharePoint.
⏺ В блоге Kubernetes вышла пошаговая инструкция по созданию собственного экспортера метрик, когда встроенных показателей CPU и памяти недостаточно. В ней разобрали, для каких задач нужен экспортер и как выбрать между Counter, Gauge и Histogram в зависимости от разных сценариев. В конце автор упомянул, как подготовить метрики для использования в
⏺ На Хабре вышло сравнение LLM в производственной среде. На примере использования llama.cpp, Gemma и Qwen в разных сценариях инженеры Wb-Tech решили:
• Перейти с Ollama на llama.cpp, чтобы получить больше контроля над инференсом, настройками, воспроизводимостью и структурированным выводом через GBNF
• Не использовать одну универсальную модель
• Использовать собственные конвееры для стабильных процессов
• Считать веса моделей критической зависимостью и фиксировать версии, хранить копии, не полагаться на внешние репозитории
Больше о бенчмарках и особенностях кейса – в статье.
⏺ Причины низкой производительности GitLab CI разобрал инженер компании OTUS. В статье он приводит 6 основных ошибок в работе: в кэшировании, распределении нагрузки между раннерами, выбором Docker-образов, параллелизацией, сборкой контейнеров и автоскейлингом. А также показывает, в чем измерять эффективность без усложнения инфраструктуры.
⏺ Брайан Грант, СТО ConfigHub, перечислил инструменты по управлению общими настройками рабочих нагрузок в Kubernetes.
Речь идет об автоматизированных проверках и изменениях в контексте безопасности, пробах, запасе количества упавших подов. В статье Брайн описывает подход
#новостная_подборка #devops #kubernetes #llm #gitlab
Вчера, 14 июля, компания представила релиз с 570 фиксами ОС Windows, обнаруженных искусственным интеллектом. Из них устранили 60 критических уязвимостей, включая CVE-2026-56155, ошибку сервисов активной директории, и CVE-2026-56164, уязвимость Microsoft SharePoint.
HorizontalPodAutoscaler через Prometheus Adapter.• Перейти с Ollama на llama.cpp, чтобы получить больше контроля над инференсом, настройками, воспроизводимостью и структурированным выводом через GBNF
• Не использовать одну универсальную модель
• Использовать собственные конвееры для стабильных процессов
• Считать веса моделей критической зависимостью и фиксировать версии, хранить копии, не полагаться на внешние репозитории
Больше о бенчмарках и особенностях кейса – в статье.
Речь идет об автоматизированных проверках и изменениях в контексте безопасности, пробах, запасе количества упавших подов. В статье Брайн описывает подход
Configuration as Data и дает готовые инструменты для анализа состояния кластеров, выявления нарушений. Подробности – на Medium.#новостная_подборка #devops #kubernetes #llm #gitlab
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍4🔥4❤2
В эфире DevOps FM – срединедельный дайджест новостей и статей!
⏺ OpenAI заявили, что GPT-5.6 Sol и предрелизная модели причастны к атаке на Hugging Face от 16 июля.
Атака началась с конвейера обработки данных. Вредонос использовал 2 уязвимости, получил доступ к ноде, проник в несколько внутренних кластеров и завладел учетными данными в облаке.
В статье OpenAI сообщили, что модели работали в экспериментальном режиме для оценки функционала. Всё об инциденте – здесь, прогнозы от OpenAI – тут.
⏺ Всего 1 комментарий в запросе на слияние Azure DevOps может настроить Агента-ревьюера против пользователя.
В MCP-сервере Microsoft обнаружена уязвимость c инъекцией промта через описание запроса на слияние. Команда Manifold Security присвоила ей тип
⏺ На прошлой неделе выкатили релиз GitLab 19.2. В новой версии сосредоточились на автоматизации в бэклоге. Представили бета-функции сканирования и исправления, проверки рабочего цикла.
Теперь ИИ-агенты сканируют содержимое конвеера и открывают запрос на слияние, чтобы устранить уязвимости и ошибки в коде. Также упростили работу в терминале с GitLab Duo CLI и агентами в цепочке (Agentic Flows), которые в версии 19.2 вышли на уровень GA. Подробнее об изменениях – тут.
⏺ 20 июля состоялся релиз стабильной ветки Kata Containers 4.0.0, проекта с открытым исходным кодом от Intel, Hyper и OpenStac. Он отличается безопасностью, защиты от уязвимостей в ядре Linux, сочетает удобство контейнеров с изоляцией виртуальных машин.
В новой версии совершили переход на runtime с языка Go на Rust, включили поддержку гипервизоров Cloud Hypervisor, Firecracker, Dragonball, QEMU и улучшили интеграцию с Kubernetes и Docker. Особенности обновления оставили – здесь, а сравнение Kate Containers с Docker от NorthFlank – тут.
⏺ На Хабре опубликовали заключительную часть из серии статей о защите CI/CD в проектах с открытым кодом. В первой сосредоточились на контроле доступа, разместили конфиги YAML и список улучшений для Cilium. Во второй дали инструкции по укреплению зависимостей, а в свежем переводе речь пошла о защите учётных данных и верификации, изоляции секретов CI.
#devops #инциденты #ии #gitlab #ci_cd
Атака началась с конвейера обработки данных. Вредонос использовал 2 уязвимости, получил доступ к ноде, проник в несколько внутренних кластеров и завладел учетными данными в облаке.
В статье OpenAI сообщили, что модели работали в экспериментальном режиме для оценки функционала. Всё об инциденте – здесь, прогнозы от OpenAI – тут.
В MCP-сервере Microsoft обнаружена уязвимость c инъекцией промта через описание запроса на слияние. Команда Manifold Security присвоила ей тип
confused deputy. Разбор причин и PoC найдете – здесь.Теперь ИИ-агенты сканируют содержимое конвеера и открывают запрос на слияние, чтобы устранить уязвимости и ошибки в коде. Также упростили работу в терминале с GitLab Duo CLI и агентами в цепочке (Agentic Flows), которые в версии 19.2 вышли на уровень GA. Подробнее об изменениях – тут.
В новой версии совершили переход на runtime с языка Go на Rust, включили поддержку гипервизоров Cloud Hypervisor, Firecracker, Dragonball, QEMU и улучшили интеграцию с Kubernetes и Docker. Особенности обновления оставили – здесь, а сравнение Kate Containers с Docker от NorthFlank – тут.
#devops #инциденты #ии #gitlab #ci_cd
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤3🔥3
Как ИИ-агенты снижают нагрузку: кейсы
👨💻 Переход к агентам начинается с осознания, что ИИ – лишь инструмент, а не универсальное решение. Вместо того чтобы держать 10 вкладок Claude Code в браузере, DevOps-инженер Евгений Дехтярёв создал автономную систему на базе оркестратора Paperclip и моделей Claude (Opus/Sonnet).
Ниже мы описали, как агенты справляются с задачами команды из 50 разработчиков и менеджеров.
⏺ Рутина под ключ
На практике агенты отлично справляются с рутиной для оптимизации времени и ресурсов. Так, Claude Code самостоятельно создает техническое задание с соблюдением логики и контекста и по нему выполняет простую инфраструктурную задачу.
За месяц 34 тикета были отданы агентам:
⁃ GitLab CI/ Runners – 7
⁃ Kubernetes – 6
⁃ Storage/S3 – 6
⁃ Базы данных – 6
⁃ VM lifecycle – 4
⁃ Бэкапы. Домены – 4
⁃ Мониторинг (Grafana) – 1
⏺ Разбор алертов
Получив RO доступ к stage- и prod-средам, а также общий контекст системы, SRE-агент запускает разбор ошибок в системе оповещений. После диагностики он ставит гипотезу о первопричине ошибки и сообщает о результатах в тредах Slack-каналов. Так, разработчики сразу видят RCA и могут сразу приступить к внесению изменений.
⏺ FinOps по нескольким облакам
Для оптимизации облачных расходов команда должна держать руку на пульсе и обосновывать каждое техническое решение. Агент-аналитик упрощает ведение отчетности, собирает биллинг по всем провайдерам. С его помощью Евгений обнаружил подключенные мониторинг и логирование от Google. После отказа от сервисов команда сэкономила 400$ ежемесячно.
👀 Подробнее о ролях и задачах агентов, подводных камнях в работе – в записи выступления.
#devops #ai #агенты #кейс
Ниже мы описали, как агенты справляются с задачами команды из 50 разработчиков и менеджеров.
На практике агенты отлично справляются с рутиной для оптимизации времени и ресурсов. Так, Claude Code самостоятельно создает техническое задание с соблюдением логики и контекста и по нему выполняет простую инфраструктурную задачу.
За месяц 34 тикета были отданы агентам:
⁃ GitLab CI/ Runners – 7
⁃ Kubernetes – 6
⁃ Storage/S3 – 6
⁃ Базы данных – 6
⁃ VM lifecycle – 4
⁃ Бэкапы. Домены – 4
⁃ Мониторинг (Grafana) – 1
Получив RO доступ к stage- и prod-средам, а также общий контекст системы, SRE-агент запускает разбор ошибок в системе оповещений. После диагностики он ставит гипотезу о первопричине ошибки и сообщает о результатах в тредах Slack-каналов. Так, разработчики сразу видят RCA и могут сразу приступить к внесению изменений.
Для оптимизации облачных расходов команда должна держать руку на пульсе и обосновывать каждое техническое решение. Агент-аналитик упрощает ведение отчетности, собирает биллинг по всем провайдерам. С его помощью Евгений обнаружил подключенные мониторинг и логирование от Google. После отказа от сервисов команда сэкономила 400$ ежемесячно.
#devops #ai #агенты #кейс
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍6🔥6❤5🤣1
Новостной дайджест от DevOps FM!
🔔 Делимся свежими новостями, релизами и разборами инженерных практик за неделю.
🟡 В блоге Kubernetes вышел предварительный обзор версии 1.37, релиз которой запланирован на конец августа.
Разработчики рассказали о ключевых изменениях, которые планируется включить в релиз: более 20 новых экспериментальных функций, а также улучшения для динамического распределения ресурсов, сетевого стека и управления рабочими нагрузками. Подробнее читайте в обзоре.
⚫️ В том же блоге Kubernetes вышел анонс релиза Gateway API v1.6, в котором ресурсы TCPRoute и UDPRoute перешли в стабильный канал Standard.
Это обновление приносит переносимую и стабильную маршрутизацию трафика на L4-уровне. Детали читайте в официальном обзоре.
🟡 Исследователи Wiz обнаружили критическую цепочку уязвимостей CosmosEscape в Azure Cosmos DB (не без ИИ-помощника). Найденая брешь в API Gremlin позволяла полностью обойти изоляцию облака, получить доступ к внутреннему токену платформы и получить доступ на чтение и запись к базам данных любых клиентов, включая внутренние сервисы Microsoft вроде Teams и Copilot.
Microsoft уже полностью устранила проблему, переработав архитектуру безопасности. Подробный технический разбор читайте в материале The Hacker News.
⚫️ Компания Percona представила Technical Preview сервера для MongoDB 8.3, пропустив промежуточные ветки 8.1 и 8.2.
Сборка объединила улучшения сразу трех минорных релизов, включая новый планировщик запросов Cost-Based Ranker, а также прирост производительности до 195% при массовой вставке временных рядов.
Разработчики подчеркивают, что версия предназначена только для ознакомления — какие архитектурные изменения и новые лимиты памяти ждут СУБД, читайте в официальном блоге Percona.
🟡 В блоге Red Hat вышел технический обзор обновлений OpenShift, посвященный защищенным вычислениям и безопасности ИИ.
Одним из ключевых нововведений стал инструмент Agent Sandbox — изолированная среда на уровне виртуальных машин для безопасного запуска автономных ИИ-агентов и выполнения непроверенного кода.
Также технология конфиденциального ИИ на bare-metal серверах перешла в статус GA. Как новые механизмы защищают веса моделей на уровне процессора и GPU — читайте в обзоре.
⚫️ Исследователи обнаружили компрометацию npm-пакета keyv в рамках масштабной кампании Shai-Hulud (“Дюна”, привет).
Вредоносный код запускался через lifecycle-скрипт preinstall и мог извлекать секреты из окружений разработки и CI/CD-пайплайнов, включая токены облачных сервисов.
Зараженные версии удалены из npm. Проверить затронутые зависимости и индикаторы компрометации можно в техническом разборе Wiz.
#новостная_подборка #devops #kubernetes #security #cloudsecurity #mongodb #openshift #supplychain #npm
🔔 Делимся свежими новостями, релизами и разборами инженерных практик за неделю.
🟡 В блоге Kubernetes вышел предварительный обзор версии 1.37, релиз которой запланирован на конец августа.
Разработчики рассказали о ключевых изменениях, которые планируется включить в релиз: более 20 новых экспериментальных функций, а также улучшения для динамического распределения ресурсов, сетевого стека и управления рабочими нагрузками. Подробнее читайте в обзоре.
⚫️ В том же блоге Kubernetes вышел анонс релиза Gateway API v1.6, в котором ресурсы TCPRoute и UDPRoute перешли в стабильный канал Standard.
Это обновление приносит переносимую и стабильную маршрутизацию трафика на L4-уровне. Детали читайте в официальном обзоре.
🟡 Исследователи Wiz обнаружили критическую цепочку уязвимостей CosmosEscape в Azure Cosmos DB (не без ИИ-помощника). Найденая брешь в API Gremlin позволяла полностью обойти изоляцию облака, получить доступ к внутреннему токену платформы и получить доступ на чтение и запись к базам данных любых клиентов, включая внутренние сервисы Microsoft вроде Teams и Copilot.
Microsoft уже полностью устранила проблему, переработав архитектуру безопасности. Подробный технический разбор читайте в материале The Hacker News.
⚫️ Компания Percona представила Technical Preview сервера для MongoDB 8.3, пропустив промежуточные ветки 8.1 и 8.2.
Сборка объединила улучшения сразу трех минорных релизов, включая новый планировщик запросов Cost-Based Ranker, а также прирост производительности до 195% при массовой вставке временных рядов.
Разработчики подчеркивают, что версия предназначена только для ознакомления — какие архитектурные изменения и новые лимиты памяти ждут СУБД, читайте в официальном блоге Percona.
🟡 В блоге Red Hat вышел технический обзор обновлений OpenShift, посвященный защищенным вычислениям и безопасности ИИ.
Одним из ключевых нововведений стал инструмент Agent Sandbox — изолированная среда на уровне виртуальных машин для безопасного запуска автономных ИИ-агентов и выполнения непроверенного кода.
Также технология конфиденциального ИИ на bare-metal серверах перешла в статус GA. Как новые механизмы защищают веса моделей на уровне процессора и GPU — читайте в обзоре.
⚫️ Исследователи обнаружили компрометацию npm-пакета keyv в рамках масштабной кампании Shai-Hulud (“Дюна”, привет).
Вредоносный код запускался через lifecycle-скрипт preinstall и мог извлекать секреты из окружений разработки и CI/CD-пайплайнов, включая токены облачных сервисов.
Зараженные версии удалены из npm. Проверить затронутые зависимости и индикаторы компрометации можно в техническом разборе Wiz.
#новостная_подборка #devops #kubernetes #security #cloudsecurity #mongodb #openshift #supplychain #npm
2🔥4👍3❤2
🎙 Что послушать на выходных: Kubernetes и энергопотребление
В пятницу делимся свежим выпуском Kubernetes Podcast про Project Kepler — open-source проект для наблюдения за энергопотреблением Kubernetes-нагрузок.
В гостях Ники Маноледаки, Staff Platform Engineer в Grafana Labs и мейнтейнер Project Kepler. Вместе с ведущими она обсуждает, как оценивать энергопотребление рабочих нагрузок, какие метрики для этого можно собирать и почему получить реально точные данные не так просто.
Отдельно поговорили о том, зачем Kepler недавно переписали, как проект использует eBPF и Prometheus и при чём здесь растущие вычислительные нагрузки AI.
🎧 Выпуск «Measuring Sustainability via Project Kepler» послушать можно здесь.
Желаем приятного прослушивания и хороших выходных! А тем, кто дежурит🛡, — спокойных смен 🙌🏼
#подкаст #devops #kubernetes #observability #opensource
В пятницу делимся свежим выпуском Kubernetes Podcast про Project Kepler — open-source проект для наблюдения за энергопотреблением Kubernetes-нагрузок.
В гостях Ники Маноледаки, Staff Platform Engineer в Grafana Labs и мейнтейнер Project Kepler. Вместе с ведущими она обсуждает, как оценивать энергопотребление рабочих нагрузок, какие метрики для этого можно собирать и почему получить реально точные данные не так просто.
Отдельно поговорили о том, зачем Kepler недавно переписали, как проект использует eBPF и Prometheus и при чём здесь растущие вычислительные нагрузки AI.
🎧 Выпуск «Measuring Sustainability via Project Kepler» послушать можно здесь.
Желаем приятного прослушивания и хороших выходных! А тем, кто дежурит🛡, — спокойных смен 🙌🏼
#подкаст #devops #kubernetes #observability #opensource
2🔥5❤2👍2
В эфире DevOps FM – срединедельный дайджест новостей и статей!
⏺ 10 августа Docker выпустил обновление Docker VMM, переведя технологию в статус Public Beta.
Docker VMM — новый уровень виртуализации для Docker Desktop, который сделает работу контейнеров на Mac и Windows быстрее и стабильнее. Среди заявленных улучшений — более быстрый запуск контейнеров, ускоренный файловый I/O и более эффективное управление памятью. Сейчас технология доступна в Docker Desktop 4.86, а финальный релиз по имеющейся информации запланирован на конец октября.
Подробнее о том, что изменилось и как попробовать новый VMM — в блоге Docker.
⏺ После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 7.2.
Новая версия ядра традиционно приносит изменения в подсистемах, драйверах и производительности. Подробности о ключевых обновлениях и список основных изменений — читайте в OpenNET.
⏺ Debian обсуждают использование AI при разработке.
Debian объявили о начале общего голосования разработчиков по вопросу использования больших языковых моделей и AI-инструментов при разработке дистрибутива.
Прием голосов будет осуществляться до 28 августа. Как проходит голосование и какие позиции обсуждаются — читайте в OpenNET.
⏺ GitHub пережил масштабный сбой.
17 августа проблемы затронули сразу несколько ключевых сервисов платформы: Web и API показывали около 20% ошибок, а количество неудачных запросов к архивам и Raw-контенту доходило до 50%. Были затронуты Actions, Pull Requests, Issues, Webhooks, Copilot и другие сервисы.
GitHub постепенно восстановил сервисы. В качестве причины сбоев эксперты предположили сетевые инциденты в Amazon Web Services. Подробнее о масштабах сбоя — в статье.
#новостная_подборка #devops #github #docker #linux #debian
Docker VMM — новый уровень виртуализации для Docker Desktop, который сделает работу контейнеров на Mac и Windows быстрее и стабильнее. Среди заявленных улучшений — более быстрый запуск контейнеров, ускоренный файловый I/O и более эффективное управление памятью. Сейчас технология доступна в Docker Desktop 4.86, а финальный релиз по имеющейся информации запланирован на конец октября.
Подробнее о том, что изменилось и как попробовать новый VMM — в блоге Docker.
Новая версия ядра традиционно приносит изменения в подсистемах, драйверах и производительности. Подробности о ключевых обновлениях и список основных изменений — читайте в OpenNET.
Debian объявили о начале общего голосования разработчиков по вопросу использования больших языковых моделей и AI-инструментов при разработке дистрибутива.
Прием голосов будет осуществляться до 28 августа. Как проходит голосование и какие позиции обсуждаются — читайте в OpenNET.
17 августа проблемы затронули сразу несколько ключевых сервисов платформы: Web и API показывали около 20% ошибок, а количество неудачных запросов к архивам и Raw-контенту доходило до 50%. Были затронуты Actions, Pull Requests, Issues, Webhooks, Copilot и другие сервисы.
GitHub постепенно восстановил сервисы. В качестве причины сбоев эксперты предположили сетевые инциденты в Amazon Web Services. Подробнее о масштабах сбоя — в статье.
#новостная_подборка #devops #github #docker #linux #debian
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤4🔥3👍2
Пятничное чтиво от DevOps FM
📚AI-агенты постепенно заходят в DevOps: получают доступ к коду, инфраструктуре, CI/CD и production. Сегодня читаем о том, как безопасно управлять системами, которые умеют действовать самостоятельно.
⏺ 12 августа Docker представил Agent Baseline — набор практических рекомендаций для безопасного внедрения AI-агентов. В центре внимания — least privilege, наблюдаемость, аудит и возможность остановить агента, а не просто надеяться, что модель будет вести себя правильно. Подробнее читайте в статье.
⏺ CNCF смотрит на проблему с другой стороны: если AI становится частью production, то где проходит граница между ML-командой, DevOps и Platform Engineering? И кто в итоге отвечает за надёжность всей этой системы? Подробнее читайте здесь.
⏺ В разборе кейса Hugging Face хорошо показывает, почему вопрос контроля уже не теоретический. В ходе инцидента исследователи восстановили около 17 600 действий агента, объединённых примерно в 6 280 цепочек.
⏺ GitLab, в свою очередь, показывает, как можно встроить AI-агентов в существующую инфраструктуру с учётом требований безопасности. В новой статье компания рассказывает об AI Gateway для GitLab Dedicated, который позволяет контролировать используемые модели и сохранять AI-обработку внутри выбранного региона. Подробнее читайте в статье.
👀Получается интересный сдвиг: раньше DevOps автоматизировал процессы, а теперь ему предстоит ещё и управлять AI-агентами.
И теперь главный вопрос — какие права мы готовы дать AI и насколько быстро сможем его остановить, если что-то пойдет не так? Пишите свое мнение в комментариях.
Желаем приятного чтения и хороших выходных!
#пятничноечтиво #devops #ai
📚AI-агенты постепенно заходят в DevOps: получают доступ к коду, инфраструктуре, CI/CD и production. Сегодня читаем о том, как безопасно управлять системами, которые умеют действовать самостоятельно.
👀Получается интересный сдвиг: раньше DevOps автоматизировал процессы, а теперь ему предстоит ещё и управлять AI-агентами.
И теперь главный вопрос — какие права мы готовы дать AI и насколько быстро сможем его остановить, если что-то пойдет не так? Пишите свое мнение в комментариях.
Желаем приятного чтения и хороших выходных!
#пятничноечтиво #devops #ai
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤6👍3🔥1
Новостной дайджест от DevOps FM!
⌨️ Делимся свежими новостями и релизами за прошедшую неделю.
⏺ Kubeflow получил статус CNCF Graduated.
Kubeflow получил высший статус зрелости в CNCF. Проект объединяет инструменты для построения AI/ML-платформ на Kubernetes — от подготовки данных и обучения моделей до inference.
Для DevOps это ещё один сигнал: Kubernetes всё активнее становится инфраструктурой для AI — от обучения моделей до inference и serving. Детали читайте в статье.
⏺ AWS продолжает развивать Argo CD в EKS.
В понедельник мы разбирали сценарий, где Git становится control plane для инфраструктуры и deployment. Теперь AWS расширяет возможности настройки управляемой Argo CD Capability в EKS — в частности, добавляет поддержку кастомных health checks и параметров сравнения ресурсов.
Похоже, AWS постепенно углубляет интеграцию GitOps с EKS, беря на себя всё больше операционных задач по управлению Argo CD. Подробнее — в блоге AWS.
⏺ IncidentRelay 2.0 — новый релиз self-hosted incident management.
Open-source проект для управления дежурствами, маршрутизации алертов и incident response получил новый major-релиз.
IncidentRelay ориентирован на SRE и DevOps-команды, которым нужна self-hosted альтернатива облачным платформам управления инцидентами.
Подробности о ключевых обновлениях и список основных изменений — читайте в OpenNET.
⏺ GitHub опубликовал разбор масштабного сбоя 17 августа.
Напомним, тогда GitHub был недоступен или работал с ошибками почти 8 часов. Теперь компания раскрыла детали: проблема с autoscaling Istio sidecar-подов привела к перегрузке сети и каскаду отказов.
Ситуацию дополнительно усугубили агрессивные retry: нагрузка на отдельные сервисы выросла многократно.
Получился отличный пример того, как ошибка в автоматическом масштабировании + retry storm могут превратить локальную проблему в большой outage.
Подробнее — в разборе GitHub.
#devops #инциденты #gitlab #kubeflow
Kubeflow получил высший статус зрелости в CNCF. Проект объединяет инструменты для построения AI/ML-платформ на Kubernetes — от подготовки данных и обучения моделей до inference.
Для DevOps это ещё один сигнал: Kubernetes всё активнее становится инфраструктурой для AI — от обучения моделей до inference и serving. Детали читайте в статье.
В понедельник мы разбирали сценарий, где Git становится control plane для инфраструктуры и deployment. Теперь AWS расширяет возможности настройки управляемой Argo CD Capability в EKS — в частности, добавляет поддержку кастомных health checks и параметров сравнения ресурсов.
Похоже, AWS постепенно углубляет интеграцию GitOps с EKS, беря на себя всё больше операционных задач по управлению Argo CD. Подробнее — в блоге AWS.
Open-source проект для управления дежурствами, маршрутизации алертов и incident response получил новый major-релиз.
IncidentRelay ориентирован на SRE и DevOps-команды, которым нужна self-hosted альтернатива облачным платформам управления инцидентами.
Подробности о ключевых обновлениях и список основных изменений — читайте в OpenNET.
Напомним, тогда GitHub был недоступен или работал с ошибками почти 8 часов. Теперь компания раскрыла детали: проблема с autoscaling Istio sidecar-подов привела к перегрузке сети и каскаду отказов.
Ситуацию дополнительно усугубили агрессивные retry: нагрузка на отдельные сервисы выросла многократно.
Получился отличный пример того, как ошибка в автоматическом масштабировании + retry storm могут превратить локальную проблему в большой outage.
Подробнее — в разборе GitHub.
#devops #инциденты #gitlab #kubeflow
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍4❤3🔥2
А что, если AI посмотрит ваш Kubernetes?
AI-помощники для Kubernetes — уже далеко не новость.
Но становится интереснее, когда AI работает прямо в OpenShift Console и при включённом Cluster Interaction может получать актуальный контекст работающего кластера.
Red Hat в своем блоге показывает 5 сценариев для OpenShift Lightspeed — AI-помощника, который помогает работать с OpenShift и Kubernetes.
Собрали самое интересное 👇
1. Спросить вместо поиска по документации
Например:
Lightspeed использует официальную документацию Red Hat и учитывает версии OpenShift и Lightspeed в вашем окружении.
2. Сгенерировать YAML
Можно попросить AI подготовить конфигурацию:
Или:
Получаем черновик манифеста, который дальше, конечно, нужно проверить перед применением.
3. Разобраться с проблемой
Здесь уже можно использовать AI не только для генерации конфигурации, но и для troubleshooting.
Например:
Lightspeed может анализировать проблему и проводить через диагностические шаги, помогая понять, куда смотреть дальше.
4. Разобраться с виртуализацией
Для OpenShift Virtualization можно задавать вопросы вроде:
Удобный вариант, чтобы разобраться с Kubernetes-based virtualization и сопоставить её с уже знакомыми подходами.
5. А теперь самое интересное — live-кластер
При включённом Cluster Interaction Lightspeed может получать актуальный контекст активного кластера через OpenShift API.
Например:
То есть вопрос можно сформулировать не только как: «Как сделать X в OpenShift? Но и как: «Что сейчас происходит с моим кластером?»
Сам сценарий AI-assisted troubleshooting для Kubernetes уже существует. Интерес Lightspeed — в его интеграции с OpenShift и доступе к контексту работающего кластера.
При этом Cluster Interaction сейчас имеет статус Technology Preview, поэтому воспринимать его как готовую замену привычным инструментам мониторинга и диагностики точно не стоит.
👀 А когда такая возможность выйдет из Technology Preview — дали бы вы AI read-only доступ к production-кластеру? Делитесь своим мнением в комментариях 💬
#DevOps #Kubernetes #OpenShift #AI
AI-помощники для Kubernetes — уже далеко не новость.
Но становится интереснее, когда AI работает прямо в OpenShift Console и при включённом Cluster Interaction может получать актуальный контекст работающего кластера.
Red Hat в своем блоге показывает 5 сценариев для OpenShift Lightspeed — AI-помощника, который помогает работать с OpenShift и Kubernetes.
Собрали самое интересное 👇
1. Спросить вместо поиска по документации
Например:
How do I configure a custom ingress controller?
What are the prerequisite network requirements for setting up an OpenShift cluster?
Lightspeed использует официальную документацию Red Hat и учитывает версии OpenShift и Lightspeed в вашем окружении.
2. Сгенерировать YAML
Можно попросить AI подготовить конфигурацию:
Generate a YAML file for a deployment running a basic NGINX server with 3 replicas.
Или:
Create a NetworkPolicy that limits traffic to pods in the production namespace.
Получаем черновик манифеста, который дальше, конечно, нужно проверить перед применением.
3. Разобраться с проблемой
Здесь уже можно использовать AI не только для генерации конфигурации, но и для troubleshooting.
Например:
Why is my application pod stuck in ImagePullBackOff?
I am getting a CrashLoopBackOff error on my frontend pod. What is happening there?
Lightspeed может анализировать проблему и проводить через диагностические шаги, помогая понять, куда смотреть дальше.
4. Разобраться с виртуализацией
Для OpenShift Virtualization можно задавать вопросы вроде:
Is there a storage vMotion equivalent?
How do I import a VMware virtual machine into OpenShift Virtualization?
Удобный вариант, чтобы разобраться с Kubernetes-based virtualization и сопоставить её с уже знакомыми подходами.
5. А теперь самое интересное — live-кластер
При включённом Cluster Interaction Lightspeed может получать актуальный контекст активного кластера через OpenShift API.
Например:
Show me all degraded pods running in the payment-processing namespace.
Are there any active security alerts or failed deployments on my cluster right now?
То есть вопрос можно сформулировать не только как: «Как сделать X в OpenShift? Но и как: «Что сейчас происходит с моим кластером?»
Сам сценарий AI-assisted troubleshooting для Kubernetes уже существует. Интерес Lightspeed — в его интеграции с OpenShift и доступе к контексту работающего кластера.
При этом Cluster Interaction сейчас имеет статус Technology Preview, поэтому воспринимать его как готовую замену привычным инструментам мониторинга и диагностики точно не стоит.
#DevOps #Kubernetes #OpenShift #AI
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤4👍4🔥3🤣1
🎙️ На волне DevOps FM!
Пятница — отличный повод немного отвлечься от рабочих задач и послушать что-нибудь интересное.
В прошлых подборках нас просили больше русскоязычного контента, поэтому собрали три выпуска, которые стоит добавить в список для прослушивания.
🗣 DevOps в 2026: Platform Engineering, AI-агенты и будущее джунов от DevOps Kitchen Talks. Что происходит, когда у вас уже 600 сервисов и 3600 пайплайнов? Обсуждают internal platform, её архитектуру и self-service-возможности для разработчиков, а также границы ответственности platform team. Отдельный фокус — AI-агенты и multi-agent workflows: что происходит, когда автоматизация начинает работать уже не только с инфраструктурой, но и непосредственно с engineering-процессами.
🗣 Kubernetes 2035: кто будет управлять инфраструктурой? от «В SREду на кухне» / AvitoTech. GitOps, Crossplane, автоматизация Kubernetes и развитие абстракций над инфраструктурой. Интересный вопрос выпуска — сколько деталей инфраструктуры разработчику действительно нужно видеть и какие операции со временем можно передать платформе и автоматизации.
🗣 Инфраструктура & MLOps от [I'ML]. Здесь уже про инфраструктуру для ML и AI-систем. Обсуждают ML Platform, Data Platform, вывод моделей в production и особенности эксплуатации AI workloads. Хороший выпуск, чтобы посмотреть, какие привычные DevOps-подходы приходится адаптировать для AI.
Желаем приятного прослушивания и дежурств без алертов!🛡
#пятничная_подборка #подкаст #DevOps #PlatformEngineering #AIEngineering
Пятница — отличный повод немного отвлечься от рабочих задач и послушать что-нибудь интересное.
В прошлых подборках нас просили больше русскоязычного контента, поэтому собрали три выпуска, которые стоит добавить в список для прослушивания.
Желаем приятного прослушивания и дежурств без алертов!
#пятничная_подборка #подкаст #DevOps #PlatformEngineering #AIEngineering
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤4👍4🔥3
Platform Engineering 2.0: как меняется роль внутренней платформы
Kubernetes, Terraform, GitOps, CI/CD, Backstage — классический стек Platform Engineering уже хорошо знаком.
Но что происходит с этой моделью, когда появляются AI-нагрузки и новые способы взаимодействия с инфраструктурой?
В материале CNCF автор предлагает рассматривать это как следующий этап — Platform Engineering 2.0.
При этом фундамент не меняется: Platform as a Product, удобство для разработчиков, готовые пути, самообслуживание и безопасность на ранних этапах остаются актуальными. Меняется масштаб задач платформы и круг её пользователей.
Что добавляется:
⏺ AI становится ещё одним типом нагрузки
Платформе теперь приходится учитывать GPU/TPU, запуск и обслуживание моделей, обработку запросов, жизненный цикл моделей, MCP-шлюзы и специальные механизмы защиты.
То есть AI — это не отдельный слой где-то рядом с платформой. Для platform team это ещё один класс нагрузки со своими требованиями к ресурсам, безопасности и управлению.
⏺ Пользователей становится больше
Помимо разработчиков и platform engineers, с платформой работают ML-инженеры, специалисты по данным, команды безопасности и соответствия требованиям, FinOps — и постепенно AI-агенты.
Отсюда практический вопрос: можно ли пользоваться платформой программно?
Интерфейс и Backstage отлично подходят человеку. Но автоматизации и агентам нужны интерфейсы через API: ресурсы, действия, права доступа и ограничения.
⏺ FinOps перемещается ближе к созданию ресурсов
Стоимость становится частью решения ещё до развёртывания.
Например: сколько будет стоить новая нагрузка, какой ресурс выбрать и можно ли вообще её создавать с учётом текущего бюджета и правил.
⏺ Безопасность уходит глубже в платформу
Меньше ручных проверок после развёртывания — больше политик и контроля непосредственно на уровне платформы и среды выполнения.
Для AI добавляются свои риски: неконтролируемое использование AI, prompt injection, отравление моделей, утечки данных при обработке запросов.
⏺ Платформа становится модульной
Отдельные возможности должны быть доступны через API и собираться в разные сценарии: интерфейс, CLI, CI/CD, автоматизация или агент.
По сути, архитектура начинает выглядеть так:
И здесь важно: Kubernetes, Terraform, GitOps, Backstage никуда не исчезают. Меняется слой над ними — платформа начинает решать задачи, которые раньше находились за пределами классического самообслуживания разработчиков.
В итоге из концепции Platform Engineering 2.0 можно сделать вполне практичную вещь — ревизию собственной платформы.
Спросить себя:
→ Можем ли мы быстро выдать специализированный ресурс?
→ Можем ли мы сделать это через API?
→ Знаем ли стоимость до развёртывания?
→ Можем ли мы применять политики на уровне платформы?
→ Может ли автоматизация или агент работать с платформой без человека?
Если где-то ответ «нет» — вот там и находится следующая задача для platform team⌨️
#DevOps #Platformengineering
Kubernetes, Terraform, GitOps, CI/CD, Backstage — классический стек Platform Engineering уже хорошо знаком.
Но что происходит с этой моделью, когда появляются AI-нагрузки и новые способы взаимодействия с инфраструктурой?
В материале CNCF автор предлагает рассматривать это как следующий этап — Platform Engineering 2.0.
При этом фундамент не меняется: Platform as a Product, удобство для разработчиков, готовые пути, самообслуживание и безопасность на ранних этапах остаются актуальными. Меняется масштаб задач платформы и круг её пользователей.
Что добавляется:
Платформе теперь приходится учитывать GPU/TPU, запуск и обслуживание моделей, обработку запросов, жизненный цикл моделей, MCP-шлюзы и специальные механизмы защиты.
То есть AI — это не отдельный слой где-то рядом с платформой. Для platform team это ещё один класс нагрузки со своими требованиями к ресурсам, безопасности и управлению.
Помимо разработчиков и platform engineers, с платформой работают ML-инженеры, специалисты по данным, команды безопасности и соответствия требованиям, FinOps — и постепенно AI-агенты.
Отсюда практический вопрос: можно ли пользоваться платформой программно?
Интерфейс и Backstage отлично подходят человеку. Но автоматизации и агентам нужны интерфейсы через API: ресурсы, действия, права доступа и ограничения.
Стоимость становится частью решения ещё до развёртывания.
Например: сколько будет стоить новая нагрузка, какой ресурс выбрать и можно ли вообще её создавать с учётом текущего бюджета и правил.
Меньше ручных проверок после развёртывания — больше политик и контроля непосредственно на уровне платформы и среды выполнения.
Для AI добавляются свои риски: неконтролируемое использование AI, prompt injection, отравление моделей, утечки данных при обработке запросов.
Отдельные возможности должны быть доступны через API и собираться в разные сценарии: интерфейс, CLI, CI/CD, автоматизация или агент.
По сути, архитектура начинает выглядеть так:
Developer / ML Engineer / Agent↓Platform APIs↓Identity / Policy / Cost↓Kubernetes / Cloud / GPU / AIИ здесь важно: Kubernetes, Terraform, GitOps, Backstage никуда не исчезают. Меняется слой над ними — платформа начинает решать задачи, которые раньше находились за пределами классического самообслуживания разработчиков.
В итоге из концепции Platform Engineering 2.0 можно сделать вполне практичную вещь — ревизию собственной платформы.
Спросить себя:
→ Можем ли мы быстро выдать специализированный ресурс?
→ Можем ли мы сделать это через API?
→ Знаем ли стоимость до развёртывания?
→ Можем ли мы применять политики на уровне платформы?
→ Может ли автоматизация или агент работать с платформой без человека?
Если где-то ответ «нет» — вот там и находится следующая задача для platform team
#DevOps #Platformengineering
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤6🔥4👍3
Как LegalOn адаптирует Platform Engineering под AI-агентов ⌨️
Продолжаем тему Platform Engineering — сегодня разбираем кейс LegalOn Technologies от Signadot. LegalOn Technologies от Signadot.
У LegalOn около 200 инженеров, GKE, Argo CD и собственная платформа Akupara. С появлением AI-агентов узким местом всё чаще становится уже не создание кода, а его проверка и доставка.
Архитектуру они разделили на три части:
⏺ Контекст
Каталог продуктов в YAML используется как источник данных для Terraform и агентов. На основе Terraform HCL и Kubernetes-конфигураций они строят граф знаний, доступный через MCP.
По данным LegalOn, это снизило потребление токенов примерно на 25%.
⏺ Соединение с реальным окружением
Так появляется быстрый цикл, без необходимости каждый раз проходить полный путь через CI/CD: зменение → проверка → результат → исправление
⏺ Изолированная среда
Для PR LegalOn использует Signadot: изменённые сервисы запускаются в отдельном окружении, которое можно использовать для тестов и проверки взаимодействия компонентов.
Но здесь меняется сама роль платформы.
Если раньше Platform Engineering строился вокруг разработчика: разработчик → платформа → инфраструктура
то теперь появляется второй потребитель: разработчик / агент → платформа → инфраструктура
Агенту нужны не только API и инструменты, но и контекст, быстрый цикл проверки и чёткие границы действий.
Задача платформы — сделать изменения проверяемыми для машины, чтобы агент мог самостоятельно доводить их до результата, оставляя человеку контроль над границами и финальным решением.
#DevOps #PlatformEngineering #LegalOn
Продолжаем тему Platform Engineering — сегодня разбираем кейс LegalOn Technologies от Signadot. LegalOn Technologies от Signadot.
У LegalOn около 200 инженеров, GKE, Argo CD и собственная платформа Akupara. С появлением AI-агентов узким местом всё чаще становится уже не создание кода, а его проверка и доставка.
Архитектуру они разделили на три части:
Каталог продуктов в YAML используется как источник данных для Terraform и агентов. На основе Terraform HCL и Kubernetes-конфигураций они строят граф знаний, доступный через MCP.
По данным LegalOn, это снизило потребление токенов примерно на 25%.
mirrord подключает локальный процесс к удалённому окружению GKE, позволяя работать с его конфигурациями, секретами и зависимостями.Так появляется быстрый цикл, без необходимости каждый раз проходить полный путь через CI/CD: зменение → проверка → результат → исправление
Для PR LegalOn использует Signadot: изменённые сервисы запускаются в отдельном окружении, которое можно использовать для тестов и проверки взаимодействия компонентов.
Но здесь меняется сама роль платформы.
Если раньше Platform Engineering строился вокруг разработчика: разработчик → платформа → инфраструктура
то теперь появляется второй потребитель: разработчик / агент → платформа → инфраструктура
Агенту нужны не только API и инструменты, но и контекст, быстрый цикл проверки и чёткие границы действий.
Задача платформы — сделать изменения проверяемыми для машины, чтобы агент мог самостоятельно доводить их до результата, оставляя человеку контроль над границами и финальным решением.
#DevOps #PlatformEngineering #LegalOn
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍6❤4🔥4