KazDevOps

Как создавать ИИ-агентов, которым можно доверять   Онлайн-интенсив AI Agents Security Week от Школы анализа данных Yandex (ШАД) раскроет эту тему с 27 по 31 июля. Эксперты Yandex поделятся, с какими угрозами сталкиваются ИИ-агенты и как защитить свои проекты уже на этапе проектирования.   В программе: — Чем ИИ-агенты отличаются от больших языковых моделей — Как защищать системы от взломов, утечек данных, ошибок конфигурации и других угроз — Какие ошибки встречались в ИИ-системах DeepSeek, Microsoft Bing и Amazon Интенсив подойдет тем, кто активно вайбкодит и хочет получать безопасные продукты на выходе. Для старта достаточно знать, как писать промпты и запускать получившийся код. Регистрируйтесь на 5 дней видеотрансляций с возможностью задать вопросы [Зарегистрироваться]

🔥 Пятница безопасности Сегодня в программе: критическое состояние экосистемы MCP-серверов, влияние контейнеризации на ИБ и автоматический мониторинг инфраструктуры на государственном уровне. Только самое важное из мира безопасности. ⚪️ State of MCP Security 2026 Команда Canopii просканировала более 11 000 публично доступных MCP-серверов. Результаты оказались крайне тревожными. Серверы с 1000+ звёзд в 5 раз чаще оказываются в зоне высокого риска (категории D или F). - 232 сервера содержат подтверждённые опасные «синки» (eval, shell-инъекции, десериализация непроверенных данных). - 78% серверов не используют dependency pinning (фиксацию версий зависимостей), что делает их уязвимыми к скрытым обновлениям. - 1617 серверов прямо сейчас поставляются с известными опубликованными уязвимостями (в топе устаревших пакетов — библиотеки JWT и криптографии). - 260 серверов запускают install-скрипты прямо на рабочем месте пользователя ещё до старта самого сервера. - в 31% случаев (24 из 77 серверов, декларирующих авторизацию) эндпоинты отдавали полный список инструментов анонимным пользователям без проверки учётных данных. ⚪️ Запись эфира: «Как развитие контейнеров влияет на информационную безопасность» Специфика безопасности контейнеров тесно связана с эволюцией контейнерных технологий. Ландшафт ИБ меняется, и перед инженерами встают новые вызовы. Несет ли Kubernetes оверхед, насколько он безопасен по умолчанию и нужно ли для безопасности контейнеров отдельное направление в ИБ? На эти и другие вопросы смотрите ответы в записи. Спикеры: – Александр Лысенко, ведущий эксперт по безопасности разработки и ИИ К2 Кибербезопасность; – Дмитрий Евдокимов, основатель и технический директор Luntry. ⚪️ ИБ на уровне страны: опыт польского CSIRT Интереснейший доклад от инженера, как устроен государственный мониторинг безопасности «снаружи». Спикер рассказывает, как они автоматически сканируют всю доступную им инфраструктуру (а иногда и ту, куда их особо не приглашали, ради общего блага). Команда всего из 6 инженеров держит всю систему на понятных и привычных Kubernetes и PostgreSQL. При этом уязвимости они детектируют вагонами, подтверждая эффективность простого и прагматичного подхода. Берегите свои серверы, пиньте зависимости в MCP и отличных безопасных выходных @DevOpsKaz 😛

🔥 Platform Engineering 2.0: как IDPs эволюционируют для AI-native workloads IDP версии 1.0 снижали когнитивную нагрузку на людей, но не проектировались под агентов, которым нужны GPU/TPU, управление жизненным циклом моделей, валидация контекста через MCP и контроль доступа к данным. Если платформа не даёт агентам управляемого доступа к ресурсам, они либо упираются в квоты, либо разъезжаются по shadow-инфраструктуре. В блоге CNCF описали переход от Golden Paths к адаптивным платформам, где AI-агенты становятся first-class citizens наравне с разработчиками. CNCF выделяет пять сдвигов: ⚪️ AI-Native Platform — управление ускорителями и моделями встроено в контрольную плоскость.  ⚪️ Multi-Persona Experience — интерфейсы для ML-инженеров, аналитиков и агентов, а не только для сервисных команд.  ⚪️ Embedded FinOps — стоимость инференса и обучения видна в момент принятия решения, а не в отчёте через месяц.  ⚪️ Security Shifts Down — защита от prompt injection, model poisoning и утечек через inference переезжает в платформенный слой.  ⚪️ Composable by Design — компоненты заменяемы, чтобы успевать за экосистемой. Ключевая мысль в том, что выдержат нагрузку без структурного долга те платформы, которые изначально строились композируемыми. @DevOpsKaz 😛

⚡️ Как построить отказоустойчивую сеть Kubernetes в on-prem На онлайн-лекции 16 июля разберут, как построить надежную и предсказуемую сеть Kubernetes в on-prem кластере. Спикер — Сергей Сперанский, Senior Infrastructure Platform Engineer. Узнаете:  ⚪️ как организовать Kubernetes-сеть с понятной маршрутизацией, BGP и удобным troubleshooting ⚪️ какие инструменты помогают обеспечить отказоустойчивость сети  ⚪️ как кластер реагирует на отказ node, ToR-коммутатора или control plane ⚪️ какие архитектурные решения позволяют создавать практичную Kubernetes-инфраструктуру Когда: 16 июля, 19:00 Формат: онлайн 👈 Зарегистрироваться @DevOpsKaz 😛

🔥 «Под перезапустился!» Фраза, которую на дежурствах произносят по абсолютно разным поводам. Но понимаем ли мы, что произошло на самом деле? Путаница между банальным рестартом процесса в контейнере, полной заменой объекта пода или горячей перезагрузкой конфигов часто приводит к неверным решениям в 2 часа ночи. В новой статье детально разбираем внутренние механизмы Kubernetes и то, как на самом деле принимаются решения о перезапуске. 👈 Читать статью Что внутри: ⚪️Kubelet под микроскопом: почему он следит только за pod spec и игнорирует изменения ConfigMap/Secrets в переменных окружения. ⚪️Магия симлинков: как работает монтирование томов и почему классический inotify часто пропускает обновления конфигурации. ⚪️Фичи K8s 1.35 GA: как работает in-place resize ресурсов без пересоздания пода и смены IP/UID, и почему JVM может тихо проигнорировать добавление памяти. ⚪️ Ловушка Hot-Reload: почему «громкое» падение контейнера при ошибке в конфиге часто безопаснее, чем тихая работа со сломанной логикой на живую. Разбираем теорию на практических схемах и командах для отладки. @DevOpsKaz 😛

⚡️ Cilium Cluster Mesh для объединения Kubernetes-кластеров в разных облаках Приложения в нескольких кластерах развёртывают по нескольким причинам: ⚪️ Запуск реплик в разных зонах доступности, регионах или у разных провайдеров для защиты от глобальных сбоев. ⚪️ Приближение бэкенда к пользователям по всему миру. ⚪️ Изоляция критических сред. В отличие от логической изоляции через Namespaces, разделение по кластерам защищает от сбоев на уровне Control-Plane. ⚪️ Вынос мониторинга или логирования в отдельный служебный кластер, который должны видеть все остальные. Самый очевидный способ связать два сервиса в разных кластерах — выставить сервис в кластере-2 наружу через LoadBalancer и стучаться в него из кластера-1 по внешнему IP. Но есть и минусы: ⚪️ Облачные балансировщики стоят дорого, а в On-Prem средах внешние IP-адреса ограничены. ⚪️ Для удаленного кластера этот трафик выглядит как обычный внешний запрос. Теряются метаданные Kubernetes и сквозная авторизация. Cluster Mesh работает иначе: создает единую виртуальную оверлейную сеть между кластерами. Для приложений это выглядит так, будто они находятся в одной сети с единым пространством имен и идентичностей. Чтобы узнать, как объединить Kubernetes-кластеры в разных облаках через Cluster Mesh на примере Cilium, Amazon EKS (AWS) и Google GKE (GCP), рекомендуем статью. Узнаете про архитектуру сетевого взаимодействия, режимы маршрутизации CNI, посмотрите практический сценарий и сможете реализовать у себя. 👈 Читать статью @DevOpsKaz 😛

🔥 Образовательный дайджест июля ⚪️ Вечерняя школа ИИ для инженеров Слёрм запускает бесплатную серию онлайн-занятий «ИИ для инженеров: польза и риски», где разбирают реальные сценарии: — как ИИ помогает DevOps-, SRE- и infrastructure-командам — как использовать LLM для алёртов, инцидентов, логов, тикетов и документации — где ИИ реально экономит время, а где создаёт новые риски — как проверять результат модели и не ловить галлюцинации в проде — что делать с безопасностью, данными, compliance и юридическими ограничениями — как встроить ИИ в рабочий процесс, а не просто иногда спрашивать у него команды. 👈 Зарегистрироваться в боте ⚪️ Администрирование ОС Linux За 30 минут вы защитите Linux-сервер по пошаговой инструкции: создадите безопасного пользователя, настроите SSH, UFW, fail2ban, автообновления, проверите открытые порты и cron, а также получите рекомендации для дальнейшей безопасной эксплуатации. 👈 Забирайте бесплатную инструкцию «Безопасность Linux-сервера за 30 минут» ⚪️ Автоматизация инфраструктуры с Ansible Не тратьте время на поиск нужных модулей Ansible — держите под рукой шпаргалку с 30 самыми востребованными модулями и готовыми примерами. 👈 Заберите материал и ускорьте создание плейбуков ⚪️ Почему большинство AI-агентов не доходят до продакшена? В новой статье разобрали 5 ключевых проблем — от недетерминированности и контекста до тестирования и мониторинга — с примерами кода и практическим роадмапом внедрения 👈 Читать статью ⚪️ Бесплатный мини-курс по Apache Kafka Понимание архитектуры Kafka — это must-have для IT-специалистов, которые хотят избежать множества ошибок в работе с данными. Курс поможет быстро разобраться с ключевыми понятиями и терминами мира Kafka. Внутри: видеоурок + презентация, глоссарий в PDF-формате с основными терминами, тестирование для проверки себя. 👈 Забрать курс ⚪️ Система распределённых очередей Apache Kafka — набор до 20 июля Научитесь строить отказоустойчивый кластер без тонны документации. Разберётесь, как Kafka работает изнутри, чтобы предотвращать инциденты и держать систему стабильной под нагрузкой 👈 Посмотреть программу @DevOpsKaz 😛

🔥 Спикеры #1 и #2 на Cloud Native Community Day в Алматы Начинаем анонсировать первых спикеров — и показываем, какие доклады уже есть. Перед вами все еще открыта возможность выступить на 100-150 человек, чтобы укрепить личный бренд, завести полезные знакомства и завоевать очки для своей карьеры. ⚪️ Иван Екимов, SUSE: «Как скрыть control plane k8s и что это дает» Традиционно пользователи Kubernetes напрямую взаимодействуют с control plane, что усложняет эксплуатацию кластеров. Скрытие раскрывает возможности Kubernetes as a Service, передав управление инфраструктурой платформенной команде. Managed-платформа должна автоматически создавать, масштабировать, обновлять и сопровождать кластеры на протяжении всего жизненного цикла. Для реализации такого подхода наиболее подходит Cluster API — благодаря декларативной модели управления и поддержке различных инфраструктур. ⚪️ Максат Акбанов, Magnum Cash&Carry: «Защита Kubernetes-кластера с помощью Kubescape» Обзор возможностей DevSecOps-инструмента Kubescape (CNCF) и опыт внедрения в релизные циклы. Узнаете про статический и динамический режимы работы, генерацию отчетов безопасности, интеграцию с ArgoCD, настройку Alertmanager и мониторинг безопасности через Prometheus exporter. Ждем вашей заявки на доклад о реальном опыте. Требования к докладу очень простые. 👈 Подайте заявку как спикер 👈 Зарегистрироваться как участник @DevOpsKaz 😛

💙 Минорный релиз etcd v3.7.0 для Kubernetes Поскольку etcd является критически важным «сердцем» Kubernetes (хранилищем состояния кластера), это обновление напрямую влияет на производительность и стабильность будущих версий. Разбираем самое важное из релиза. 1️⃣ Киллер-фича: RangeStream Раньше, если клиент запрашивал огромный объем данных, etcd полностью собирал весь результат в буфер памяти, а затем отправлял его целиком. Это вызывало непредсказуемые скачки памяти и задержки как на сервере, так и на клиенте. Что изменилось: добавлен метод RangeStream RPC. Теперь большие выборки данных отправляются клиенту частями (чанками/стримом). Это сделает работу тяжелых контроллеров в больших кластерах гораздо более стабильной. 2️⃣ Серьезные улучшения производительности Команда заявляет о заметном снижении потребления CPU процессами etcd по сравнению с версией 3.6. При запросах ключей без их значений (например, etcdctl get --keys-only), etcd теперь читает данные только из своей инкрементальной памяти. Больше нет нужды читать и десериализовать тяжелые значения из дискового хранилища bbolt (за исключением случаев сортировки по значению). Работа с механизмами аренды ключей стала быстрее и надежнее. 3️⃣ Чистка легаси etcd теперь загружается полностью из v3store. Из кодовой базы убрали последние остатки старого движка хранения V2 API, что сильно очистило архитектуру. Завершен масштабный оверхол библиотек Protobuf, устаревшие зависимости заменены на современные и полностью поддерживаемые. 4️⃣ Другие полезные фичи - Поддержка Unix-сокетов - Управление AuthStatus. Теперь можно запрашивать статус аутентификации кластера без предварительной авторизации - Новые метрики для Watch etcd v3.7 принесет долгожданное облегчение для master-нод. Кластеры с огромным количеством объектов станут потреблять меньше процессора, а API-сервер будет тратить меньше памяти. @DevOpsKaz 😛

🔥 Расследование «невидимого» бага от Cloudflare После того как Cloudflare изменила внутреннюю архитектуру сервиса Cloudflare Images (переведя его с сетевых сокетов на локальные Unix-сокеты для ускорения работы), клиенты начали жаловаться, получая битые или недозагруженные картинки. Обычные инструменты логирования на уровне приложения ничего не показывали — для них все выглядело идеально. Попытки воспроизвести баг локально через curl тоже провалились. Команда инженеров искала баг 6 недель, а исправила всего четырьмя строчками кода. Прорыв случился, когда инженеры подключили низкоуровневую утилиту ядра strace, чтобы отследить системные вызовы к сокетам. Оказалось, что при отправке больших файлов процесс делал один системный вызов записи в буфер сокета (sendto), а следующим шагом сразу же закрывал соединение на запись (shutdown), хотя большая часть данных еще оставалась во внутреннем буфере библиотеки. Виновником оказалась hyper — популярная open-source библиотека на Rust для работы с HTTP. Баг сидел в ней годами во множестве версий. В цикле обработки соединений (dispatch.rs) библиотека вызывала функцию сброса данных из буфера в сокет (poll_flush). Однако результат этого вызова просто игнорировался с помощью конструкции let _ = self.poll_flush(cx)?;. Если сокет на стороне получателя на пару миллисекунд заполнялся, функция возвращала статус «ожидания» (Poll::Pending), сообщая, что данные еще не ушли. Но из-за let _ библиотека игнорировала это, считала, что всё успешно отправлено, и преждевременно вызывала закрытие сокета, обрубая хвост файла. 👈 Узнать детали в источнике Когда вы проектируете межсервисное взаимодействие на сверхвысоких скоростях (особенно в K8s через sidecar-контейнеры, mesh-сети или локальные сокеты), всегда закладывайте тесты на переполнение буферов и симулируйте медленных клиентов. @DevOpsKaz 😛