ar
Feedback
KazDevOps

KazDevOps

الذهاب إلى القناة على Telegram

Канал о DevOps во всех проявлениях: K8s, CI/CD, HighLoad, AI/ML, Cloud, Linux Возьмем на поддержку DevOps: https://core247.kz/ По рекламе @UlKonovalova

إظهار المزيد
6 873
المشتركون
-524 ساعات
-337 أيام
+22030 أيام
أرشيف المشاركات
💻 Запись вебинара по миграции без простоев + лучшие условия для вас Core 24/7 и Yandex Cloud провели вебинар, где рассказали
💻 Запись вебинара по миграции без простоев + лучшие условия для вас
Core 24/7 и Yandex Cloud провели вебинар, где рассказали, как мигрировать в облако без серьезного простоя, но и как сделать это бесплатно. Уложились в 40 минут — и теперь можете смотреть в своем темпе, когда удобно. Никакой воды, только концентрированные советы.
👈 Смотреть запись Оставим здесь и наши предложения — БЕЗ ПОДВОХА бесплатные: 1️⃣ Бесплатная миграция в Yandex Cloud Технический перенос инфраструктуры в казахстанский дата-центр по всем канонам лучших практик возьмет на себя Core 24/7, а Yandex Cloud оплатит миграцию вместо вас. Миграция постепенная, с резервными копиями, на основе опыта 50+ переносов инфры казахстанского бизнеса. Подходит, если вы сейчас на своём железе, у хостинг-провайдера или в другом облаке. 👈 Мигрировать бесплатно 2️⃣ Бесплатный аудит зрелости DevOps процессов Пройдите чек-лист и получите оценку зрелости вашей инфраструктуры — узкие места, риски и приоритеты (где проблема, что чинить и улучшать в первую очередь). Первичный аудит готовили Senior инженеры около месяца, и теперь он полностью автоматизирован. Без обязательств получите отчет за 10 минут. 👈 Пройти аудит
❗️ Предложения действуют до 1 августа.
@DevOpsKaz 😛

🔥 Вакансия DevSecOps/AppSec Lead в KASE Ищут специалиста, который поможет выстроить полноценный SSDLC-процесс: от анализа тр
🔥 Вакансия DevSecOps/AppSec Lead в KASE Ищут специалиста, который поможет выстроить полноценный SSDLC-процесс: от анализа требований и архитектуры до автоматизированных проверок безопасности в CI/CD, quality gates, ревью кода и внедрения современных инструментов AppSec. Также в задачи входит формирование AppSec-команды и ее встраивание в процессы разработки, ревью и сопровождения критичных изменений. Основные задачи
• Выстроить процессы SSDLC. • Внедрить SAST и DAST в пайплайн разработки. При необходимости рассмотреть более продвинутые подходы - IAST/RASP. • Внедрить SCA, в том числе с использованием уже приобретенного модуля SonarQube. • Обеспечить настройку инструментов: SonarQube, quality gates и других средств контроля качества и безопасности кода. • Собрать команду AppSec-инженеров и встроить ее в процесс ревью. • Внедрить AppSec-анализ на этапе формирования задач в рамках подхода shift left. • Внедрить локальные LLM-модели в пайплайн разработки на практически применимом уровне.
  Основные требования
• Опыт в AppSec, DevSecOps или Application Security от 3 лет. • Понимание SSDLC и практик безопасной разработки. • Опыт внедрения SAST, SCA, DAST, IAST или аналогичных инструментов. • Практический опыт работы с SonarQube или другим стат анализатором, на уровне написания правил. • Понимание CI/CD-пайплайнов GitLab CI. • Опыт настройки quality gates, security gates и правил анализа кода. • Понимание OWASP Top 10, ASVS, CWE, CVE и CVSS. • Умение разбирать результаты сканеров и отличать реальные риски от false positive. • Опыт взаимодействия с командами разработки. • Умение писать понятные регламенты, чек-листы и инструкции.
  Будет плюсом
• Опыт построения AppSec-команды с нуля. • Опыт работы с локальными LLM: Ollama, vLLM, llama.cpp, Open WebUI, Code LLM, агентные инструменты. • Понимание рисков LLM: prompt injection, утечки данных, supply chain risks, генерация небезопасного кода. • Опыт внедрения RASP/IAST-решений. • Опыт построения метрик AppSec и DevSecOps.
❗️ Отправляйте резюме на почту a.almassova@kase.kz с пометкой в теме DevSecOps или в Telegram @aselya_ao

Repost from Rocket Tech
Финтех становится сложнее: растет число интеграций, появляются новые регуляторные требования, банки внедряют AI и открытые AP
+5
Финтех становится сложнее: растет число интеграций, появляются новые регуляторные требования, банки внедряют AI и открытые API. Вместе с этим меняется и роль DevOps — от поддержки инфраструктуры к обеспечению стабильности цифровых сервисов. Подготовили краткий обзор ключевых трендов, листайте карусель 👉🏻

🔥 Архитектурный выбор контроллеров в Kubernetes Оркестрация жизненного цикла подов зависит от правильного выбора контроллера
🔥 Архитектурный выбор контроллеров в 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 😛

🔥 Как вырастить ML-инфраструктуру от коробки до гигантской платформы Когда в компании появляется первый Data Scientist, ему
🔥 Как вырастить ML-инфраструктуру от коробки до гигантской платформы
Когда в компании появляется первый Data Scientist, ему обычно хватает одной мощной машинки или DevBox. Но что происходит, когда команда разрастается до сотен и тысяч инженеров, а модели начинают приносить бизнесу миллионы?
Хаос из разрозненных скриптов, проблемы с масштабированием, "зоопарк" технологий и бесконечная головная боль инженеров. В новой статье на Хабре команда Авито делится своим опытом эволюции ML-платформы. Вы узнаете: ⚪️ С какими граблями сталкивается крупный бизнес при масштабировании ML ⚪️ Как пройти путь от локальной разработки до полноценной MLOps-экосистемы на 1000+ пользователей ⚪️ Как выстроить процессы так, чтобы инфраструктура помогала, а не мешала катить модели в прод Практический гайд для тимлидов, MLOps-инженеров и всех, кто строит Big Data в больших масштабах. 👈  Читать статью @DevOpsKaz 😛

📅 Станьте спикером на DevOpsDays Almaty 2026 DevOpsDays Almaty состоится 16 октября 2026 — и уже сейчас мы подготавливаем пе
📅 Станьте спикером на DevOpsDays Almaty 2026 DevOpsDays Almaty состоится 16 октября 2026 — и уже сейчас мы подготавливаем первых спикеров к ежегодной масштабной конференции. Встаньте в один ряд с лидерами мнений СНГ и расскажите о своем опыте — с докладом и выступлением мы поможем. 👈 Регистрируйтесь спикером Ждем спикеров, которые готовы рассказать про: ⚪️ Инструменты и платформы ⚪️ Безопасность и DevSecOps ⚪️ Облака и инфраструктуру ⚪️ Практические кейсы ⚪️ Людей, процессы и культуру ⚪️ Новые подходы и будущее DevOps Особенно интересны эксперименты на практике: ⚪️ применение AI и ML в инфраструктуре ⚪️ использование агентов в продакшене (LLM-агенты, auto-remediation, AI-assisted ops) ⚪️ MCP-серверы и их роль в DevOps-пайплайнах ⚪️ predictive autoscaling и адаптивные системы ⚪️ log clustering, noise reduction и интеллектуальный анализ логов ⚪️ автоматизация принятия решений и self-healing системы 👈 Подать доклад

⚡️ 4 причины прийти на вебинар «Переезд в облако без простоев» 1 июля в 19:00 Core 24/7 и Yandex Cloud Kazakhstan расскажут о
⚡️ 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 😛

⚡️ Постмортем: как взломали цепочку поставок TanStack через GitHub Actions (OIDC + Cache Poisoning) 11 мая 2026 года злоумышл
⚡️ Постмортем: как взломали цепочку поставок 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 😛

🔥 Конец эры VMware: строим open source private cloud в 2026 VMware после Broadcom заставил многие инфраструктурные команды з
🔥 Конец эры 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 😛

🔥 Запускаем наш продукт в бете — OpsMan AI Первая публичная версия платформы, которая не просто показывает сколько вы тратит
🔥 Запускаем наш продукт в бете — OpsMan AI Первая публичная версия платформы, которая не просто показывает сколько вы тратите на облака и инфраструктуру, но и дает рекомендации по экономии. В цифрах — это до 30% ваших костов. Подключаете за пару кликов свои сервисы и получаете весь функционал в одном окне. Больше не нужно прыгать между консолями провайдеров и таблицами, а потом долго выяснять как улучшить. Что уже умеет OpsMan AI: ⚪️ Единый дашборд. Облака (Yandex Cloud, VK), Kubernetes-кластеры — потребление ресурсов, стоимость (USD / ₸ / ₽), рекомендации на одном экране. ⚪️ Анализ затрат. Динамика по дням, разбивка по сервисам и тегам, сравнение месяцев, подсветка текущих и оптимальных затрат — сразу видно потенциал оптимизации. ⚪️ Аномалии и рекомендации. Система сама находит скачки расходов, «зомби-ресурсы», диски без дела и ресурсы без лимитов. По каждой проблеме — конкретная рекомендация с суммой экономии. ⚪️ Группы аллокации. Конкретные ресурсы можно привязать к командам, проектам и отделам. Видно, кто сколько тратит, сколько ожидали и получили в итоге, какой прогноз на период. ⚪️ Бюджеты с алертами. Можно выставить бюджет на месяц/квартал/год и настроить ежедневные алерты при достижении определенного %. Сообщения придут в Telegram или на почту, чтобы избавить вас от неприятных сюрпризов. ⚪️ Отображение ресурсов. Kubernetes, облачные сущности, хосты — все ресурсы отображаются прямо в OpsMan AI. ⚪️ Прогноз расходов. На основе истории получаете план до конца месяца. Будет заранее понятно, уложитесь в бюджет или нет. ❗️ Это бета — и мы активно дорабатываем, добавляем функции и рады обратной связи. Мы даже группу для этого создали — там можно говорить честно и по существу.
Хотите подключить свою инфраструктуру и протестировать? Регистрируйтесь на платформе 👈 https://console.opsman.ai/register
@DevOpsKaz 😛

🔥 Эмулятор Android как сервиса Если вам нечем заняться в пятницу Если нужна минималистичная среда с полноценным Android-эмул
🔥 Эмулятор 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 😛

⚡️ У всех в телеге куча каналов про IT, которые годами висят в архиве непрочитанными. Чтобы не тратить время на поиск нормальных, их собрали в папку IT-HUB. Там вы найдете каналы из совершенно разных сфер: от разработки, инфраструктурных решений и архитектуры до менеджмента. Объединяет всех одно: люди пишут сами, про свой опыт, а не репостят чужие статьи ради охватов. 👈 Забрать всю папку в один клик

🎉 Осталось всего 2 дня до DataBoom Birthday! В честь 7-летия DataBoom уже в эту субботу пройдёт ежегодная конференция для вс
+4
🎉 Осталось всего 2 дня до DataBoom Birthday! В честь 7-летия DataBoom уже в эту субботу пройдёт ежегодная конференция для всех, кто связан с данными, IT и аналитикой. Вас ждёт насыщенная программа: выступления топовых спикеров индустрии, панельные сессии с экспертами, менторские часы, ярмарке вакансий от ведущих компаний, розыгрыши призов и подарков и ещё много интересного. Это шанс получить новые знания, завести полезные знакомства, найти работу мечты или менторов, которые помогут вырасти профессионально. Все подробности программы и спикеров — в карусели 👍 Билеты разлетаются быстро, успейте забронировать своё место. 👈 КУПИТЬ БИЛЕТ

🔥 Почему DevOps-инженеры массово учат MCP Раньше инженеры спорили о тонкостях Kubernetes, Terraform, CI/CD и облачных архите
🔥 Почему DevOps-инженеры массово учат MCP
Раньше инженеры спорили о тонкостях Kubernetes, Terraform, CI/CD и облачных архитектур. Теперь в курилках и на созвонах всплывают новые темы, особенно MCP. На первый взгляд это очередная скучная техспека, в которой нет ничего революционного. Но MCP действительно приживается, потому что возникает необходимость связать ИИ с инструментами, сервисами и инфраструктурой, которыми инженеры пользуются каждый день. Раньше, чтобы подключить новый инструмент, инженерам приходилось писать кастомную интеграцию, создавать отдельный коннектор под каждую платформу. В итоге получался хаос: разрозненная экосистема, в которой ИИ «понимал», что нужно сделать, но физически не мог это реализовать.
У всех сейчас огромный пул технологий: системы мониторинга, CI/CD-конвейеры, несколько облачных провайдеров, сканеры безопасности, оркестраторы контейнеров, таск-трекеры и базы знаний. Инфраструктура становится только сложнее. Ее части разбросаны между облаками, контейнерами, вендорскими платформами, базами данных и сторонними API. Держать все это в голове человеку уже невозможно. С MCP вы ставите задачу агенту, и он сам работает со всеми вашими системами. Например, вы спрашиваете: «Почему вчера подскочила задержка при деплое?». Агент самостоятельно запрашивает метрики, проверяет логи, анализирует историю изменений, находит паттерны и тут же предлагает решение. Для инфраструктурных команд это означает меньше времени на сидение в логах и больше энергии на решение архитектурных задач. Инженеры учат MCP не ради хайпа — за этим стоит чистый прагматизм. Это такой же навык, как работа с контейнерами, облаками и CI/CD. @DevOpsKaz 😛

🔥 Подборка инструментов DevOps Новинки, важные апдейты и хорошо забытое старое. ⚪️ Meshery Платформа (CNCF Sandbox) для упра
🔥 Подборка инструментов DevOps Новинки, важные апдейты и хорошо забытое старое. ⚪️ Meshery Платформа (CNCF Sandbox) для управления Kubernetes-инфраструктурой из единого окна. Позволяет контролировать жизненный цикл мультикластерных сред, анализировать производительность с генерацией нагрузки, отслеживать события ресурсов и внедрять GitOps-подход. Это полноценная экосистема для оркестрации, выходящая далеко за рамки обычного UI. ⚪️ Kloak Инструмент безопасности, который перехватывает исходящий TLS-трафик в Kubernetes с помощью eBPF uprobes. Он заменяет хешированные placeholders реальными секретами на уровне ядра прямо перед шифрованием. Приложения не контактируют с учетными данными, а сама схема не требует sidecar-контейнеров или изменений в коде. ⚪️ Isola Open-source проект для безопасного запуска недоверенной AI-нагрузки в Kubernetes. Использует рантайм gVisor для изоляции от ядра хостовой ОС. Управление сэндбоксами и snapshot-файлами реализовано декларативно через Custom Resources, а сетевая изоляция настраивается с помощью классических NetworkPolicy. ⚪️ Патчи уязвимостей в containerd В рантайме containerd закрыты пять опасных уязвимостей. Четыре из них связаны с восстановлением контейнеров из checkpoint-образов (позволяют читать файлы хоста, получать доступ к устройствам и подменять теги). Самая критичная (CVE-2026-53488) позволяет выполнить root-команды на хосте при обычном pull образа из-за отсутствия валидации LABEL. Рекомендуется срочный апдейт до версий 2.3.2, 2.2.5, 2.1.9, 2.0.10 или 1.7.33. @DevOpsKaz 😛

🔥 Agile & Product Excellence Meetup — второй митап нового сезона Halyk Tech Sprints: Level Up Расскажут, как создаются и раз
+5
🔥 Agile & Product Excellence Meetup — второй митап нового сезона Halyk Tech Sprints: Level Up Расскажут, как создаются и развиваются цифровые продукты в крупных компаниях: как проверяются бизнес-идеи, как работают Agile-подходы в реальности, и как команды управляют изменениями и продуктовой эффективностью. ⚪️ Быстрая проверка бизнес-идей и гипотез ⚪️Agile в реальных условиях крупных организаций ⚪️ Управление изменениями и продуктовой разработкой ⚪️ Эффективность команд и вывод продуктов на рынок
Алматы, ТРЦ Forum, зал Event Space 26 июня | 19:00
👈 Участие бесплатное — регистрация тут

🔥 AKASHI Data Center и Core 24/7 подписали меморандум о сотрудничестве в области DevOps, SRE и CloudOps. Партнёрство объедин
+5
🔥 AKASHI Data Center и Core 24/7 подписали меморандум о сотрудничестве в области DevOps, SRE и CloudOps. Партнёрство объединяет инфраструктуру дата-центра уровня Tier IV и экспертизу Core 24/7 в автоматизации, облачных технологиях и обеспечении надёжности цифровых сервисов. Вместе мы создаём основу для надёжной, масштабируемой и автоматизированной цифровой инфраструктуры Казахстана и Центральной Азии. ______ AKASHI Data Center and Core 24/7 have signed a memorandum of cooperation focused on advancing DevOps, SRE, and CloudOps practices. The partnership combines AKASHI’s Tier IV infrastructure with Core 24/7’s expertise in automation, cloud operations, and reliability engineering. Together, we are building a foundation for reliable, scalable, and automated digital infrastructure across Kazakhstan and Central Asia. @DevOpsKaz 😛

🔥 Что сделать, чтобы ИИ-агенты не слили данные в прод Для тех инженеров, чьи разработчики перешли на вайб-кодинг с Cursor, C
🔥 Что сделать, чтобы ИИ-агенты не слили данные в прод
Для тех инженеров, чьи разработчики перешли на вайб-кодинг с Cursor, Claude Code и другими ИИ-агентами: подробный разбор рисков безопасности и практический гайд по защите инфраструктуры. Пока разработчики наслаждаются скоростью генерации кода, привычные контуры безопасности начинают протекать. Традиционный .gitignore больше не спасает от утечек, когда в процесс включаются автономные ИИ-агенты.
👈 Читать на Хабре Кратко о главном: ⚪️ ИИ-агенты и MCP читают файлы до коммита, выводят секреты в логи, отправляют приватные детали базы в публичные тикеты. Статистика GitGuardian 2026 уже фиксирует десятки тысяч уникальных секретов в MCP-файлах. ⚪️ Package hallucination (slopsquatting) — как ИИ выдумывает названия npm/pip-пакетов, а злоумышленники регистрируют их с вредоносным кодом. ⚪️ Риски автономных действий агентов в CI/CD (атаки на GitHub Actions, GhostAction) и уязвимости конфигураций MCP. ⚪️ Автор предлагает конкретные уровни защиты в зависимости от зрелости проекта. Для DevOps-специалистов собран готовый стек утилизации рисков. ⚪️ Готовый инструмент автоматизации ai-repo-safety-skill для быстрого развертывания безопасного окружения (bootstrap репозитория, генерация правил для MCP, добавление проверок безопасности в GitHub Actions). Материал полезен для пересборки пайплайнов безопасности и внедрения превентивных мер (включая составление файлов AGENTS.md и правил для ИИ). @DevOpsKaz 😛

🔥 Как Servercore помогает строить ИИ-инфраструктуру Центральной Азии В Алматы прошел очередной IT-беш от Servercore — мы поб
+4
🔥 Как Servercore помогает строить ИИ-инфраструктуру Центральной Азии В Алматы прошел очередной IT-беш от Servercore — мы побывали на встрече и рассказываем самое важное. Там подняли тему, о которую сейчас спотыкаются 90% корпоративных AI-проектов. Спойлер: они умирают не из-за качества моделей, а из-за косяков в архитектуре инфраструктуры. Основные инсайды для тех, кто катит ML в прод (особенно в финтех и медицину): ⚪️ Почему сторонние API и чужие облака — это боль для Enterprise? Во-первых, регуляторка и закон о персданных (РК/УЗ). Во-вторых, потокенная оплата зарубежным сервисам при масштабировании на миллионную базу превращается в кассовый разрыв. ⚪️ Выход — грамотный Self-Hosted GPU в локальном облаке. Акбар Ермеков (PAfoS AI) разложил по полочкам: если правильно посчитать нагрузку, подобрать модель, заюзать квантование и арендовать локальные GPU-мощности (например, те же NVIDIA A5000 в Servercore в Казахстане), это выходит в разы дешевле, чем закупать собственное «железо» (капекс + риск устаревания) или сидеть на зарубежных API. ⚪️ AI-агенты заменяют бэк-офис. Ребята из LexARE (пишут на Go и Python) собирают уже не просто обертки над LLM, а полноценных ИИ-сотрудников для B2B (юристы, HR, бухгалтеры) со своими базами знаний и интеграцией с 1С/Bitrix. Всё крутится в закрытом контуре, данные никуда не утекают. ⚪️ Голосовые ИИ-агенты поумнели. Время детского сада в духе «нажмите один для связи с оператором» прошло. Голосовые агенты на базе LLM в финтехе теперь ведут нормальный контекстный диалог и реально решают задачи, а не бесят клиентов. ❗️ Главный вывод встречи. Хайп вокруг «просто потестить AI» прошел. Выигрывают те, кто умеет развернуть инфраструктуру под AI в локальной юрисдикции, обеспечить предсказуемую стоимость и встроить модели в реальный прод.
Servercore, как провайдер IT-инфраструктуры, активно работает с финтех-компаниями, предлагая услуги по запуску GPU-серверов и LLM-моделей.
👈 Читать подробнее в статье Кто уже пробовал переносить AI-процессы на локальные GPU-облака? Как полет? Делитесь в комментариях 👇 @DevOpsKaz 😛

🎉 Переезд в облако за счёт Yandex Cloud Мигрировать инфраструктуру дорого и рискованно. Поэтому на вебинаре 1 июля в 19:00 C
🎉 Переезд в облако за счёт Yandex Cloud Мигрировать инфраструктуру дорого и рискованно. Поэтому на вебинаре 1 июля в 19:00 Core 24/7 и Yandex Cloud разберут не только как переехать без серьезного простоя, но и как сделать это бесплатно. Что даёт программа бесплатной миграции в Yandex Cloud KZ: ⚪️ Грант на потребление облака до 60 дней. Переносите силами своей команды — Yandex Cloud покрывает расходы на облако на время пилота, тестирования и переноса. Размер считают индивидуально под ваш план, фиксированного лимита нет. ⚪️ Или бесплатный технический перенос. Нет выделенной cloud-команды? Технический перенос берёт на себя сертифицированный партнёр Core 24/7. Ваша команда не выпадает из текущей работы. ⚪️ Без остановки сервисов. Миграция идёт постепенно, с резервными копиями на текущей платформе. Можно начать с пилота и перенести только часть сервисов. ⚪️ Локально и в тенге. Дата-центр в Казахстане, договор с казахстанским юрлицом, соответствие закону РК о персональных данных. Подходит, если ваша инфраструктура сейчас на своём железе, у хостинг-провайдера или в другом облаке. ❗️Как получить бесплатную миграцию: регистрируетесь на вебинар → на эфире разбираем условия → консультация и расчёт гранта под ваш проект. Формат: онлайн, ~75-90 минут, бесплатно. Запись будет. 👈 Зарегистрироваться Приглашайте руководителей, коллег и приходите сами 🫡 @DevOpsKaz 😛