KazDevOps

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

❤️ «Kubernetes в гневе» Пост для тех, кто уже перерос базовые туториалы и столкнулся с суровой реальностью эксплуатации. Существует огромный разрыв между пониманием базовой теории Kubernetes и реальным поддержанием жизнеспособности EKS-кластера в продакшене. Практическое руководство по траблшутингу поможет закрыть пробелы и ответит на самые болезненные вопросы при сбоях инфраструктуры. ➖ Что делать, когда поды переходят в статус Pending, а очевидных причин для этого нет? ➖ Как точно определить, является ли DNS первопричиной проблемы или это лишь симптом другого сбоя? ➖ Почему ваш сетевой балансировщик (NLB) постоянно сбрасывает соединения? ➖ Как правильно и быстро собрать улики и логи до того, как сработает автохилинг (самовосстановление) кластера и уничтожит все следы, необходимые для анализа причин аварии? ➖ И еще десяток важных вопросов, раскрытых на кейсах Самое главное — автор объясняет, как не сойти с ума, когда всё идет не по плану. Сохраняйте себе и делитесь с коллегами 🫡 @DevOpsKaz 😛

👾 Постмортем: ИИ-агент + Terraform = снесённый прод История о том, как чрезмерное доверие к AI-ассистентам в связке с IaC может за пару минут уничтожить продакшен-инфраструктуру, которая создавалась годами. Автор истории решил перенести статический сайт с GitHub Pages в AWS и развернуть новую Django-версию. Ради копеечной экономии на VPC ($5–10) он решил подселить новый сайт в существующую инфраструктуру платформы управления курсами. Делать это помогал ИИ-агент (Claude Code). Что произошло: ⚪️Разворачивая проект на новом ПК, автор забыл перенести Terraform state. Запущенный агентом terraform plan решил, что ничего не существует, и начал плодить дубликаты. ⚪️Пытаясь навести порядок, автор принёс архив со старого ПК. Агент распаковал его и затер текущий стейт старым, вернув в него описание реального прода. ⚪️Агент предложил: «Давай выполним terraform destroy, чтобы начисто удалить дубликаты». Автор согласился. Результат: полностью уничтожен прод и стёрты данные за 2.5 года. Вместе с базой удалились и все автоматические RDS-снапшоты — это стандартное поведение AWS, если не защититься от этого в конфигах заранее. Как спасали прод: ⚪️Обычная поддержка не помогала, пришлось экстренно переходить на тариф AWS Business Support (+10% к облачному счету), чтобы получить ответ за час. ⚪️Инженеры AWS Support подтвердили, что скрытые бэкапы на стороне AWS еще живы, и передали их внутренней команде на восстановление. ⚪️На полное оживление базы (в одной только таблице ответов было почти 2 млн строк) ушло около 24 часов. Выводы автора истории и дальнейшие шаги читайте в полной статье. 👈 Читать разбор инцидента @DevOpsKaz 😛

🔥 Freedom Connect подключает к интернету 90% сельской местности Казахстана В казахстанском телекоме и инфре намечается масштабный деплой: Freedom Connect подписались с «Транстелеком» на строительство ВОЛС в рамках национального проекта «Доступный Интернет». Для понимания масштаба: проект СНП 2.0 целится на покрытие высокоскоростным интернетом до 90% сельских населённых пунктов Казахстана. С точки зрения инфраструктуры — это огромный вызов по связности и latency на колоссальных расстояниях. Как отмечает СЕО компании Фархат Максутканулы:

Эта сеть станет физическим фундаментом для пропуска трафика будущих AI-сервисов и развития экономики данных в регионах. Когда физический уровень (L1/L2) дотянется до самых удаленных точек, перед нами откроется огромный рынок для распределенных систем, edge-вычислений и локальных инфраструктурных решений.

Ждем технических подробностей о топологии сети и используемом вендорском оборудовании. Очевидно, что для управления такой распределенной махиной ребятам понадобится очень серьезный автоматизированный сетевой мониторинг и IaC на полную мощность. @DevOpsKaz 😛

🔥 Симуляторы для инженеров и разработчиков

Вместо того, чтобы ронять прод, можно сделать то же самое на симуляторе — при этом без риска получить выговор. И такой симулятор есть — Semicolony. Он популярен среди инженеров, которые готовятся к серьезным собеседованиям, или кто хочет глубже разобраться в надежности и архитектуре крупных веб-сервисов. Вы можете изменять параметры сети, имитировать сбои серверов и сразу видеть, как это влияет на систему.

На платформе представлено более 40 различных симуляторов. Например: ⚪️Постепенное развертывание в Kubernetes. Работа с контроллером через maxSurge и maxUnavailable и завершение работы пода. ⚪️Распределенный консенсус. Визуализация того, как узлы в сети выбирают лидера, как происходит репликация логов и что случается, если часть серверов внезапно уходит в офлайн. ⚪️Теорема CAP. Симулятор, позволяющий «разрезать» сеть (создать network partition) и в реальном времени увидеть, как распределенная система жертвует либо согласованностью данных, либо доступностью. ⚪️Консистентное хеширование. Помогает понять, как распределяется нагрузка в базах данных и кэшах. Вы можете добавлять или удалять узлы и наблюдать, как перебалансируются данные с минимальными потерями. ⚪️Структуры данных (B-Trees и LSM-Trees). Показывают «подкапотную» часть современных баз данных. Можно увидеть, как индексируются данные, как разрастаются деревья и как происходит слияние таблиц. ⚪️Сетевые протоколы. Пошаговые интерактивные разборы DNS-резолвинга и TLS-рукопожатия, показывающие, какими именно пакетами обмениваются клиент и сервер для установки защищенного соединения. @DevOpsKaz 😛

🔥 Вебинар «Миграция в облако без серьезных простоев» — 1 июля, 19:00 Миграция инфраструктуры — процесс, где спотыкается даже зрелая команда. Сроки часто сдвигаются, «незаметный» сервис оказывается зависимостью половины системы, и узнаешь об этом в день переключения. А счёт за облако приходит в разы больше ожидаемого. 1 июля в 19:00 мы в Core 24/7 проведем совместный вебинар с Yandex Cloud. Расскажем, как мигрировать так, чтобы пользователи ничего не заметили, деньги не утекли в неизвестность, а результат порадовал всех. Что будет на вебинаре: ⚪️ Причины, почему миграция идёт не по плану ⚪️ Решение проблем с миграцией ⚪️ Алгоритм миграции без даунтайма ⚪️ Кейс Biometric: миграция в Yandex Cloud и настройка CI/CD под современные требования ⚪️ Кейс миграции стартапа ⚪️ Lift & Shift или Cloud-Native: как не переплатить за облако ⚪️ Ответы на вопросы Спикеры — Александр Калинин, COO Core 24/7, и Ренат Бегайдар, Yandex Cloud. Формат: онлайн, ~75-90 минут, бесплатно. Запись будет. 👈 Зарегистрироваться Приглашайте руководителей, коллег и приходите сами 🫡 @DevOpsKaz 😛

⚡️ Чек-лист верификации ПО в эпоху ИИ ИИ кардинально меняет роль инженера — фокус смещается на валидацию смыслов. Чтобы вы ничего не пропустили, рассказываем, на что обратить внимание — сохраняйте себе и делитесь с коллегами. ⚪️ Проверка на логические галлюцинации. Убедиться, что ИИ не придумал правдоподобно выглядящие, но несуществующие параметры, свойства объектов или скрытые бизнес-правила, противоречащие исходному ТЗ. ⚪️ Очистка от мертвого и избыточного кода. Проверить сгенерированный объем на лишние абстракции, неиспользуемые импорты или функции-пустышки. ⚪️ Соответствие архитектуре. Проверить, вписывается ли предложенный ИИ фрагмент в общую концепцию и паттерны проекта, или он решает задачу изолированно, нарушая глобальную структуру. ⚪️ Поиск устаревших практик. Проверить код на устаревшие подходы и уязвимые методы. Так как ИИ обучался на исторических данных, он может воспроизводить небезопасные паттерны прошлых лет. ⚪️ Аудит сторонних зависимостей. Проверить все предложенные ИИ внешние пакеты и библиотеки: существуют ли они реально, нет ли известных критических уязвимостей (CVE), подходят ли лицензионной политике проекта. ⚪️ Контроль утечки чувствительных данных. Убедиться, что в коде отсутствуют зашитые тестовые ключи, токены, пароли или персональные данные, которые могли попасть в генерацию из обучающей выборки модели. ⚪️ Перекрестный аудит тестов. Если юнит-тесты генерировались той же моделью, они могут дублировать её же логические ошибки. Тесты от ИИ должны либо жестко ревьюиться человеком, либо создаваться независимой моделью. ⚪️ Покрытие граничных условий. Вручную добавить тест-кейсы для экстремальных входных данных. Модели часто упускают из виду редкие сценарии (деление на ноль, пустые массивы, переполнение типов). ⚪️ Ложное ощущение надежности. Провести полноценное функциональное тестирование. Красивое форматирование и академически правильные комментарии ИИ усыпляют бдительность, скрывая дефекты за идеальным «внешним видом». @DevOpsKaz 😛

⚡️ Roadmap по изучению Linux Если вы новичок в DevOps и администрировании, или у вас есть знакомые, которые начинают свой путь — этот пост для вас. Пошаговый маршрут с упором на практику проведет вас от нуля до уверенного админа. В каждом разделе — объясняют «почему это устроено именно так», разбирают команды и дают задания, которые нужно выполнить руками, чтобы получить опыт. Курс нужно проходить в том порядке, в котором он и выложен. 👈 Приступить к изучению Linux И напоминаем: лучший способ учиться — это совершать ошибки и самому их исправлять. @DevOpsKaz 😛

⚡️ Приглашаем на второй митап AI Qadam — 20 июня, Ташкент Спикеры на личном практическом опыте разберут живые бизнес-кейсы: ⚪️ чем боты отличаются от агентов ⚪️ что такое оркестрация агентов и как ею управлять ⚪️ как собрать собственную команду ИИ-разработки А главное — покажут, что всё это доступно уже любому прямо сейчас. 👈 Зарегистрироваться Спикеров и их доклады представят в LinkedIn и Telegram.

20 июня 2026, 13:00–15:00 (Ташкент) IMPACT.T Innovation Hub, Tashkent Язык: русский

@DevOpsKaz 😛

🎉 DataBoom Birthday — важное событие для всех, кто в аналитике и IT! 27 июня в Алматы пройдет DataBoom Birthday — масштабное событие, которое объединит более 500 участников: аналитиков, разработчиков, специалистов по данным и тех, кто только начинает карьеру в IT. Вас ждет: ⚪️ Конференция с участием экспертов из крупнейших IT-компаний ⚪️ Ярмарка вакансий от топ-компаний Казахстана: Kolesa Group, Head Hunter, Air Astana, Bereke Bank и другие ⚪️ Нетворкинг с представителями индустрии ⚪️ Розыгрыши, квизы, активности и атмосфера, которую не передать словами

27 июня, 12:00–18:30 г. Алматы, Университет Нархоз

🎟️ КУПИТЬ БИЛЕТ @DevOpsKaz 😛

🔥 Datadog внедряет ИИ-агентов глубоко в DevOps-процессы для автоматизации мониторинга и исправления ошибок

Datadog объявила о масштабном апдейте своей ИИ-платформы Bits, чтобы дать DevOps-командам автоматически находить и устранять инфраструктурные и программные сбои на основе телеметрии. Интеграция ИИ переводит системы мониторинга на новый уровень: теперь они не просто описывают проблемы в продакшене, а фактически управляют ими и контролируют изменения в коде.

⚪️ Bits Code — ИИ для написания кода, встроенный во всю линейку продуктов Datadog. На основе данных мониторинга он сам предлагает варианты исправления ошибок и генерирует необходимый код. ⚪️ Bits Release — агент для проверки изменений в коде. Он анализирует потенциальный эффект от правок, формирует план валидации, запускает тесты в staging-окружении и контролирует процесс развертывания. ⚪️ Bits Testing Agent — инструмент для автоматического создания и поддержки синтетических тестов. Он сканирует приложение, выявляет критические сценарии пользовательского опыта и формирует под них тестовые наборы. ⚪️ Bits Remediation и Bits Infrastructure Operations — модули автоустранения неполадок со скриптами исправления ошибок. ИИ может автономно находить и чинить повторяющиеся проблемы в инфраструктуре, опираясь на ранее одобренные действия. ⚪️ Bits Memories — «память» ИИ-системы, которая аккумулирует информацию из прошлых расследований, runbook-инструкций, postmortem-отчетов и переписок в Slack, чтобы автоматически компилировать и запускать скрипты исправления. ⚪️ Bits Detection — для автоматического расширения зоны мониторинга при добавлении в ИТ-окружение новых эндпоинтов и рабочих нагрузок. @DevOpsKaz 😛

🔥 Yandex Cloud CDN стал доступен в Казахстане CDN позволяет ускорить работу устройств и приложений, повысить позиции сайта в поисковой выдаче, снизить нагрузку на серверы и расходы на инфраструктуру. Для потребителей контента это означает более быструю загрузку сайтов, картинок и видео. Сейчас клиентам в Казахстане доступны локации суммарной емкостью сети порядка 1 Тбит/с. Оплата только за исходящий трафик — из CDN к потребителю контента. Также компания может самостоятельно настраивать время кеширования, что позволяет оптимизировать инфраструктуру. Подробнее о сервисе рассказал архитектор Yandex Cloud Иван Кабанов в статье для The Tech: 👈 Читать статью @DevOpsKaz 😛

🔥 Отладка bash: а что, так можно было? Каждый DevOps-инженер или системный администратор рано или поздно оказывается в персональном аду, имя которому — отладка чужого (или забытого своего) Bash-скрипта на 500+ строк. Когда всё, что у тебя есть — это разбросанные по коду echo. На Хабре рассказали: ⚪️ Как заставить скрипт автоматически выплевывать стек вызовов, имя функции и номер строки, в которой произошла ошибка, без ручного прописывания проверок после каждой команды. ⚪️ Все знают про set -x, но мало кто умеет кастомизировать переменную PS4. Как вывести в трейс время выполнения команды, имя функции и даже глубину вложенности ⚪️ Про утилиты, которые позволяют «дебажить» Bash как нормальный язык программирования ⚪️ Как отловить 95% глупых багов и скрытых уязвимостей в синтаксисе еще до того, как уронишь прод 👈 Читать статью на Хабре Руководство поможет автоматизировать рутину для дебага, сразу писать скрипты, за которые не стыдно, и понимать, почему «оно опять упало». @DevOpsKaz 😛

⚡️ До нового Cloud Native Community Day — 2 месяца Кажется, времени вагон, но на самом деле нет. Хороший доклад не готовится за 5 минут. Нужно время, чтобы в спокойном темпе собрать структуру, выкинуть лишнее, прогнать черновик с нашей командой. ❗️ Чтобы подготовиться без аврала, заявку стоит подать до 15 июня. Слотов для спикеров всего 4-5. Берём доклады по реальному опыту, а не по громкости темы: сертификация, service mesh, ArgoCD, инциденты, платформа, FinOps. Если у вас есть история «было больно — вот как решили» — она нам нужна. Подавайте заявку — свяжемся и поможем довести доклад до ума. 👈 Подать заявку как спикер @DevOpsKaz 😛

🚀 Как мы провели полный аудит IT-инфраструктуры для Bilim Group BilimGroup — IT-платформа Казахстана, которая предлагает клиентам образовательные программы. Это 24 крупных проекта и около 3 млн пользователей. В группу входит более 15 цифровых образовательных компаний. Перед Bilim стояла задача выявить узкие места, риски и точки роста в IT-инфраструктуре перед масштабированием и возможной миграцией. Группа компаний обратилась к нам в Core 24/7 для комплексного аудита: ⚪️ Поговорили с ключевыми сотрудниками ⚪️ Собрали и проанализировали артефакты ⚪️ Определили ожидания и глубину анализа — провели аудит и составили рекомендации О ходе аудита и результатах читайте в новом кейсе. 👈 Читать @DevOpsKaz 😛

🚀 Хотите прокачать свои навыки в AI-разработке? Приглашаем на Build with AI: Astana — событие для разработчиков, которые хотят прокачать навыки работы с искусственным интеллектом и узнать, как применять AI-инструменты на практике. Участники узнают, как внедрять AI-решения в реальные продукты, работать с Gemini, Gemma и мультимодальным искусственным интеллектом, применять подходы к AI-финансам и AI-безопасности, использовать дообучение моделей для медицинских данных, а также выстраивать практические AI-процессы и запуск решений. 👈 Регистрация

12 июня, 12:00-18:00, пр-т. Мангилик Ел. 55/1, Астана Для входа необходимо заранее скачать мобильное приложение Astana Hub

Спикеры: ⚪️ Ramesh Chander — Regional Lead, Developer Ecosystem, MENA, Turkey & Central Asia, Google ⚪️ Alexander Tyutin — DevSecOps, Semrush ⚪️ Adkham Zokhirov — CAIO, Mohirdev LLC ⚪️ Bilguun Jargalsaikhan — Founder & AI Researcher, Deep Tech LLC ❗️Мероприятие пройдёт на английском языке.

Такие мероприятия возможны благодаря нашим партнерам из Astana Hub — крупнейший международный технопарк IT-стартапов в Центральной Азии. Здесь создаются условия для свободного развития казахстанских и зарубежных IT проектов.

@DevOpsKaz 😛

🔥 Новости мира DevOps, которые вы могли пропустить ⚪️ Релиз Kagent 0.96 — опенсорсного фреймворка класса Cloud Native Agentic AI, который превращает ИИ-агентов в полноценные ресурсы Kubernetes, управляемые через привычные YAML-файлы ⚪️ OpenYurt получила версию v1.7.0, которая повышает стабильность и автоматизацию — это платформа расширяет возможности нативного Kubernetes на Edge Computing ⚪️ История о том, как AWS перестроила свою сеть на основе теории случайных графов и сэкономила миллионы ⚪️ NATS, edge-native система обмена сообщениями, выпустила сервер версии v2.14. Добавили поддержку feature flags в конфигурации сервера, функцию пакетной публикации с высокой скоростью обработки и планирование отправки сообщений на основе интервалов и cron-выражений ⚪️ Опубликовали чек-лист готовности Kubernetes к проду @DevOpsKaz 😛

🔥 Доклады с DevOpsDays Tashkent 2026 Во вложении видео о том, как мы с Core 24/7 съездили в Ташкент. Если вы пропустили какой-то доклад (или саму конференцию) или просто хотите пересмотреть интересные моменты — теперь это можно сделать в любое время. 👈 Доклады DevOpsDays Tashkent 2026 А ещё мы подготовили aftermovie DevOpsDays Tashkent 2026. Спасибо всем, кто был с нами в этот день, выступал, задавал вопросы, спорил в кулуарах, участвовал в воркшопах и просто создавал ту самую атмосферу сообщества, ради которой всё это и затевается. @DevOpsKaz 😛

⚡️ PROFIT Contact Day — 12 июня в Алматы

Общение с клиентами — самый уязвимый момент в бизнесе, ведь «один довольный клиент расскажет максимум троим, а недовольный — минимум девяти». Так как же бизнесу нивелировать и даже предотвратить недовольства клиентов, как сделать их более лояльными. Как вообще узнать, что ваши клиенты недовольны?

Ответы на эти и другие вопросы лежат в основе современных решений для контакт-центров. Что это за решения, каков их функционал, какую аналитику можно получить с их помощью, какой Call-центр выбрать — корпоративный или аутсорсинговый — вы узнаете в рамках конференции PROFIT Contact Day. PROFIT Contact Day — конференция о технологиях контакт-центров, омниканальности, ИИ, аналитике, клиентском сервисе и управлении персоналом. 👈 Регистрация открыта Узнайте, как поднять общение с клиентами на новый уровень и извлечь максимум выгоды от ИТ!   @DevOpsKaz 😛

🔥 Парадокс observability: больше сигналов, меньше ясности

Время на восстановление работы после инцидентов увеличивается с каждым годом. И это на фоне рекордных затрат на инструменты наблюдаемости. Доля команд с MTTR > одного часа растет из года в года: 7% в 2021 году, 64% в 2022 году, 74% в 2023 году и 82% в 2024 году. При этом среднее количество инструментов, используемых одной командой, выросло до 8–9 различных платформ. И ответ команд пока что один — «нужно больше»: больше инструментов, больше дашбордов, больше сигналов. Все исходят из предпосылки, что главная проблема — это видимость.

Однако после определенного порога избыток данных observability приводит к когнитивной перегрузке. Это мешает поиску первопричин (RCA) и лишь увеличивает MTTR. Как ни парадоксально, больше сигналов часто означает меньше ясности. Инженер не способен сопоставить 8 дашбордов на 4 разных платформах, когда инцидент происходит в 2 часа ночи. Он ищет сигнал, похожий на то, что он уже видел ранее. Анализ подходов к снижению MTTR показывает, что скорость восстановления стабильно обеспечивают 3 вещи: ⚪️быстрое и точное обнаружение ⚪️инструментарий с низкой кардинальностью ⚪️понятные пути диагностики Что с этим можно сделать? ⚪️ Измеряйте то, куда уходит внимание инженера. Что конкретно он открывал во время аварии? На какие графики смотрел дольше 30 секунд? Какие действия предпринимал? А что полностью проигнорировал? ⚪️ Проектируйте дашборды под инциденты, а не под покрытие. Каждая панель должна отвечать на конкретный вопрос, который возникает у инженера во время сбоя. Если вы не можете сформулировать этот вопрос — удаляйте панель. ⚪️ Качество сигнала важнее его объема. Один точный алерт, указывающий на корень проблемы, ценнее 50 алертов, требующих расшифровки. Регулярно проверяйте соотношение алертов к действиям. Если инженеры постоянно «гасят» или игнорируют уведомления — система шлет вам сигнал о собственной неэффективности. ⚪️ Проводите аудит внимания после крупных сбоев. Общайтесь с инженерами: что они открывали, что сработало, а что только мешало. Три месяца такой практики дадут вам более честное понимание ценности вашего observability-стека, чем любой отчет. @DevOpsKaz 😛