DevOps FM
Ir al canal en Telegram
♾️ Канал для тех, кто живёт слиянием разработки и эксплуатации (DevOps) и сис. администрированием. Новости, статьи, практики, инструменты и развлекательный контент. Cloud Native, Docker, Kubernetes, БД, мониторинг и пр. Алена @alyona2780
Mostrar más5 276
Suscriptores
Sin datos24 horas
-47 días
-1330 días
Carga de datos en curso...
Canales Similares
Nube de Etiquetas
Menciones Entrantes y Salientes
---
---
---
---
---
---
Atraer Suscriptores
septiembre '26
septiembre '26
+20
en 1 canales
agosto '26
+81
en 1 canales
Get PRO
julio '26
+114
en 1 canales
Get PRO
junio '26
+97
en 3 canales
Get PRO
mayo '26
+123
en 2 canales
Get PRO
abril '26
+98
en 1 canales
Get PRO
marzo '26
+108
en 4 canales
Get PRO
febrero '26
+79
en 2 canales
Get PRO
enero '26
+69
en 3 canales
Get PRO
diciembre '25
+76
en 1 canales
Get PRO
noviembre '25
+75
en 1 canales
Get PRO
octubre '25
+84
en 2 canales
Get PRO
septiembre '25
+65
en 0 canales
Get PRO
agosto '25
+86
en 0 canales
Get PRO
julio '25
+94
en 1 canales
Get PRO
junio '25
+78
en 1 canales
Get PRO
mayo '25
+81
en 1 canales
Get PRO
abril '25
+69
en 1 canales
Get PRO
marzo '25
+125
en 2 canales
Get PRO
febrero '25
+102
en 2 canales
Get PRO
enero '25
+144
en 1 canales
Get PRO
diciembre '24
+100
en 1 canales
Get PRO
noviembre '24
+134
en 2 canales
Get PRO
octubre '24
+212
en 2 canales
Get PRO
septiembre '24
+181
en 4 canales
Get PRO
agosto '24
+135
en 0 canales
Get PRO
julio '24
+151
en 1 canales
Get PRO
junio '24
+108
en 2 canales
Get PRO
mayo '24
+175
en 1 canales
Get PRO
abril '24
+138
en 1 canales
Get PRO
marzo '24
+251
en 1 canales
Get PRO
febrero '24
+172
en 2 canales
Get PRO
enero '24
+159
en 1 canales
Get PRO
diciembre '23
+193
en 2 canales
Get PRO
noviembre '23
+293
en 1 canales
Get PRO
octubre '23
+158
en 1 canales
Get PRO
septiembre '23
+168
en 0 canales
Get PRO
agosto '23
+106
en 0 canales
Get PRO
julio '23
+127
en 0 canales
Get PRO
junio '23
+106
en 0 canales
Get PRO
mayo '23
+216
en 0 canales
Get PRO
abril '23
+155
en 0 canales
Get PRO
marzo '23
+156
en 0 canales
Get PRO
febrero '23
+55
en 0 canales
Get PRO
enero '23
+87
en 0 canales
Get PRO
diciembre '22
+71
en 0 canales
Get PRO
noviembre '22
+71
en 0 canales
Get PRO
octubre '22
+180
en 0 canales
Get PRO
septiembre '22
+100
en 0 canales
Get PRO
agosto '22
+137
en 0 canales
Get PRO
julio '22
+175
en 0 canales
Get PRO
junio '22
+143
en 0 canales
Get PRO
mayo '22
+709
en 0 canales
| Fecha | Crecimiento de Suscriptores | Menciones | Canales | |
| 14 septiembre | +1 | |||
| 13 septiembre | 0 | |||
| 12 septiembre | 0 | |||
| 11 septiembre | 0 | |||
| 10 septiembre | +1 | |||
| 09 septiembre | +4 | |||
| 08 septiembre | +2 | |||
| 07 septiembre | 0 | |||
| 06 septiembre | +3 | |||
| 05 septiembre | 0 | |||
| 04 septiembre | +2 | |||
| 03 septiembre | +5 | |||
| 02 septiembre | +2 | |||
| 01 septiembre | 0 |
Publicaciones del Canal
Как дать командам доступ к метрикам Kubernetes и не открыть весь Prometheus?
Всем DevOps!🖖 В прошлом посте мы разбирали, как LegalOn перестраивает платформу для AI-агентов: даёт им нужный контекст и доступ к окружению, но оставляет чёткие границы действий.
В свежем материале CNCF инженеры Adobe разбирают похожую задачу для наблюдаемости: как дать командам самостоятельный доступ к метрикам, не открывая весь общий Prometheus.
В многопользовательском Kubernetes командам нужны собственные запросы и оповещения, но общий Prometheus нельзя открыть всем: его API не изолирует запросы по пространствам имён, а множество произвольных запросов создаёт на него нагрузку.
В Adobe решили проблему через промежуточный слой:
команда → проверка прав → ограничение области данных → Prometheus
Этот слой ограничивает запросы данными своего пространства имён. А нужные метрики при необходимости можно дополнительно отправлять в отдельный Prometheus команды — для графиков и оповещений.
Получается тот же принцип, что и в кейсе LegalOn: самообслуживание без прямого доступа ко всей инфраструктуре.
В кейсе Adobe это помогло найти GPU, который 11 дней был выделен, включен, но не использовался.
Как у вас устроен доступ команд к метрикам: общий Prometheus с изоляцией или отдельный для каждой команды? Делитесь опытом в комментариях💬
| 2 |  Как 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%.
⏺Соединение с реальным окружением
mirrord подключает локальный процесс к удалённому окружению GKE, позволяя работать с его конфигурациями, секретами и зависимостями.
Так появляется быстрый цикл, без необходимости каждый раз проходить полный путь через CI/CD: зменение → проверка → результат → исправление
⏺Изолированная среда
Для PR LegalOn использует Signadot: изменённые сервисы запускаются в отдельном окружении, которое можно использовать для тестов и проверки взаимодействия компонентов.
Но здесь меняется сама роль платформы.
Если раньше Platform Engineering строился вокруг разработчика: разработчик → платформа → инфраструктура
то теперь появляется второй потребитель: разработчик / агент → платформа → инфраструктура
Агенту нужны не только API и инструменты, но и контекст, быстрый цикл проверки и чёткие границы действий.
Задача платформы — сделать изменения проверяемыми для машины, чтобы агент мог самостоятельно доводить их до результата, оставляя человеку контроль над границами и финальным решением.
#DevOps #PlatformEngineering #LegalOn | 596 |
| 3 |  🔔В эфире DevOps FM – срединедельный дайджест новостей!
🔊 NVIDIA договорилась о покупке Hugging Face за $12,93 млрд.
NVIDIA объявила о соглашении по покупке Hugging Face — платформы с open-source и open-weight AI-моделями. После сделки Hugging Face должна сохранить открытый и мультиоблачный подход.
Для NVIDIA это возможность усилить позиции не только в GPU, но и в инфраструктуре для разработки и запуска AI-моделей. Закрытие сделки ожидается в первой половине 2027 года.
Детали сделки можно прочитать в блоге NVIDIA.
🔊 В vm2 нашли критическую уязвимость с обходом sandbox и RCE.
GitLab Threat Research обнаружила уязвимость с максимальным CVSS 10.0 в популярной Node.js-библиотеке vm2. Она позволяет обойти изоляцию и получить полный доступ к хост-системе.
Проблема затрагивает версии 3.11.6 и ниже при включённом require.external. Исправление доступно в 3.11.7.
Подробности читайте в исследовании GitLab.
🔊 Google Cloud пережил четырёхчасовой сетевой сбой.
1 сентября в зоне us-central1-b произошёл серьёзный сбой, затронувший Compute Engine, GKE, Cloud Run, Cloud SQL и другие сервисы.
Причиной стала ошибка во время планового обслуживания: последовательно были отключены все оптоволоконные пути к части инфраструктуры, из-за чего часть VM в зоне потеряла сетевую связность. Сбой продолжался 4 часа 11 минут.
Подробности инцидента — в отчёте Google Cloud.
🔊 Karmada получил статус CNCF Graduated.
Karmada стал первым проектом CNCF для управления несколькими Kubernetes-кластерами, достигшим статуса Graduated.
Платформа позволяет управлять приложениями сразу в нескольких кластерах, облаках и регионах, а в последних версиях развивает механизмы планирования для распределённых AI-нагрузок.
Подробнее — на сайте CNCF.
#новостной_дайджест #devopsfm #karmada #security #cloud | 796 |
| 4 |  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, автоматизация или агент.
По сути, архитектура начинает выглядеть так:
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 | 923 |
| 5 |  🎙️ На волне 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 | 2 354 |
| 6 |  🔔 Друзья, 9 сентября — День тестировщика, и в этот день в Москве пройдет ежегодная конференция, посвященная обеспечению качества и надежности ИТ-систем.
Тема — производительность, отказоустойчивость и все практики, которые позволяют системам выдерживать высокие нагрузки.
Будет особенно интересно инженерам по нагрузочному тестированию, QA-лидам, DevOps и SRE-специалистам.
Можно прийти лично — пообщаться с коллегами, обменяться опытом и узнать много нового из практик и трендов. А если не получается приехать — конференцию можно смотреть онлайн.
📍 Москва, 9 сентября
⌨️ Очно и онлайн
Подробности и регистрация на сайте.
И в канале конференции. | 1 184 |
| 7 |  🔔Новостной дайджест от DevOps FM!
⏺ Вышел релиз Kubernetes 1.37.
В новой версии добавили 67 изменений: 16 функций перешли в Stable, 23 — в Beta, ещё 27 получили статус Alpha.
Среди основных изменений — переход Metrics API в Stable, обновления сетевых компонентов, поддержка Pod Certificates и Cluster Trust Bundles, а также изменения в kube-proxy и cgroup. Релиз также включает обновления и улучшения для безопасности, управления ресурсами и работы кластера.
Подробнее об изменениях Kubernetes рассказали в своем блоге.
⏺Боты создают 98% трафика на git.kernel.org и заставляют ограничивать сервис.
git.kernel.org получает около 6 млн запросов в день, и около 98% из них — боты, которые массово запрашивают страницы отдельных коммитов, создавая постоянную нагрузку на серверы.
На пяти серверах 14–16 из 90 CPU-ядер постоянно заняты обработкой этих запросов, в результате администраторы начали отключать ресурсоёмкие операции, ограничивать анонимный доступ и сокращать количество доступных для обхода ссылок.
Детали читайте в статье.
⏺Amazon завершила покупку DuckLabs, разработчика DuckDB.
Сделка была закрыта 31 августа. Команда DuckDB присоединяется к AWS, при этом проект продолжит развиваться под руководством своих основателей. AWS планирует использовать технологии DuckDB для развития своего аналитического стека.
Подробнее на OpenNET.
⏺Для Debian 11 завершилась официальная LTS-поддержка.
31 августа закончился период LTS для Debian 11 Bullseye. Для части пакетов и архитектур доступна Extended LTS от Freexian — она продлевает поддержку до 2031 года.
Подробнее на OpenNET.
⏺Debian завершил голосование по правилам использования AI.
Ранее мы писали о голосовании Debian по правилам использования генеративного AI. Теперь голосование завершено: проект выбрал вариант Responsible Generative AI Use.
Подробности читайте в статье.
#новостной_дайджест #devopsfm #kubernetes #debian | 1 132 |
| 8 |  🔔27 августа в 16:00 МСК наши партнеры проведут бесплатный вебинар:
«Нагрузочное тестирование на каждый Pull Request: как встроить перф-контроль в CI/CD за 15 минут»
Главный бонус для участников — промокод на скидку на конференцию Перфоманс Конф 12
Вебинар посвящен открытой библиотеке Locomotive (Python, MIT) — инструменту, который встраивает нагрузочное и регрессионное тестирование прямо в CI/CD-пайплайн: тест запускается на каждый Pull Request, результат приходит комментарием к PR, деградация роняет сборку.
На вебинаре обсудят:
⏺почему перф-регресс не ловится в CI;
⏺конфиг вместо кода;
⏺реалистичная нагрузка;
⏺пайплайн из коробки;
⏺как выносится вердикт;
⏺когда меняется контракт API;
⏺результаты и ограничения.
Кому полезно: инженерам по нагрузочному тестированию и performance-инженерам, QA-, DevOps, SRE специалистам, Backend-разработчикам, QA-лидам и руководителям тестирования и другим.
🎙Спикеры — соавторы Locomotive:
Илья Фирсов — выпускник ИТМО, backend-разработчик и DevOps-инженер, 4+ года коммерческой разработки.
Дарья Едигарева — выпускница ИТМО, Python-backend-разработчик, 2 года коммерческой разработки.
27 августа, 16:00 МСК
Бесплатно
Регистрация по ссылке | 148 |
| 9 |  А что, если AI посмотрит ваш Kubernetes?
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, поэтому воспринимать его как готовую замену привычным инструментам мониторинга и диагностики точно не стоит.
👀 А когда такая возможность выйдет из Technology Preview — дали бы вы AI read-only доступ к production-кластеру? Делитесь своим мнением в комментариях 💬
#DevOps #Kubernetes #OpenShift #AI | 1 180 |
| 10 |  Подборка интерактивных тренажеров для DevOps
⌨️ В эту пятницу собрали тренажеры, где можно на практике разбирать нетривиальные сценарии Kubernetes, networking и troubleshooting.
⏺ Deadnodes — тренировка в формате production-инцидента: получаем сломанное окружение, ищем root cause и восстанавливаем систему. Есть сценарии по Linux, Kubernetes, networking и базам данных.
⏺ iximiuz Labs — набор hands-on лабораториий с Linux, контейнерами и Kubernetes. Можно самостоятельно разбирать networking, container internals и troubleshooting-сценарии разной сложности.
⏺ Anycast и BGP — меняем маршруты и отключаем PoP, чтобы посмотреть, что происходит с трафиком и TCP-соединениями. Можно разобрать проблемы с long-lived connections и capacity при отказе части инфраструктуры.
⏺ Kubernetes Scheduler Simulator — практика работы с Filter/Score, resource requests, taints и tolerations. Можно посмотреть, почему Pod оказывается Pending, и сравнить стратегии размещения.
Сохраняйте подборку, чтобы попробовать эти сценарии на практике и проверить свои навыки troubleshooting.
Хорошей практики и приятных выходных! Делитесь своими любимыми тренажерами в комментариях.
#девопс #тренажеры | 1 382 |
| 11 |  Новостной дайджест от 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 | 1 321 |
| 12 |  DevOps через Git: насколько реально управлять всей инфраструктурой и deployment из Git?
Что, если от создания VPC до выката приложения в Kubernetes вообще не заходить в AWS руками? Именно такой сценарий GitLab разбирает в статье — и он хорошо показывает, куда движется современный DevOps.
Если сильно упростить, схема примерно такая:
Git → GitLab CI/CD → OpenTofu → AWS/EKS → Argo CD → приложение
OpenTofu создаёт и изменяет инфраструктуру, GitLab CI/CD управляет процессом и сборкой, а Argo CD следит за состоянием Kubernetes и синхронизирует его с Git.
Вместо привычного сценария:
> Зайди в AWS, поправь вот это.
> Потом сделай kubectl apply.
> А почему staging теперь отличается от production?
Получаем:
> Изменение инфраструктуры — commit.
> Изменение приложения — commit.
> Дальше автоматика сама приводит окружение к нужному состоянию.
И вот это уже интереснее, чем просто очередная связка инструментов.
IaC + CI/CD + GitOps постепенно превращаются в единую декларативную цепочку, где Git становится источником истины не только для кода, но и для окружения.
Плюсы очевидны:
⏺меньше ручных действий;
⏺изменения проходят review;
⏺инфраструктура воспроизводима;
⏺rollback часто превращается в git revert;
⏺окружение можно восстановить из кода.
Но ведь чем больше production мы передаём автоматизации, тем важнее становится надёжность самого control plane.
Отсюда возникают следующие вопросы:
⏺Что делать, если GitLab недоступен?
⏺Как внести emergency change?
⏺Кто имеет break-glass доступ?
⏺Можно ли восстановить инфраструктуру, если недоступны инструменты, которые ей управляют?
И, пожалуй, это один из интересных вопросов современного DevOps — что важнее: полностью исключить ручные изменения или сохранить возможность быстро обойти автоматизацию в аварийной ситуации? Делитесь своим мнением в комментариях💬
Желаем продуктивной недели и спокойных дежурных смен! | 1 475 |
| 13 |  Пятничное чтиво от 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 | 1 472 |
| 14 |  В эфире 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 тг | 1 441 |
| 15 |  KYAML vs YAML: зачем усложнять простое?
YAML давно стал привычным инструментом для DevOps. Но у него есть обратная сторона: неявные типы, зависимость структуры от отступов и множество возможностей, которые Kubernetes на самом деле не использует.
Kubernetes предлагает более строгий подход к конфигурациям — KYAML и описывает его преймущества в своем блоге. Идея в том, чтобы оставить от YAML только то, что действительно нужно Kubernetes, и убрать неоднозначности.
Что получает DevOps?
🟡 меньше зависимости от отступов;
🟡 более предсказуемую работу со строками и типами;
🟡 явное обозначение списков [] и структур {};
🟡 более удобную работу с генерацией, шаблонами и автоматизацией;
🟡 KYAML остаётся валидным YAML и рассчитан на совместимость с существующими YAML-парсерами.
Но есть и другая сторона. Среди обсуждений инженеров можно встретить мнение, что KYAML не избавляет Kubernetes-конфиги от сложности, объясняя это тем, что:
🟡 KYAML не уберёт Helm-шаблоны, огромные манифесты и десятки взаимосвязанных параметров. А значит, вместо решения основной проблемы можно получить ещё один формат, который команде придётся изучать и поддерживать;
🟡YAML уже встроен практически во всю DevOps-экосистему — от IDE и линтеров до CI/CD-инструментов. KYAML — новый подход, а значит, не все инструменты одинаково хорошо его поддерживают.
И здесь возникает главный вопрос:
KYAML действительно решает проблемы YAML — или просто вводит более строгие правила там, где и так всё работало?
👀 А вы бы использовали KYAML в своих проектах, либо же обычного YAML вам вполне хватает? Поделитесь мыслями. | 1 696 |
| 16 | KYAML vs YAML: зачем усложнять простое?
YAML давно стал привычным инструментом для DevOps. Но у него есть обратная сторона: неявные типы, зависимость структуры от отступов и множество возможностей, которые Kubernetes на самом деле не использует.
Kubernetes предлагает более строгий подход к конфигурациям — KYAML и описывает его преймущества в своем блоге. Идея в том, чтобы оставить от YAML только то, что действительно нужно Kubernetes, и убрать неоднозначности.
Что получает DevOps?
🟡 меньше зависимости от отступов;
🟡 более предсказуемую работу со строками и типами;
🟡 явное обозначение списков [] и структур {};
🟡 более удобную работу с генерацией, шаблонами и автоматизацией;
🟡 KYAML остаётся валидным YAML и рассчитан на совместимость с существующими YAML-парсерами.
Но есть и другая сторона. Среди обсуждений инженеров можно встретить мнение, что KYAML не избавляет Kubernetes-конфиги от сложности, объясняя это тем, что:
🟡 KYAML не уберёт Helm-шаблоны, огромные манифесты и десятки взаимосвязанных параметров. А значит, вместо решения основной проблемы можно получить ещё один формат, который команде придётся изучать и поддерживать;
🟡YAML уже встроен практически во всю DevOps-экосистему — от IDE и линтеров до CI/CD-инструментов. KYAML — новый подход, а значит, не все инструменты одинаково хорошо его поддерживают.
И здесь возникает главный вопрос:
KYAML действительно решает проблемы YAML — или просто вводит более строгие правила там, где и так всё работало?
👀 А вы бы использовали KYAML в своих проектах, либо же обычного YAML вам вполне хватает? Поделитесь мыслями. | 1 |
| 17 |  🎙 Что послушать на выходных: 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 | 1 896 |
| 18 |  Новостной дайджест от 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 | 1 761 |
| 19 | Интересно, как проходит ваш сегодняшний День системного администратора? | 1 710 |
| 20 |  🎉 Команда DevOps FM поздравляет с Днём системного администратора!
Забавно, что идеальный рабочий день системного администратора выглядит примерно так:
- мониторинг молчит;
- платформа управления ИТ-инцидентами не звонит;
- бэкапы успешно проходят проверку;
- пользователи не пишут «ничего не менял, оно само».
То есть когда инфраструктура незаметна, именно потому что очень много для этого сделано. Поздравляем всех, кто делает ее такой незаметной 🙌🏼
Желаем всем хороших выходных и спокойных дежурств!
#SysAdminDay | 1 650 |
