🔥 Почему DevOps-инженеры массово учат MCP

Раньше инженеры спорили о тонкостях Kubernetes, Terraform, CI/CD и облачных архитектур. Теперь в курилках и на созвонах всплывают новые темы, особенно MCP. На первый взгляд это очередная скучная техспека, в которой нет ничего революционного. Но MCP действительно приживается, потому что возникает необходимость связать ИИ с инструментами, сервисами и инфраструктурой, которыми инженеры пользуются каждый день.

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

У всех сейчас огромный пул технологий: системы мониторинга, CI/CD-конвейеры, несколько облачных провайдеров, сканеры безопасности, оркестраторы контейнеров, таск-трекеры и базы знаний. Инфраструктура становится только сложнее. Ее части разбросаны между облаками, контейнерами, вендорскими платформами, базами данных и сторонними API. Держать все это в голове человеку уже невозможно.

С MCP вы ставите задачу агенту, и он сам работает со всеми вашими системами. Например, вы спрашиваете: «Почему вчера подскочила задержка при деплое?». Агент самостоятельно запрашивает метрики, проверяет логи, анализирует историю изменений, находит паттерны и тут же предлагает решение.

Для инфраструктурных команд это означает меньше времени на сидение в логах и больше энергии на решение архитектурных задач.

Инженеры учат MCP не ради хайпа — за этим стоит чистый прагматизм. Это такой же навык, как работа с контейнерами, облаками и CI/CD.

@DevOpsKaz 😛

⚡️ У всех в телеге куча каналов про IT, которые годами висят в архиве непрочитанными.

Чтобы не тратить время на поиск нормальных, их собрали в папку IT-HUB.

Там вы найдете каналы из совершенно разных сфер: от разработки, инфраструктурных решений и архитектуры до менеджмента. Объединяет всех одно: люди пишут сами, про свой опыт, а не репостят чужие статьи ради охватов.

👈 Забрать всю папку в один клик

🔥 Эмулятор Android как сервиса

Если вам нечем заняться в пятницу Если нужна минималистичная среда с полноценным Android-эмулятором, к которому можно подключаться удалённо по сети...

docker-android — решение для CI-ферм, автотестов мобильных приложений и воспроизводимых сред разработки.

Чем полезен:

⚪️ Минимальный образ на Alpine с поддержкой KVM-аппаратного ускорения и Java Runtime Environment 11 на борту
⚪️ Каждый образ тегается под конкретный API level (halimqarroum/docker-android:api-33) — удобно гонять приложение против нескольких версий Android в одном пайплайне
⚪️ Конфигурируется через env как в docker-compose.yml, так и в манифестах Kubernetes, если гоняете ферму в кластере
⚪️ Подходит для своей локальной (или inside-VPC) фермы на bare-metal — KVM требует доступа к /dev/kvm, так что железо или nested virt обязательны
⚪️ Контейнер эфемерный: между прогонами не копится мусор, не остаётся хвостов от прошлых сессий — чистый старт по умолчанию

@DevOpsKaz 😛

🔥 Запускаем наш продукт в бете — OpsMan AI

Первая публичная версия платформы, которая не просто показывает сколько вы тратите на облака и инфраструктуру, но и дает рекомендации по экономии. В цифрах — это до 30% ваших костов.

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

Что уже умеет OpsMan AI:

⚪️ Единый дашборд. Облака (Yandex Cloud, VK), Kubernetes-кластеры — потребление ресурсов, стоимость (USD / ₸ / ₽), рекомендации на одном экране.

⚪️ Анализ затрат. Динамика по дням, разбивка по сервисам и тегам, сравнение месяцев, подсветка текущих и оптимальных затрат — сразу видно потенциал оптимизации.

⚪️ Аномалии и рекомендации. Система сама находит скачки расходов, «зомби-ресурсы», диски без дела и ресурсы без лимитов. По каждой проблеме — конкретная рекомендация с суммой экономии.

⚪️ Группы аллокации. Конкретные ресурсы можно привязать к командам, проектам и отделам. Видно, кто сколько тратит, сколько ожидали и получили в итоге, какой прогноз на период.

⚪️ Бюджеты с алертами. Можно выставить бюджет на месяц/квартал/год и настроить ежедневные алерты при достижении определенного %. Сообщения придут в Telegram или на почту, чтобы избавить вас от неприятных сюрпризов.

⚪️ Отображение ресурсов. Kubernetes, облачные сущности, хосты — все ресурсы отображаются прямо в OpsMan AI.

⚪️ Прогноз расходов. На основе истории получаете план до конца месяца. Будет заранее понятно, уложитесь в бюджет или нет.

❗️ Это бета — и мы активно дорабатываем, добавляем функции и рады обратной связи. Мы даже группу для этого создали — там можно говорить честно и по существу.

Хотите подключить свою инфраструктуру и протестировать? Регистрируйтесь на платформе БЕСПЛАТНО
👈 https://console.opsman.ai/register

@DevOpsKaz 😛

🔥 Конец эры VMware: строим open source private cloud в 2026

VMware после Broadcom заставил многие инфраструктурные команды заново считать TCO, риски вендор-лока и варианты развития частного облака.

В рамках Cloud Native Community Day 13 августа в Алматы мы проведем воркшоп, где и разберем, как перейти от классической виртуализации к cloud native private cloud: с виртуальными машинами, self-service для команд, managed-сервисами, сетями, хранилищем, мониторингом и API-first подходом.

Это не про замену одного продукта другим, а про понимание современной cloud native экосистемы: Kubernetes, KubeVirt, LINSTOR, Cilium, GitOps/API-подходы и платформенная модель управления инфраструктурой.

Cozystack будет использоваться как практический пример интегрированной платформы, на которой можно быстро собрать рабочий private cloud и показать миграционные сценарии руками.

Воркшоп проводит Тимур Тукаев, COO из Aenix (создатели Cozystack).

❗️ Регистрироваться на него нужно отдельно от CNCD.

Воркшоп рассчитан на инженеров уровня middle и выше:

⚪️DevOps / SRE инженеров
⚪️Системных и инфраструктурных инженеров
⚪️Инженеров виртуализации
⚪️Platform engineers
⚪️Технических лидов, которые оценивают альтернативы VMware
⚪️Команды, которые строят private cloud в Казахстане или планируют миграцию с VMware

Что вы получите на воркшопе:

⚪️Практическое понимание, как устроен cloud native private cloud
⚪️Карту соответствий между VMware-компонентами и cloud native стеком
⚪️Опыт миграции VM в KubeVirt-based среду
⚪️Понимание tenant-модели, self-service и managed-сервисов
⚪️Честный список рисков, ограничений и случаев, когда миграция не оправдана
⚪️Доступ к тестовому окружению на 1 месяц после воркшопа
⚪️Возможность выполнить домашнюю лабораторную работу и получить сертификат
⚪️Доступ в чат на 1 месяц после воркшопа для обратной связи по лабораторке и экспериментам

👈 Зарегаться на воркшоп

После воркшопа вы уйдете с ясной и практической картиной: как выглядит современный private cloud на базе cloud native подхода, какие компоненты нужны, где Cozystack помогает собрать их в единую платформу, и какие решения стоит принимать до начала реальной миграции.

@DevOpsKaz 😛

⚡️ Постмортем: как взломали цепочку поставок TanStack через GitHub Actions (OIDC + Cache Poisoning)

11 мая 2026 года злоумышленники за 6 минут опубликовали 84 вредоносные версии 42 npm-пакетов семейства @tanstack/* (популярный набор библиотек для фронтенд-разработки) с легитимной подписью происхождения (SLSA provenance). При этом учетные данные мейнтейнеров не были украдены, а 2FA была включена.

Схема атаки:

⚪️ Pwn Request. Злоумышленник создал PR из форка. Воркфлоу bundle-size.yml использовал триггер pull_request_target. Сам по себе он безопасен (запускает код из ветки main), но внутри был шаг сборки бенчмарков, который явно подтягивал файлы из коммита форка. Это и позволило вредоносному коду выполниться в контексте базового репозитория без одобрения админов.

⚪️ Отравление кэша. Вредоносный скрипт записал отравленный кэш pnpm-store (1.1 ГБ) в общий репозиторий под ключом ветки main. Разграничение прав через permissions не сработало, так как экшен использовал внутренний токен раннера для записи, а не GITHUB_TOKEN. Затем злоумышленник сделал force-push пустышки, скрыв изменения в PR.

⚪️ Кража OIDC-токена из памяти. Когда мейнтейнер сделал штатный пуш в main, запустился легитимный релизный воркфлоу, который восстановил отравленный кэш. Вредоносный код активировался и извлек валидный OIDC-токен прямо из оперативной памяти процесса GitHub Actions Runner, после чего легитимно залил пакеты в npm.

Вредоносный код внедрялся через хук prepare (optionalDependencies) и выполнял:

⚪️ Сбор секретов. Сканировал .npmrc, сессии GitHub/gh CLI, ключи AWS (IMDS/Secrets Manager), GCP, Azure, конфиги Kubernetes, HashiCorp Vault, приватные SSH-ключи, файлы .env и сессии 1Password.

⚪️ Эксфильтрацию. Отправлял данные по HTTPS и скрытым DNS-каналам в сеть Session/Oxen.

⚪️ Червь-эффект. Запрашивал у npm другие пакеты, где скомпрометированный юзер был админом, и пытался заразить и их (пострадали некоторые пакеты Mistral AI, UiPath, Guardrails AI).

Если ваша команда пользуется TanStack:

⚪️Проверить lock-файлы на наличие зараженных версий (полный список в CVE-2026-45321 / GHSA-g7cv-rxg3-hmpx). Если пакеты ставились — считать раннеры/хосты скомпрометированными и провести полную ротацию всех секретов и ключей, к которым они имели доступ.

⚪️Блокировать хуки сборки. В CI/CD использовать флаг --ignore-scripts при установке зависимостей (например, pnpm install --ignore-scripts или npm ci --ignore-scripts).

⚪️Изолировать кэш. Недостаточно просто ограничить OIDC-токен веткой main (ведь атакующие дождались легитимного пуша). Необходимо строго разделять области видимости кэша. Кэш для релизных пайплайнов должен быть полностью изолирован от кэша, доступного для воркфлоу проверки PR (pull_request_target).

В GitHub Actions фиксировать сторонние экшены по SHA-хэшам коммитов, ограничить область действия OIDC конкретными защищенными ветками (refs/heads/main) и жестко изолировать триггер pull_request_target.

@DevOpsKaz 😛

⚡️ 4 причины прийти на вебинар «Переезд в облако без простоев»

1 июля в 19:00 Core 24/7 и Yandex Cloud Kazakhstan расскажут о проблемах миграции и их решении на базе практических кейсов. Рассказываем, почему стоит смотреть:

1️⃣ Информация из первых уст. Это будет не пересказ статей, а практический опыт тех, кто переносил инфраструктуру банков, ритейла, стартапов, госсектора и холдингов. Спикеры — Александр Калинин, COO Core 24/7, и Ренат Бегайдар, Yandex Cloud.

2️⃣ Казахстанские кейсы. Разбираем переезд Biometric, Aurma и Sector Tree.

3️⃣ Бесплатный аудит DevOps по чек-листу. Каждый участник сможет пройти чек-лист DevOps-зрелости и получить рекомендации с первичного аудита инфраструктуры — увидите свои узкие места ещё до переезда.

4️⃣ Грант на миграцию от Yandex Cloud KZ. Участникам — вход в программу бесплатной миграции в Yandex Cloud KZ: грант на потребление облака до 60 дней или бесплатный технический перенос силами сертифицированного партнера Core 24/7.

Формат: онлайн, ~60 минут, бесплатно. Запись будет.

👈 Зарегистрироваться

Приглашайте руководителей, коллег и приходите сами 🫡

@DevOpsKaz 😛

🔥 Как вырастить ML-инфраструктуру от коробки до гигантской платформы

Когда в компании появляется первый Data Scientist, ему обычно хватает одной мощной машинки или DevBox. Но что происходит, когда команда разрастается до сотен и тысяч инженеров, а модели начинают приносить бизнесу миллионы?

Хаос из разрозненных скриптов, проблемы с масштабированием, "зоопарк" технологий и бесконечная головная боль инженеров.

В новой статье на Хабре команда Авито делится своим опытом эволюции ML-платформы. Вы узнаете:

⚪️ С какими граблями сталкивается крупный бизнес при масштабировании ML
⚪️ Как пройти путь от локальной разработки до полноценной MLOps-экосистемы на 1000+ пользователей
⚪️ Как выстроить процессы так, чтобы инфраструктура помогала, а не мешала катить модели в прод

Практический гайд для тимлидов, MLOps-инженеров и всех, кто строит Big Data в больших масштабах.

👈  Читать статью

@DevOpsKaz 😛

🔥 Архитектурный выбор контроллеров в Kubernetes

Оркестрация жизненного цикла подов зависит от правильного выбора контроллера (Workload API). Ошибка на этапе проектирования может привести к нарушению консистентности данных, неэффективной утилизации ресурсов нод или деградации stateful-приложений.

⚪️ Deployment: оркестрация Stateless-нагрузок

Этот контроллер спроектирован для приложений без сохранения состояния, где любой под является эфемерным и взаимозаменяемым.

Поды не имеют постоянного сетевого или дискового состояния. Имена генерируются динамически на основе хэша шаблона и случайной строки.

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

Использование PersistentVolume ограничено. Как правило, все реплики делят один том в режиме ReadWriteMany (например, NFS), либо работают исключительно с ephemeral-хранилищами.

Использование: REST API, микросервисы, фронтенд, stateless-воркеры очередей.

⚪️ StatefulSet: управление Stateful-нагрузками

Для приложений, требующих идентичности, стабильного сетевого имени и персистентного хранилища для каждой отдельной реплики.

Каждый под получает предсказуемый индекс (от 0 до N-1), который сохраняется при пересоздании (db-0, db-1).

Требует обязательного объявления Headless Service. Это позволяет формировать уникальные DNS для каждого пода, что критично для сборки кластерных топологий.

Каждому индексу пода соответствует свой PersistentVolumeClaim (через volumeClaimTemplates). При пересоздании или переносе пода на другую ноду, к нему монтируется его родной том. PVC не удаляются автоматически ни при масштабировании вниз, ни при удалении StatefulSet — это защищает данные от случайной потери. Это поведение можно переопределить полем .spec.persistentVolumeClaimRetentionPolicy с параметрами whenScaled и whenDeleted (Retain/Delete) — полезно, чтобы не копить orphaned-тома и не платить за неиспользуемое хранилище после scale down.

Для развертывания по умолчанию используется политика OrderedReady. Для оптимизации времени деплоя доступна политика Parallel.

Использование: распределенные СУБД, брокеры сообщений, координаторы (etcd, ZooKeeper).

⚪️ DaemonSet: гарантированное покрытие нод

Гарантирует, что экземпляр пода будет запущен на всех (или на строго определенных через nodeSelector / affinity) узлах кластера.

Количество реплик не задается вручную, а динамически масштабируется вместе с размером кластера. При вводе новой ноды под разворачивается на ней автоматически.

Размещение подов DaemonSet делегируется штатному kube-scheduler — через автоматическое добавление NodeAffinity и tolerations к системным taints, а не рассчитывается напрямую контроллером DaemonSet.

Поддерживает RollingUpdate. Параметр maxUnavailable управляет доступностью агентов с самого начала (по умолчанию 1).

Использование: агенты мониторинга и метрик, сборщики логов, системные компоненты сети и проксирования (kube-proxy, CNI-плагины вроде Cilium или Calico).

🎯 Чек-лист для архитектурного выбора

⚪️Deployment: нужна горизонтальная масштабируемость, поды идентичны, состояние хранится во внешних хранилищах (S3, внешняя БД)
⚪️StatefulSet: нужна строгая идентичность подов, кворумные алгоритмы (Raft/Paxos), фиксация сетевых имен и индивидуальные диски для каждой реплики
⚪️DaemonSet: нужна сквозная инфраструктурная обвязка хостов (логи, метрики, безопасность, сеть), которая должна жить на самой ноде независимо от бизнес-логики

@DevOpsKaz 😛