⚡️ PROFIT Telecom Day — 21 мая 2027 года

Конференция о цифровых сетях, спутниковой и мобильной связи, оптоволоконных сетях, IoT, защите сетей и развитии телеком-отрасли.

👈 Регистрация открыта (перенесли на 27-ой год)

На конференции затронут актуальные вопросы и перспективы развития телекоммуникационной отрасли:

➖ спутниковую связь и магистральные каналы
➖ городскую канализацию
➖ мобильную связь, 5G, интернет вещей
➖ телекоммуникационная безопасность и регулирование отрасли в целом.

PROFIT Telecom Day станет площадкой для обсуждения самых острых и актуальных вопросов связи, поможет сотрудничеству и обмену опытом всех заинтересованных сторон.

@DevOpsKaz 😛

⚡️ Copy Fail (CVE-2026-31431)

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

⚪️ Суть уязвимости CVE-2026-31431:

Любой непривилегированный пользователь может с помощью цепочки AF_ALG → splice() записать контролируемые 4 байта в страничный кэш любого читаемого файла, в который у него есть доступ на чтение. Обычной целью становится setuid-бинарник /usr/bin/su, модификация которого в памяти даёт root-шелл.

Изменения происходят только в памяти (in-memory), не затрагивая диск. Проверки целостности вроде checksum будут молчать

⚪️ Как влияет на облака и Kubernetes:

- Kubernetes. Страничный кэш шарится между контейнерами на ноде. Эксплоит из пода ломает изоляцию и пробивается на хост.

- CI/CD. Пулл-реквест на GitHub Actions, GitLab CI, Jenkins, выполняющий PoC, получает root на раннере. Дальше — компрометация секретов и всей пайплайновой инфраструктуры

⚪️ В чем опасность:

- Возраст. Баг завезли в ядро коммитом 72548b093ee3 в 2017 году, и с тех пор он тихо жил почти во всех дистрибутивах: Ubuntu, Debian, RHEL, Amazon Linux, SUSE и их производных.

- Простота. Пэйлоад умещается в 732 байта Python-скрипта, не требующего никаких зависимостей, кроме stdlib. Один скрипт — и у вас root на всех уязвимых системах.

- Стелс. Нет триггеров для большинства систем обнаружения.

⚪️ Что делать:

- Обновляйте ядра до версий, содержащих коммит a664bf3d603d
- Если патча у вашего вендора ещё нет — отключаем algif_aead.

Сайт исследователей
Детальный разбор от Microsoft
Рекомендации по триажу и патчингу от Wiz
Репозиторий PoC (только для проверки своих систем)

Кстати, баг нашли с помощью ИИ.

@DevOpsKaz 😛

🔥 Манифест против «тушения пожаров» без разбора причин

Инцидент-менеджмент возвращает сервис в рабочее состояние, а проблем-менеджмент ищет и устраняет первопричину, чтобы ситуация не повторилась.

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

1️⃣Примите как данность: закрытый тикет — это не конец истории. Заведите в своей ITSM-системе отдельный тип записей для Проблем, чтобы они не терялись в массе тикетов.

2️⃣ Выявите кандидатов на «Проблему». Не каждую ошибку нужно расследовать с лупой, а только критическую и рецидив. Если один и тот же мелкий баг повторяется регулярно, он «съедает» больше ресурсов, чем один крупный сбой. Используйте анализ Парето: 20% типов инцидентов приносят 80% головной боли.

3️⃣ Находите первопричины. Играйте в детектива и через вопросы пробирайтесь к корню проблем. Разложите проблему на категории (люди, методы, оборудование, среда). Соберите мнение экспертов, которые реально знают, «как это работает под капотом».

4️⃣ Зафиксируйте ошибку. Чтобы облегчить жизнь первой линии поддержки, публикуйте в базе знаний описание проблемы и обходной путь (Workaround).

5️⃣ Возьмите за правило — проблема считается решенной только тогда, когда причина устранена физически.

6️⃣ Переходите к проактивному управлению. Не ждите, пока что-то сломается. Анализируйте рецидивы и отчеты заранее. Ищите слабые места в инфраструктуре до того, как они станут инцидентами. Помните: лучший сервис — это тот, о существовании которого пользователь не вспоминает, потому что всё просто работает.

Если вы просто перезагружаете сервер каждый раз, когда он зависает, вы не работаете — вы надеетесь на чудо; настоящая работа начинается с вопроса «почему он зависает?».

@DevOpsKaz 😛

🔥 VictoriaMetrics теперь с метриками, логами и трейсами

Наблюдаем эволюцию VictoriaMetrics из простого хранилища метрик в полноценную платформу для наблюдаемости.

Раньше VM была «улучшенным Прометеем» и отвечала на вопрос: «Все ли в порядке?» (метрики, графики, алерты). Для
Observability нужны не только метрики, но и контекст: логи и трейсы. И VictoriaMetrics теперь закрывает все три направления (Metrics, Logs, Traces).

Основные фишки:

⚪️ Она потребляет до 10 раз меньше дискового пространства и ОЗУ, чем Elasticsearch или Grafana Loki на тех же объемах.
⚪️ Вместо того чтобы пытаться втиснуть логи в движок для метрик, разработчики создали специализированное хранилище (похожее по логике на ClickHouse).
⚪️ Новый язык запросов — LogsQL. Он проще, чем SQL, и интуитивнее, чем LogQL у Loki, при этом поддерживает полнотекстовый поиск.
⚪️ Не требует сложной настройки кластеров как в ELK.

Для полной картины добавлена поддержка трейсинга. Это позволяет DevOps-инженерам проследить путь конкретного запроса через все микросервисы в том же интерфейсе и стеке, где лежат метрики и логи.

Когда метрики, логи и трейсы лежат в одной экосистеме, проще коррелировать данные. Например, увидеть всплеск 500-х ошибок на графике и тут же «провалиться» в соответствующие логи и трейсы.

Теперь это полноценная альтернатива тяжелым Enterprise-стекам, которая позволяет построить глубокую наблюдаемость системы.

@DevOpsKaz 😛

⚡️ Kuber Meetup 2026 — Алматы, 28 мая, офлайн

Конференция про Kubernetes для бизнеса. Разберём реальные сценарии использования, посмотрим кейсы внедрения и обсудим, какие задачи он помогает решать в современных продуктах и инфраструктуре.

Спикеры:

⚪️Павел Селиванов, Архитектор, Yandex Cloud. Тема — Kubernetes 2026: от инфраструктуры к платформе для AI, данных и бизнеса
⚪️Кирилл Шевчук, Архитектор решений в Казахстане, Yandex Cloud. Тема — Kubernetes в реальности: почему он не работает «из коробки» и что с этим делать
⚪️Мирас Байгашев, DevOps Teamlead, Core 24/7. Тема — Kubernetes для бизнеса: best practices

Дополнительно команда покажет кейс миграции на Yandex Managed Service — изменения, результаты и решённые проблемы.

👈 Зарегистрируйтесь, чтобы забронировать участие

❗️Количество мест ограничено.

@DevOpsKaz 😛

⚡️ Прощай MinIO, встречайте RustFS

Эпоха сменяется на наших глазах: легендарный MinIO официально ушел на покой, но вакуум в мире объектных хранилищ заполняется мгновенно.

⚪️MinIO заархивирован

25 апреля основной репозиторий MinIO на GitHub был переведен в режим архива. Проект, который долгие годы был стандартом де-факто для S3-совместимых хранилищ, официально прекратил активную разработку в своем привычном виде.

⚪️RustFS — новый стандарт?

На смену приходит RustFS — опенсорсная система хранения, которая обещает не просто заменить предшественника, но и существенно превзойти его.

➖ Экстремальная скорость: RustFS работает в 2.3 раза быстрее MinIO при обработке небольших объектов (payload 4KB). Это критический показатель для микросервисной архитектуры и кэширования.

➖ Полная S3-совместимость: переход не потребует переписывания кода ваших приложений.

➖ Бесшовная миграция: система поддерживает режим сосуществования с MinIO и Ceph, позволяя мигрировать данные постепенно и без простоев.

Если ваша инфраструктура завязана на S3-хранилищах, сейчас самое время изучить альтернативы. RustFS выглядит как прямой наследник, предлагающий безопасность памяти Rust и впечатляющий прирост IOPS там, где это нужнее всего.

Как вы думаете, станет ли RustFS новым стандартом? Ставьте реакции, чтобы выразить мнение:

👍 — выглядит недурно

👎 — сомневаюсь

@DevOpsKaz 😛

🔥 Как понять, каких знаний не хватает

Чтобы оставаться востребованным специалистом, всем нам нужно что-то подтянуть, а порой и освоить что-то новое. Большинство инженеров развиваются реактивно — обучаются в том, что требует их текущая работа. Это нормально, но не всегда эффективно. По данным World Economic Forum, 44% core скиллов обновятся к 2027 году. А это значит, что нужно думать наперед.

Как понять, что учить дальше?

1️⃣ Открываем вакансии мечты, на уровень выше своего и желательно западной компании
2️⃣ Находим пересекающиеся core-скиллы и выписываем их в таблицу
3️⃣ Сортируем их по 3 столбцам (умею, сомневаюсь, не умею)

Подтягиваем те навыки, в которых сомневаемся, и учимся недостающим.

Большинство скиллов, которые пригодятся в ближайшем будущем, уже упакованы в курсы. Например, на странице нашей компании есть большой выбор дисциплин, метанавыков и комплексных программ. На курсы Слёрм действует региональная скидка для подписчиков KazDevOps.

@DevOpsKaz 😛

🔥 Подборка инструментов DevOps

⚪️ kagent

Нативный Kubernetes-фреймворк для создания AI-агентов (проект CNCF Sandbox), обновился до v0.9.0. Добавлены поддержка песочниц для агентов, интерфейс для шаблонов промптов, обмен токенами для аутентификации моделей и SAP AI Core в качестве нового провайдера моделей.

⚪️ KubeVirt v1.8.0

Обновился проект (CNCF Incubating), который позволяет запускать виртуальные машины бок о бок с контейнерами в Kubernetes. Появились тома ContainerPath (маппинг путей контейнера для дисков ВМ). Внедрили инкрементальные бэкапы с CBT (Changed Block Tracking), а также добавили топологию PCIe NUMA для более эффективной работы GPU. В будущем можно будет интегрировать не только KVM.

⚪️ etcd-walker

Представляем приложение для работы с etcd хранилищем как с системой файлов. В нем можно создавать, удалять, экспортировать ключи и директории через единый интерфейс с поддержкой всех версий etcd, аутентификацией и TLS.

⚪️ CloudNativePG v1.29.0

Платформа для управления PostgreSQL внутри Kubernetes (CNCF Sandbox). Ключевым обновлением стала интеграция Image Catalogs с новой выделенной экосистемой расширений PostgreSQL. Также добавлены: динамический контроль доступа к сети через селекторы подов, поддержка общих ServiceAccount и гранулярная настройка TLS для PgBouncer. Проект начал подписывать все релизные артефакты и образы контейнеров.

@DevOpsKaz 😛

⚡️ Amazon, что по токенам?

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

Корпоративная культура Amazon породила новый термин — «токенмаксинг». Сотрудники намеренно раздувают показатели использования ИИ-инструментов, чтобы соответствовать жестким внутренним KPI.

По правилам Amazon более 80% разработчиков должны еженедельно использовать ИИ-инструменты. Ввели даже «таблицы лидеров», отслеживающие потребление токенов. Чтобы не оказаться внизу списка лидеров, разработчики отправляют ИИ бессмысленные или повторяющиеся запросы, перефразируют одни и те же тексты или заставляют модель генерировать огромные объемы кода, который им не нужен.

Это создает иллюзию массового внедрения ИИ, хотя реальная ценность такой работы зачастую нулевая. Феномен возник на фоне общего стремления техгигантов доказать инвесторам, что их огромные вложения в ИИ окупаются и меняют рабочие процессы.

Оценка работы по количеству потребленных токенов — это то же самое, что оценивать качество кода по количеству написанных строк.

👍 — мир, который мы заслужили

👎 — бездари, отдайте токены нам

@DevOpsKaz 😛

🔥 DevOpsDays Tashkent 2026 — начинается

👈 Онлайн-трансляция

В программе:

⚪️Metal3 – Kubernetes Provisioning on Baremetal
⚪️Amazon SQS за 5 минут
⚪️Эволюция надежности: как мы трансформировали SRE в Yandex Go за 6 лет
⚪️CI/CD для мобильных приложений (Android, iOS)
⚪️Gateway API: Ingress мёртв, да здравствует Gateway!
⚪️Dynamic Resource Allocation: от статических реквестов к гибкому планированию
⚪️А также воркшопы и другие активности

Подключайтесь и смотрите доклады — это бесплатно.

@DevOpsKaz 😛

⚡️ Доклад с DevOpsDays Tashkent от Core 24/7

Для самых любознательных, как и обещали, целая куча материала с доклада "Ingress умер, да здравствует Gateway!" на DevOpsDays Tashkent от Байгашева Мираса.

Несмотря на относительно небольшой срок работы в DevOps, Мирас уже активно выступает на площадках CNCF Kazakhstan и Yandex Cloud и фокусируется на современных подходах, стабильности и улучшении инфраструктуры.

👈 Смотреть доклад Мираса

⚪️Разбор CVE-2025-1974 от Fortinet — мирового лидера решений и систем по кибербезопасности
⚪️Что предоставил Nginx в мире Gateway API? Контроллер Nginx Gateway Fabric
⚪️Пример создания HTTPRoute с автоматическими Reference Grant в виде Helm чарта
⚪️Официальный скрипт Kubernetes для миграции манифестов Ingress-nginx в формат Gateway
⚪️Официальный гайд Kubernetes по миграции с Ingress-nginx
⚪️Больше про Service Mesh через Gateway API — Project GAMMA
⚪️Официальные гайды по переносу аннотаций Ingress-nginx в формат Gateway API
⚪️Интеграция Gateway API и cert-manager
⚪️Inference Extension для балансировки ИИ трафика в Gateway API
⚪️Результаты сравнения базовых Service и Inference Extension ресурсов для ИИ трафика
⚪️Реальный пример использования Inference Extension с моделью llama
⚪️Самый навороченный контроллер Gateway API — AgentGateway
⚪️Какие контроллеры уже имплементированы для Gateway API
⚪️Как выбрать контроллер — бенчмарки всех доступных контроллеров

@DevOpsKaz 😛

🔥 А если взглянуть на SRE и любую «надежность» с другого угла?

Сегодня немного философии.

Есть такая модель Safety-II, которая в отличии от традиционного подхода (минимизация негативных факторов, приведших к сбою) предлагает сосредоточиться на развитии позитивных факторов — на повседневной работе, которая раз за разом предотвращает аварии. Вместо вопроса «Почему всё пошло не так?» можно спрашивать себя «Как сделать так, чтобы всё работало правильно?». В конце концов, мы измеряем доступность «девятками» (99,9% или 99,99%).

Эта идея кажется нам как инженерам настолько непривычной, что она буквально противоречит знаниям о том, как ломаются системы. В чем главная проблема?

Мы живем с установкой, что надежность — вещь пассивная: мол, по умолчанию система должна работать стабильно, а чтобы она сломалась, кто-то должен активно сделать что-то не так. Мы воспринимаем повседневную работу людей внутри системы как потенциальную угрозу для надежности.

Если рассматривать адаптивные действия сотрудников только в контексте инцидента и пытаться повысить надежность за счет их запрета, это будет похоже на попытку понять, как выиграть в лотерею, изучая поведение победителей. Существует гораздо больше проигравших, которые вели себя точно так же, просто мы на них не смотрим.

❗️ Приложили книгу Safety-I and Safety-II The Past and Future of Safety Management для тех, кто захочет глубже копнуть в эту тему.

Почему внедрить Safety-II сложно?

⚪️Компании попросту не привыкли изучать свою нормальную деятельность, чтобы ответить на вопрос: «Что у нас получается особенно хорошо и как масштабировать этот успех?»

⚪️Внимание внутри организации — ограниченный ресурс. Если все индикаторы «зеленые», это воспринимается как сигнал, что мы можем со спокойной душой переключить бюджет внимания на что-то другое.

⚪️В сфере технологий большая часть нашей работы фактически невидима: мы сидим один на один с компьютером.

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

@DevOpsKaz 😛

📅 Call for Papers на DevOpsDays Almaty 2026

Следующий DevOpsDays Almaty состоится в октябре 2026 (точная дата и место уточняются)

👈 Регистрируйтесь спикером, если хотите выступить с докладом

Какие доклады мы ждем:

⚪️Инструменты и платформы

Практика использования ОС, СУБД, CI/CD пайплайнов, контейнеризации, Kubernetes и оркестрации, систем мониторинга, логирования и observability-стека.

⚪️Безопасность и DevSecOps

Интеграция безопасности в процессы разработки, управление уязвимостями, защита инфраструктуры и данных, secure-by-design подходы.

⚪️Облака и инфраструктура

Переход в облако, мульти- и гибридные архитектуры, serverless-подходы, оптимизация затрат и производительности.

⚪️Практические кейсы

Реальные истории: что сработало, что нет, какие компромиссы пришлось принять и какие уроки вы извлекли.

⚪️Люди, процессы и культура

Построение эффективных команд, развитие DevOps-культуры, взаимодействие между разработкой, эксплуатацией и бизнесом.

⚪️Новые подходы и будущее DevOps

Тренды и эксперименты на практике, включая:
– применение AI и ML в инфраструктуре;
– использование агентов в продакшене (LLM-агенты, auto-remediation, AI-assisted ops);
– MCP-серверы и их роль в DevOps-пайплайнах;
– predictive autoscaling и адаптивные системы;
– log clustering, noise reduction и интеллектуальный анализ логов;
– автоматизация принятия решений и self-healing системы.

[Форма регистрации]

@DevOpsKaz 😛