KazDevOps

⚡️ Бесплатный офлайн-воркшоп KZ Data Community в Алматы — 27 августа Спикеры: ⚪️ Екатерина Рехерт — «Ваш ИИ несёт чушь? Основы промпт-инжиниринга и Microsoft Copilot» ⚪️ Михаил Пасечный — «Не просто чат-бот: как Copilot и Claude встраиваются в data-workflow» 📅 27 августа, 19:00 Офис Beeline, пересечение Тимирязева × Ауэзова Количество мест ограничено. 👉 Регистрируйтесь по ССЫЛКЕ

⚡️ От обычных гейтов в CI/CD к Agentic CI/CD с MCP

Классический цикл «Build-Push-Deploy» прост только на бумаге. В реальности мы регулярно упираемся в проблему: пайплайн отработал идеально, тесты прошли, артефакт собран… и релиз улетает в кластер, который прямо сейчас находится под высокой нагрузкой (Memory pressure, CPU throttling или риски OOM).

Обычно эту проблему решают написанием громоздких bash/python-скриптов или запросов к API Prometheus, которые проверяют Deployment Gates. Но эти скрипты жесткие, хрупкие и требуют постоянного обслуживания. На смену им приходит Agentic CI/CD — подход, где роль гейткипера перед деплоем выполняет AI-агент, взаимодействующий с инфраструктурой через Model Context Protocol (MCP). Как это работает на практике? Вместо выполнения захардкоженного скрипта GitHub Actions обращается к Elastic MCP Server и запрашивает статус кластера на понятном языке. ⚪️Сбор метрик: OpenTelemetry Collector непрерывно собирает данные о состоянии Kubernetes-кластера. ⚪️AI-агент: в Elastic создается специализированный Observability Kubernetes Agent с системными инструкциями и кастомными ES|QL-инструментами для анализа ресурсов. ⚪️Запрос из CI/CD: GitHub Actions через MCP-протокол отправляет агенту промпт:

«Скажи, использует ли кластер otel-test более 25% CPU или памяти на любом из узлов?»

⚪️Принятие решения: агент запрашивает метрики, находит просадку, форматирует понятный отчет и отдаёт статус. Если кластер нестабилен — пайплайн автоматически падаёт до этапа синхронизации в ArgoCD/Flux. Зачем это нужно? ⚪️ Вы не тратите ресурсы на выкатку релиза в падающий или перегруженный кластер. ⚪️ Агент может учитывать сразу комплекс факторов (метрики, активные алерты, динамические пороги), а не просто сверять одну статичную цифру. ⚪️ В логах CI/CD остается не безымянный exit code 1, а человекочитаемый разбор от агента с указанием конкретной ноды и метрик. @DevOpsKaz 😛

🔥 Сервисы на Rust Автор объясняет, почему Rust — отличный выбор для средних по размеру backend-сервисов, несмотря на меньшую "продуктивность" по сравнению с Go. В Rust богатая система типов, проверки компилятора и zero-cost-абстракции избавляют от багов бизнес-логики. В статье разбирается HTTP-стек Rust с tokio, hyper, axum для сервера, reqwest для клиента и tracing для наблюдаемости. Автор предлагает классическую трехуровневую архитектуру кода - HTTP/worker-слой, слой сервисов с бизнес-логикой и "тупой" repository-слой для работы с БД, где каждый слой общается только с соседним. Автор также накидывает про фоновые задачи через очередь, крон-задачи, кэширование на уровне сервисов. В целом, у Rust уже достаточно богатый стек для продакшен разработки. Поддержать проект на boosty и читать в MAX

💛 Разбираем htop на запчасти Кажется, что htop — простейшая утилита линукс. Но заглядывали ли вы к ней под капот? 👈 В статье htop explained автор не просто дает шпаргалку по хоткеям, а наглядно показывает устройство Linux через призму мониторинга, подкрепляя всё командами strace и чтением псевдофайловой системы /proc. ⚪️ Load Average: почему 1.00 на 1-ядерном процессоре — это не всегда 100% CPU, и при чём тут диск (I/O). ⚪️ Память без путаницы: разница между VIRT (виртуальная), RES (физическая) и SHR (расшаренная). Как не паниковать при виде огромного VIRT. ⚪️ Статусы процессов: что скрывается за буквами R, S, D, Z и почему процесс в статусе D (uninterruptible sleep) нельзя завершить даже через kill -9. ⚪️ Полезные хоткеи: как через Shift+H (скрыть потоки), Shift+K (скрыть треды ядра) и F5 (дерево процессов) превратить хаос на экране в понятную структуру. ⚪️ Магия /proc и strace: как сам htop собирает метрики прямо из ядра. @DevOpsKaz 😛

🎓 Бесплатно обучитесь аналитике данных с нуля и сделайте первый шаг в IT! Успейте подать заявку на грант TechOrda на обучение в DataBoom. ❗️Вся подробная информация в карусели. Оставляйте заявку по ссылке: https://astanahub.com/ru/techorda/course/844/ На все вопросы ответим в комментариях 🫶

27 августа приглашаем вас на Halyk Tech Sprints: Level Up — Cybersecurity & Antifraud Meetup 🚀 Поговорим о киберугрозах, Red Team, антифроде и современных подходах к защите банковских сервисов. Будут реальные кейсы и практический опыт экспертов Halyk. 📍 Алматы, ТРЦ Forum, Event Space 📅 27 августа | 🕖 19:00 А ещё вас ждут интересные доклады, кофе-брейк, мерч и возможность пообщаться с участниками и спикерами. 🎟 Участие бесплатное — регистрация

🎓 Приглашаем на официальные тренинги Zabbix на русском языке (ближайший уже через пару недель) При выборе обучения многие обращают внимание на программу курса и опыт преподавателя, но есть еще один фактор, который остается с вами надолго после окончания курса — официальный сертификат Zabbix. Компания Gals Software является официальным тренинг-партнером Zabbix, поэтому после успешного прохождения обучения и сдачи экзамена слушатели получают официальный сертификат от Zabbix. Почему это важно? ✅ Сертификат выдает сам разработчик Zabbix, а не учебный центр. ✅ Он подтверждает, что ваши знания соответствуют требованиям вендора. ✅ Его признают компании по всему миру при поиске специалистов по мониторингу. ✅ Для работодателя это простой способ убедиться, что кандидат действительно владеет Zabbix, а не только работал с ним. Для инженера это: ✅ дополнительное преимущество при трудоустройстве; ✅ подтверждение своей квалификации; ✅ возможность выделиться среди других специалистов; ✅ официальный статус, который ценится на рынке. Мы регулярно проводим официальные курсы: 📌 Zabbix Certified Specialist (программа) 7-11 сентября 2026 📌 Zabbix Certified Professional (программа) 28-30 октября 2026 📌 Zabbix Certified Expert (программа) 16-20 ноября 2026 Обучение проходит по официальной программе Zabbix с использованием материалов вендора, а занятия проводят сертифицированные инструкторы Gals Software. Если вы хотите не просто изучить Zabbix, а получить международно признанное подтверждение своих знаний, будем рады видеть вас на наших курсах. 📅 Полное расписание тренингов 📩 Напишите нам на hello@gals.software или @galssoftware, и мы расскажем подробнее.

⚡️ Почему сложно найти DevOps-инженеров Пост для тех, кто нанимает в команду.

Если попросить 10 компаний описать идеального DevOps-инженера, почти наверняка получится 10 разных вакансий. При этом все компании используют одно и то же название вакансии. Именно поэтому у работодателя и кандидата разные ожидания. Вакансии часто продолжают описывать стек, который формировался несколько лет назад, в результате чего появляются требования, отражающие не текущие задачи бизнеса, а список вообще всех инструментов. Для кандидатов это выглядит как попытка найти универсального специалиста, который одинаково хорошо знает все существующие инструменты.

Можно знать Terraform, Kubernetes, Prometheus, Grafana и десятки других решений, но если инженер не сталкивался с отказоустойчивостью, масштабированием, авариями или эксплуатацией высоконагруженных систем, этого опыта может оказаться недостаточно для конкретного проекта. Инженеры обычно принимают решение о новом месте работы не только исходя из условий, большое значение имеет понимание самого проекта. ⚪️ Какая инфраструктура уже существует? ⚪️ Какие задачи предстоит решать? ⚪️ Насколько зрелые процессы в компании? ⚪️ Есть ли возможность влиять на архитектуру? Именно поэтому техническое интервью становится не просто этапом оценки кандидата. Оно превращается в обсуждение того, насколько ожидания обеих сторон совпадают. Успешный поиск DevOps-инженеров редко строится вокруг длинного списка технологий. Гораздо лучше работают другие подходы: ⚪️ Четкое описание текущей инфры и проекта ⚪️ Разделение обязательных и желательных требований ⚪️ Понимание реальных задач на повестке ⚪️ Готовность обсуждать развитие роли инженера А если компания не может понятно объяснить, с чем предстоит работать, вероятность отказа заметно возрастает. Это звучит очевидно, но далеко не все действительно ставят себя на место соискателя. @DevOpsKaz 😛

Реклама поверх экрана: где проходит граница операторского маркетинга На iPhone приходит «Важное сообщение оператора». Телефон просит разблокировать экран, чтобы его прочитать. Кажется, что речь идет о сети, SIM-карте или чем-то действительно срочном. Но после разблокировки Kcell предлагает подключить New Happy Bonus, участвовать в Perfect 10 и платить за услугу 90 тенге в день. Это не обычное SMS и не push из приложения Kcell. Судя по тому, как сообщение отображается на устройстве, речь идет о механике класса SIM Toolkit push — такой формат часто называют DSTK-push, или Dynamic SIM Toolkit push. SIM-карта может передать телефону команду показать сообщение через системный интерфейс. Именно эта особенность делает такой канал привлекательным для маркетинга: сообщение сложно не заметить. Зачем вообще существует такой формат SIM Toolkit появился задолго до современных операторских приложений и позволяет SIM-карте взаимодействовать с телефоном: показывать сервисные меню, подтверждать действия, запускать услуги и передавать абоненту информацию. Со временем эту возможность начали использовать и для маркетинга. На рынке есть готовые решения для операторов, позволяющие отправлять рекламу через SIM Toolkit. Например, A1 Systems предлагает A1S Flash именно как инструмент для маркетинговых коммуникаций. То есть сама идея продавать услуги таким способом не уникальна для Казахстана и не является изобретением Kcell. Вопрос в другом: стоит ли использовать техническую возможность привлечь повышенное внимание пользователя только потому, что она существует? Где здесь проблема У оператора достаточно способов рассказать о новой услуге: SMS, приложение, обычные push-уведомления, личный кабинет, баннеры. Большинством из них пользователь может управлять: push отключить, SMS не открывать, баннер закрыть. С системным сообщением ситуация выглядит иначе. Сама формулировка «Важное сообщение оператора» может быть частью интерфейса iOS, а не текстом Kcell. Но вопрос остается: насколько этично использовать для рекламы канал, которому устройство дает такой высокий приоритет? В результате коммерческое предложение получает внимание, которого обычная реклама, скорее всего, не получила бы. Важное — значит важное Через смартфон мы получаем не только рекламу, но и банковские предупреждения, уведомления о безопасности и экстренные оповещения. Здесь важно не смешивать технологии. Например, казахстанская Mass Alert использует Cell Broadcast — это не DSTK-push. Но пользователю необязательно знать, по какому протоколу пришло сообщение. Он видит главное: телефон требует обратить внимание на что-то важное. И у такого приоритета есть ограниченный ресурс — доверие. Если человек разблокирует телефон ради «важного сообщения», а внутри оказывается акция, это доверие постепенно расходуется. Где должна проходить граница Сам по себе DSTK-push не плохой инструмент. Такой канал оправдан, когда сообщение действительно требует повышенного внимания: проблема с SIM-картой, изменение условий связи, роуминг, риск неожиданных расходов или другая важная информация от оператора. Но продажа платной услуги — другая категория коммуникации. Чем сложнее рекламу проигнорировать, тем ценнее канал для бизнеса. Но эффективность механики сама по себе не отвечает на вопрос, стоит ли ее использовать. У операторов есть преимущество перед большинством других брендов: благодаря SIM-карте у них есть прямой доступ к системным возможностям телефона. А значит, появляется и ответственность за то, как этим доступом распоряжаться. Если сегодня «важным сообщением оператора» оказывается предложение платить 90 тенге в день, завтра абонент может перестать считать сообщения оператора важными. Получается тот самый мальчик, который слишком часто кричал «волки». Только в этот раз волки стоят 90 тенге в день. Подписывайтесь на bailanys — независимый канал о связи и телекоме в Казахстане

🔥 Новости мира DevOps, которые вы могли пропустить ⚪️ Rancher v2.15.0 — платформа для управления несколькими Kubernetes-кластерами Общедоступные (GA) провайдеры CAPI-инфраструктуры, наследование правил пространства имён для GlobalRoles, ограничения локальной аутентификации в UI при настройке EAP, новый быстрый интерфейс Workloads Overview и поддержка Kubernetes v1.36. ⚪️ Karpenter v1.14.0 — высокопроизводительный автоскалер узлов Kubernetes Аллокатор для Dynamic Resource Allocation (DRA), поддержка секционируемых устройств в DRA, стратегия консолидации Balanced, переопределение ресурсов на уровне офферингов и поддержка CapacityBuffer API. ⚪️ Cilium 1.20.0 — сетевой плагин CNI и инструмент безопасности на базе eBPF Поддержка TCPRoute/UDPRoute в Gateway API, шифрование трафика между шлюзом и сервисами, миграция на multi-pool IPAM, учет топологии (PreferSameZone/PreferSameNode), стабильный MCS API, ClusterNetworkPolicy из апстрима K8s и уменьшенный в 4 раза бинарник cilium-cni. ⚪️ Cozystack v1.6.0 — PaaS-платформа для построения собственных облаков Переезд воркеров K8s с Ubuntu/kubeadm на Talos Linux, иерархические квоты ресурсов, переход etcd на etcd-operator v1alpha2, новый файрвол SecurityGroup для тенантов и улучшения в Keycloak. ⚪️ KServe v0.20.0 — платформа для инференса и развёртывания AI-моделей Управляемый DRA для LLMInferenceService, конфиденциальное обслуживание моделей, поддержка AutoGluon, несколько OCI-источников в storageUris, разделение трафика через API и канареечные релизы в режиме RawDeployment. ⚪️ wasmCloud v2.7.0 — среда выполнения WebAssembly-нагрузок в облаке Параллельные экземпляры в пуле, доверенные приватные CA-корни для OCI-реестров за TLS, включенные по умолчанию maps/implements и единое ограничение соединений. @DevOpsKaz 😛

А вот и официальная причина инцидента GitHub: ​

Непосредственной причиной сбоя стало перенасыщение сетевого трафика на балансировщиках нагрузки в регионе Central US из-за нового пика активности. ​Первоисточником проблемы стал pod с sidecar-контейнером Istio: он уперся в лимиты по параллельным запросам и не смог корректно смасштабироваться (auto scale). Это произошло из-за ошибки в конфигурации политики масштабирования, которая отслеживала параметры основного хостового сервиса, но игнорировала лимиты самого sidecar-контейнера. ​Сбой одного компонента вызвал каскадную реакцию, в результате чего четыре узла HAProxy исчерпали свои лимиты по количеству соединений (flow limits). Это привело к деградации шлюза аутентификации и массовым задержкам/ошибкам при входе пользователей. ​Ситуацию усугубила слишком оптимистичная логика повторных запросов (retry logic), которая создала избыточную нагрузку на внутренние балансировщики. Одновременная приостановка работы HAProxy на проблемных узлах сразу же привела к восстановлению системы

.

🔥 Постмортем: глобальный сбой сервисов GitHub 17 августа

GitHub на неделе столкнулся с масштабным сбоем, который затронул разработчиков по всему миру и нарушил стандартные рабочие процессы. Ваши тоже, да? Разбираемся по порядку. Все началось с проблемы с производительностью, которая переросла в глобальную деградацию большинства ключевых сервисов. Команда GitHub обнаружила источник и начала восстановление. Инженеры устраняли точечные проблемы с авторизацией, затрагивавшие Copilot и другие службы. Время сбоя составило почти 8 часов.

⚪️ Характер ошибок В пиковые моменты сбоя проблемы наблюдались практически по всей экосистеме платформы: - Веб-интерфейс и API: уровень ошибок (error rate) достиг примерно 20%. - Скачивание файлов: загрузка архивов и необработанного контента репозиториев (raw repository content) столкнулась с 50% уровнем ошибок. - Основные сервисы: сбои в работе Webhooks, API Requests, Issues, Pull Requests, а также систем автоматизации и тестирования GitHub Actions. - AI-инструменты: нарушен доступ к GitHub Copilot. - затронуты аутентификация SAML и OIDC, а также сервисы SCIM и Team Sync. ⚪️ Контекст и предпосылки Официальные детали технической причины платформой пока не раскрыты, однако инцидент произошел на фоне следующих факторов: - Взрывной рост AI-разработки: из-за нагрузки от AI-агентов и средств автонабора кода инфраструктура GitHub испытывает серьезное давление. В апреле CTO GitHub Владимир Федоров отмечал, что если осенью компания планировала 10-кратное расширение мощностей, то к февралю возникла необходимость проектировать масштабирование в 30 раз. Ранее 8 инцидентов с деградацией насчитали в июле, 6 —в июне. - Переход в облака: Microsoft ускоряет перевод GitHub на Azure, а также использует мультиоблачную стратегию, аренда мощностей у AWS. - Предположения экспертов: аналитики также указывали на сетевые инциденты на стороне AWS. @DevOpsKaz 😛

🔥 Постмортем: глобальный сбой сервисов GitHub 17 августа

GitHub на неделе столкнулся с масштабным сбоем, который затронул разработчиков по всему миру и нарушил стандартные рабочие процессы. Ваши тоже, да? Разбираемся по порядку. Все началось с проблемы с производительностью, которая переросла в глобальную деградацию большинства ключевых сервисов. Команда GitHub обнаружила источник и начала восстановление. Инженеры устраняли точечные проблемы с авторизацией, затрагивавшие Copilot и другие службы. Время сбоя составило почти 8 часов.

⚪️ Характер ошибок В пиковые моменты сбоя проблемы наблюдались практически по всей экосистеме платформы: - Веб-интерфейс и API: уровень ошибок (error rate) достиг примерно 20%. - Скачивание файлов: загрузка архивов и необработанного контента репозиториев (raw repository content) столкнулась с 50% уровнем ошибок. - Основные сервисы: сбои в работе Webhooks, API Requests, Issues, Pull Requests, а также систем автоматизации и тестирования GitHub Actions. - AI-инструменты: нарушен доступ к GitHub Copilot. - затронуты аутентификация SAML и OIDC, а также сервисы SCIM и Team Sync. ⚪️ Контекст и предпосылки Официальные детали технической причины платформой пока не раскрыты, однако инцидент произошел на фоне следующих факторов: - Взрывной рост AI-разработки: из-за нагрузки от AI-агентов и средств автонабора кода инфраструктура GitHub испытывает серьезное давление. В апреле CTO GitHub Владимир Федоров отмечал, что если осенью компания планировала 10-кратное расширение мощностей, то к февралю возникла необходимость проектировать масштабирование в 30 раз. Ранее 8 инцидентов с деградацией насчитали в июле, 6 —в июне. - Переход в облака: Microsoft ускоряет перевод GitHub на Azure, а также использует мультиоблачную стратегию, аренда мощностей у AWS. - Предположения экспертов: аналитики также указывали на сетевые инциденты на стороне AWS. @DevOpsKaz 😛

🚀 Как внедрить AI в компании и не застрять на этапе пилота? 27 августа в 12:00 по Астане VK Cloud проведет онлайн-вебинар: «Как внедрить AI в компании: от первых сценариев к масштабируемой enterprise-архитектуре» Многие компании уже тестируют AI-инструменты, но при переходе к реальному внедрению появляются вопросы: как подготовить данные, выстроить архитектуру, подключить RAG, AI-агентов, GPU-инфраструктуру и при этом контролировать затраты. На вебинаре эксперт VK Tech разберет: — почему одной LLM недостаточно для корпоративного AI; — как выглядит enterprise AI-архитектура; — какие ошибки мешают перейти от PoC к production; — как использовать GPU, Kubernetes и облачную инфраструктуру для AI-нагрузок; — какие AI-сценарии можно внедрять в бизнес-процессы уже сейчас. Спикер: Артем Симанов, ведущий менеджер продукта, направление AI-продуктов, VK Tech. Вебинар будет полезен CTO, CIO, руководителям Data/AI-направлений, архитекторам, DevOps-командам и тем, кто отвечает за внедрение AI в компании. 📅 27 августа, 12:00 по Астане 👈 Участие бесплатное по регистрации @DevOpsKaz 😛

🔥 Подборка топовых IT-каналов ⚙️ Dev Boost — Самая огромная коллекция платных курсов, которые можно скачать бесплатно 👩‍💻 IT Books — Самая огромная библиотека книг 💻 Hacking & InfoSec Base — Крутой блог белого хакера 🛡 CyberGuard — Всё про ИБ 🤔 ИБ Вакансии — Всё, чтобы найти работу в ИБ 👩‍💻 linux administration — Всё про Линукс 👩‍💻 Программистика — Python, python и ещё раз python 👩‍💻 GameDev Base — Всё про GameDev 😆 //code — Самые топовые мемы по IT Подпишись, чтобы не потерять!

🔥 Harness от DeepSeek Не успело отгреметь последнее обновление DeepSeek, как на сцену вышло что-то куда более ценное. Сейчас это самый быстрорастущий репозиторий на GitHub: за 3 дня набрал 130к звёзд — хайп на уровне OpenClaw, который стал первым годным опенсорс-агентом. Плагином может быть всё, что вы только сможете представить. Модели, сессии, скиллы, песочницы, циклы и даже просто интерфейс. Относите в Harness, а он выдает готового к работе агента. @DevOpsKaz 😛

⚡️ Онлайн-митап CRISIS MANAGEMENT IN TECH COMPANIES — 18 августа Это встреча о финансовой и операционной модели, инвестициях, юнит-экономике и решениях о масштабировании или трансформации проекта. Митап пройдёт на английском языке — хороший повод совместить полезную бизнес-практику с профессиональным английским. 📅 18 августа, 19:00, онлайн и бесплатно 👈 Регистрация @DevOpsKaz 😛

🔥 Безопасный AI-ассистент внутри кластера Пока все экспериментируют с агентами уровня доступа «всемогующий», мы предлагаем практическое руководство по созданию автономного, предназначенного только для чтения, AI-агента для кластера. Он использует GitHub Actions, Argo CD Image Updater. Работает внутри кластера, использует локальную модель и не передает данные за пределы сети. Агент не имеет прав на запись/изменение (update, delete), что изолирует кластер от возможных галлюцинаций модели. И вы можете развернуть его у себя без особого труда. В итоге получите агента с локальным запуском модели (zero-data-egress) + строгие ограничения RBAC (read-only) + полный аудит изменений через GitOps. @DevOpsKaz 😛