🚀 CI/CD → GitOps → MLOps

Современная инфраструктура сводится к одной ключевой идее — пайплайнам. Но то, что течёт через эти пайплайны и как они управляются, определяет разницу между парадигмами, будь то CI/CD, GitOps или MLOps.

⚪️ Традиционный CI/CD (Push-модель)

- Фокус: доставка кода приложения
- Поток: write → build → test → deploy
- Развёртывание: пайплайн сам пушит изменения в окружения
- Цель: быстрые, надёжные и повторяемые релизы

⚪️ GitOps (Pull-модель)

- Фокус: инфраструктура и развёртывания через Git
- Поток: Git как единственный источник истины → декларативные манифесты → авто-синхронизация с кластером
- Развёртывание: операторы (Argo CD / Flux CD) вытягивают желаемое состояние из Git и применяют его к кластеру
- Цель: согласованность, полная аудитируемость, автоматическое обнаружение дрифта

⚪️ MLOps

- Фокус: полный жизненный цикл машинного обучения
- Поток: данные → инженерия признаков → обучение → оценка → развёртывание → переобучение
- Развёртывание: модель пакетируется и выкатывается через пайплайны (batch-задачи, REST/gRPC API или стриминговые сервисы)
- Цель: воспроизводимость экспериментов, стабильность качества модели, непрерывное улучшение

Что на самом деле меняется? Мы последовательно переходим от пайплайнов кода → к пайплайнам инфраструктуры → и пайплайнам данных + моделей. А дальше уже появляются новые уровни: AIOps, LLMOps и т.д. Каждый следующий слой добавляет сложности, но основа остаётся прежней — это всё те же пайплайны.

@DevOpsKaz 😛

🔥 Тупик масштабирования: как расширить кластер виртуализации БЕЗ остановки бизнес-сервисов

Все мы сталкивались с такой ситуацией: кластер «под завязку», на СХД нет свободных портов, SAN — point-to-point (без коммутаторов), любое изменение рискует вырубить прод. А бизнес и начальство требует 100% доступности. Особенно болезненно, когда документация скудная, а хосты могут внезапно «не увидеть» LUN.

Решаем за 5 шагов (универсально для VMware, oVirt, KVM и др.):

⚪️Аудит

Полная инвентаризация, метрики (реальное потребление CPU/RAM/IOPS), карта зависимостей, точки отказа, проверка бэкапов.

⚪️Проектирование целевой схемы

Вводим FC-коммутаторы, dual-fabric, зонинг по WWPN (best practice IBM), добавляем хосты для возврата N+1.

⚪️Создаём запас ёмкости

Временно переносим нагрузку или отключаем тестовые стенды, чтобы было место для живой миграции. Цель — 15–20% буфера + N+1.

⚪️«Одно изменение за раз»

- Разворачиваем и настраиваем FC-коммутаторы
- По одному хосту: переводим в сервисный режим → мигрируем ВМ → перекоммутируем SAN → проверяем пути и LUN → возвращаем в кластер
- Всё тестируем на пилотном хосте заранее

⚪️Фиксация

Обновляем схему, CMDB, алерты на «красную зону» заполнения.

Как результат — бесшовное масштабирование без даунтайма, отказоустойчивость и возможность планового обслуживания.

@DevOpsKaz 😛

⚡️ GitHub в Казахстане: смотреть можно, трогать нельзя

Похоже, в РК начались странные танцы вокруг GitHub. Ситуация такая: сам сайт открывается без проблем, но как только дело доходит до скачивания бинарников из разделов Releases — всё «умирает».

Что происходит:

Судя по всему, мы имеем дело с точечной блокировкой по SNI для IP из Казахстана. Под удар попал поддомен objects.githubusercontent.com (это хранилище Azure, куда GitHub перенаправляет трафик при попытке скачать файл). Основной домен на Fastly оставили нетронутым, а вот доступ к софту фактически перекрыли.

⚪️ Не качаются инструменты и релизы.
⚪️ Ломается автоматика: go install, pip и прочие менеджеры пакетов, которые тянут зависимости напрямую из VCS, просто вылетают с ошибками тайм-аута.

Решения:

⚪️ Чтобы ваша разработка не встала, можно поднять прокси-сервер.
⚪️ Через VPN также всё работает. С большой вероятностью подтверждается теория о локальных «фильтрах».
⚪️Для команд и компаний - поднять внутренний mirror зависимостей (Nexus, Artifactory, Harbor): проксирует GitHub Releases, npm, PyPI, Docker Hub через себя и кеширует артефакты. Разово настраивается, дальше CI/CD работает даже при очередной «фильтрации», плюс ускоряются сборки.​​​​​​​​​​​​​​​​

Открыли комменты, чтобы понять, насколько масштабное это «затмение». Пишите, как у вас 👇

@DevOpsKaz 😛

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

⚪️ RootlessKit

Инструмент для запуска контейнеров без root-прав. Он создает изоляцию и видимость мнимого root, уберегая ОС хоста от потенциальных угроз и атак через контейнеры.

⚪️ Vesparian

Сервис для обнаружения API endpoints с помощью анализа «живого» HTTP-трафика. После анализа он генерирует спецификацию. Умеет REST API Discovery, WSDL/SOAP Discovery, Headless Browser Crawling, Traffic Import.

⚪️ gh dash

Расширение для GitHub CLI, которое трансформирует терминал в дашборд с PR и issue. Секции можно настроить под нужные репозитории и фильтры.

⚪️ lazygit

Интерактивный интерфейс для Git со стейджингом по строкам, разрешением конфликтов, работой с ветками и interactive rebase. Все работает через хоткеи.

@DevOpsKaz 😛

🔥 6 проектов, которые прокачают ваш DevOps, если у вас мало практики

Проекты на AWS:

⚪️ Контейнеризация веб-приложения на ECS через CI/CD — для новичков

- Суть: создать путь от исходного кода до Docker-образа и развернуть его в Amazon ECS.
- Ценность: вы осваиваете полный цикл поставки (CI/CD) в контейнерной среде, а не просто запуск одиночного сервера.
- Гайд: https://www.youtube.com/watch?v=4xd1eM6Js60

⚪️ Развертывание EKS-кластера (Kubernetes) через Terraform — уровень Intermediate

- Суть: использование Infrastructure as Code (IaC) для управления оркестрацией.
- Ценность: в индустрии никто не кликает мышкой в консоли AWS, чтобы создать кластер. Этот проект учит профессиональному подходу к управлению K8s.
- Гайд: https://www.youtube.com/watch?v=LZssMfdJSeM

Проекты на Azure:

⚪️ End-to-End инфраструктура с Terraform и Azure — уровень Intermediate

- Суть: связать внешний инструмент (Terraform) и нативный сервис (Azure DevOps) для управления ресурсами.
- Ценность: демонстрирует работу в стиле Enterprise — как крупные компании автоматизируют облако Azure.
- Гайд: https://www.youtube.com/watch?v=hj5gbhSmftE

⚪️DevOps в реальном времени с использованием GitOps — от новичка к продвинутому

- Суть: внедрить методологию GitOps (вероятно, с использованием ArgoCD или Flux) внутри экосистемы Azure.
- Ценность: так выглядит современная автоматизация, когда состояние облака синхронизировано с Git-репозиторием.
- Гайд: https://www.youtube.com/watch?v=dmGW22W3VOs

Проекты на Google Cloud (GCP):

⚪️ CI/CD через Cloud Build и Cloud Deploy для GKE — для новичков

- Суть: использовать нативные инструменты Google для автоматизации релизов в Kubernetes.
- Ценность: поучитесь использовать экосистему Google «из коробки», что важно для проектов, завязанных на GCP.
- Гайд: https://www.youtube.com/watch?v=L_1qbt-Iii0

⚪️ GitHub Actions + Terraform CI/CD на GCP — уровень Intermediate

- Суть: создать пайплайн в GitHub для автоматического управления ресурсами Google через Terraform.
- Ценность: это самый популярный в стартапах стек — автоматизация через GitHub Actions.
- Гайд: https://www.youtube.com/watch?v=0PwvhWa3OOY&list=PLLrA_pU9-Gz0oXg8ccnHjfowKXxxud8P9&index=4

@DevOpsKaz 😛

🔥 Вакансия в CORE 24/7 для специалистов технической поддержки (L1-инженеров)

Одного нашли, нужен второй 😏

Компания Core 24/7 — лидер в сфере DevOps-аутсорсинга Средней Азии. Мы растем, и для развития первой линии технической поддержки ищем начинающих специалистов. Прокачаетесь на практике — и двери в DevOps станут открыты.

Алматы, офис
Заработная плата: до 200 000 тг.
Можно без опыта
График: сменный (1/3, с 8:00 до 20:00)
Испытательный срок: 3 месяца

❗️ Cамый главный профит — это отличный старт карьеры бок-о-бок с командой, которая делает DevOps для госсектора, стартапов и IT-гигантов Средней Азии.

⚪️Задачи:

• Регистрация и обработка обращений пользователей в системе заявок
• Разрешение инцидентов и поддержка пользователей по регламентам
• Подготовка и ведение документации: инструкции для решения проблем
• Мониторинг дашбордов и управление алертами для выявления критических изменений
• Обработка запросов, эскалация критических инцидентов при необходимости
• Своевременная реакция в чатах и обратная связь клиентам в течение 15 минут

⚪️Требования:

• Базовые знания ОС Linux и администрирования IT-инфраструктуры
• Умение работать в стрессовых ситуациях и принимать решения
• Грамотная устная и письменная речь
• Готовность к сменному графику работы
• Умение быстро находить информацию для решения задач (google, stack overflow, chatgpt)
• Желание обучаться и развиваться

⚪️Приветствуется, но не обязательно:

• Техническое образование (высшее, средне-специальное или среднее).
• Опыт работы с GitLab/GitHub CI/CD
• Знания AWS, Ansible или Kubernetes
• Навыки настройки SSL и работы с сетевым оборудованием

⚪️Мы предлагаем:

• Обучение с нуля и постоянное наставничество
• Программы повышения квалификации в сфере SRE/DevOps
• Сертификацию по ключевым направлениям (Kubernetes, AWS, Red Hat и др.)
• Компенсацию за тренажерный зал
• Премии за успешную работу
• Регулярные тимбилдинги
• Возможности для профессионального и карьерного роста

Если вы хотите расти в ИТ и стать частью команды профессионалов, отправляйте свое резюме. Мы ждем вас!

Писать сюда:

👈 aissabekova@core247.io
👈 @issaika

⚡️ AI Qadam Uzbekistan: первый офлайн-митап — 25 апреля, Ташкент, IMPACT.T Innovation Hub

25 апреля в Ташкенте пройдёт первый офлайн-митап сообщества AI Qadam Uzbekistan — независимой платформы для обмена опытом и кейсами применения ИИ в бизнесе и повседневной жизни

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

Спикеры и темы:

- Алексей Кулагин, 20+ опыта разработки, расскажет о том, как проверил гипотезу за 5$ и случайно создал нужный инструмент для любой первой линии поддержки
- Антон Устинов, IT-архитектор с глубоким опытом в финтехе и банкинге, расскажет о внедрении ИИ агентов в AML-процессы
- Live-воркшоп «ИИ в хакинге и безопасности».

Для всех, кому интересна тематика ИИ, кто хочет получить или передать опыт.

👈 Регистрация

📍 IMPACT.T Technology Hub
25 Апреля, 2026, 13:00-15:00 по Ташкенту
Добавить в Google-календарь

@DevOpsKaz 😛

🔥 Как переложить code review с разработчиков на LLM

Ревью кода часто тормозит выпуск фичей, особенно в маленьких командах, где разработчик берет на себя сразу несколько ролей. А при тысячах PR в неделю это создаёт большую нагрузку и на большую команду. Но что если поручить задачу LLM? И какого качества вообще ожидать?

Инженер Авито рассказал, как они справлялись с этой задачей у себя.

👈 Читать статью

Что внутри:

⚪️Причины для автоматизации процесса Code review
⚪️Архитектура системы Code review
⚪️Выбор LLM-модели
⚪️Этапы ML-пайплайна
⚪️Метрики решения

Спойлер: Qwen3-Coder-30B-Instruct-FP8 показала хорошие результаты по метрикам.

Как правильно отметили в заключении — скидывать процесс на AI и оставлять его без надзора нельзя. Передать рутину роботу хорошо и правильно, но контролировать процесс всё равно должны люди.

@DevOpsKaz 😛

🔥 Как выстроить сбор телеметрии в микросервисной системе

Микросервисная архитектура решает проблему масштабируемости, но почти всегда создает новую — потерю прозрачности. Сложнее понять, что произошло во время запроса, чем исправить саму ошибку. Логи не дают общей картины, метрики — деталей. Один запрос может пройти через десяток сервисов и очередей, API и фоновые процессы. Искать источник ошибки без полноценной трассировки долго или ОЧЕНЬ долго.

В таких случаях на помощь приходит наблюдаемость на базе OpenTelemetry и анализа трейсов в Sentry / Jaeger.

Вот как можно реализовать наблюдаемость:

⚪️ OpenTelemetry Collector как промежуточный слой для сбора телеметрии
⚪️ Трейсы идут в Sentry, метрики — в Prometheus, алерты — в Grafana
⚪️ Сервисы работают только с OpenTelemetry
⚪️ ...

👈 Подробнее в статье

@DevOpsKaz 😛

⚡️ AppSecFest 2026 уже близко

📍 15 мая в Алматы в Farabi Hub пройдет уже четвертая конференция на стыке разработки, DevSecOps и безопасности.

Спикеры — эксперты из DerScanner, Sonatype, IBM, RTEAM, Semrush (Adobe), Beeline и независимые практики индустрии.

Что вас ждет:

— Реальные уязвимости, живые атаки и Red Team-кейсы от тех, кто в теме 24/7
— Нетворкинг с людьми, которые двигают AppSec и DevSecOps в регионе
— Интерактивы, активности на площадке и подарки от партнёров: DerScanner, Sonatype, RTEAM, MUK + IBM, FCBK и Halyk Kazteleport

Приходите учиться, знакомиться и становиться частью комьюнити!

👈 Регистрация

@DevOpsKaz 😛

🔥 Новости мира DevOps, которые вы могли пропустить

Про Kubernetes 1.36 мы уже писали ранее, тут оставим полный changelog.

⚪️ kumo

Лёгкий эмулятор 70+ сервисов AWS для тестирования CI/CD. Предоставляет локальную среду для тестирования приложений, использующих AWS, без необходимости подключаться к реальному облаку или платить за ресурсы. Быстрая и простая альтернатива популярному LocalStack. Запускается почему мгновенно.

⚪️ Cardamon

Аудитор метрик для Prometheus / Grafana. Находит метрики в вашей TSDB, которые никогда не запрашиваются дашбордом, правилами оповещений и записи или чем-либо еще. Ценен тем, что можно сразу сгенерировать правила удаления метрик. Освобождаем хранилище за пару кликов.

⚪️ Библиотека промптов и агентов от AWS

Amazon выкатил разработанный экспертами сборник, где можно найти промпты и агентов для различных вариантов использования: от отдельных веб-приложений до сложных микросервисов. Лучшие практики помогут встроить все это дело в архитектуру AWS.

⚪️ Traceway

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

@DevOpsKaz 😛

🔥 Тот самый джун: устроил катастрофу, сказал «сорян» и уволился

Классику джунов сегодня отрабатывает наш верный помощник — ИИ.

➖ Cursor на базе Claude Opus 4.6 за 9 секунд удалил всю базу компании

Агент «починил» доступ и снес продакшн. Улетели базы клиентов, броней и платежей, а также бэкапы. Разработчики PocketOS ставили задачи в в тестовой среде, но при ошибке доступа он нашел API-токен, после чего отправил запрос на удаление. Восстановиться удалось спустя сутки — по резервной копии трёхмесячной давности.

...Вспоминаем, были ли еще подобные инциденты...

➖ Инженеры положили часть AWS после совета ИИ

В декабре ИИ предложил инженерам удалить и заново развернуть прод для исправления проблем с конфигами — те одобрили, после чего система начала автоматические изменения инфраструктуры. Но по классике все пошло не так, что привело к масштабным сбоям в облачных сервисах. Исправляли 13 часов.

➖ Инцидент в системе безопасности Meta

В марте сотрудники Meta почти на 2 часа получили несанкционированный доступ к данным из-за ИИ-агента. Тот опубликовал ответ в открытом доступе на запрос, не получив предварительного одобрения. Ответ должен был быть показан только сотруднику, который его запросил, а не стать достоянием общественности. До этого (видимо тот же бро на OpenClaw) массово удалял письма, проигнорировав команды на остановку.

➖ ИИ вместо кэша стёр весь диск

В конце 25 года разработчик рассказал, что Google Antigravityпо его просьбе удалить временные файлы решила иначе и вынесла целую корневую директорию на диске D. После операции модель вежливо извинилась и уведомила, что «идёт спать, квота достигнута».

Какой вывод напрашивается: даже с ограничениями ИИ могут выполнять разрушительные действия без контроля. То, что кажется мелочью на одном ПК, может стать катастрофой в масштабе компании. Человек с критическим мышлением и здоровой опаской нужен как никогда. И прежде, чем передавать инструкции, важно учесть даже самые невероятные сценарии. И да, не хранить бэкапы там же, где лежит основная ифра. Инженера по эксплуатации ПО могут спать спокойно - работы по восстановлению хватит всем :)

@DevOpsKaz 😛

⚡️ Бесплатные обучающие материалы по Linux

У многих из нас есть знакомые, которые хотят попасть в DevOps, но даже с Linux не знакомы. Может быть, эти люди есть и среди наших подписчиков — и этот пост для них.

⚪️ Основы GNU/Linux и подготовка к RHCSA

Курс часто рекомендуют как общепризнанную базу. Материал адаптирован для новичков и дополнен автором, за основу взято обучение по программе RHCSA.

⚪️ Курсы от Слёрм:

Администрирование ОС Linux. Лучшие практики работы в Linux — от администрирования до автоматизации: аспекты конфигурирования, автоматизации, безопасности и оптимизации систем, а также практика на виртуальных стендах.

Администрирование linux-серверов. Фундаментальные навыки администрирования Linux-систем, чтобы решать наиболее популярные проблемы с серверами.

Сети в Linux. Опыт сетевого администрирования на Linux, который можно адаптировать для работы в любой компании и в любом проекте.

⚪️ Learn the ways of Linux-fu

Серия хорошо оформленных и структурированных курсов по основам Linux в виде уроков с заданиями, ответы на которые проверяются автоматически. Рекомендуем заниматься на английском. От командной строки до сетей.

⚪️ Курсы от Stepik:

Linux CLI. Наиболее свежий курс по основам командной строки. Объём небольшой, на один вечер.

Архитектура параллельных вычислительных систем. Курс о настройке apache, nginx, iptables, bind9 (dns), nfs, samba, docker.

@DevOpsKaz 😛

⚡️ Early bird цена на главную IT-конференцию весны продлена!

23 мая в Алматы пройдет шестая beetech conf — одна из крупнейших IT-конференций Казахстана, которая ежегодно собирает 1000+ участников.

24 доклада, личные консультации с ведущими экспертами, квартирники на острые темы и формат Epic Fails микрофон, где разбирают реальные ошибки и решения, которые из них выросли.

Главная тема этого года — как AI уже встроен в инженерную и управленческую практику и что происходит, когда он выходит в продакшн: ускоряет процессы, меняет команды и иногда ломает привычные подходы.

Спикеры:

⚪️ международный эксперт Илья Красинский (CEO Rick.ai, Product Heroes)
⚪️ Арман Сулейменов (nFactorial)
⚪️ представители американской Riot Games
⚪️ специалисты из Kolesa Group, Freedom Holding, BeelineКазахстан, QazCode, Moon AI, Яндекс.Практикум и других КЗ компаний.

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

❗️ Билеты до 1 мая — 12 150 тг в приложении Freedom с кэшбэком вместо 20 тыс. тг.

Организаторы (Beeline и QazCode) также подготовили лотерею и ценные призы.

@DevOpsKaz 😛

🔥 Ubuntu 26.04 LTS: на что смотреть перед миграцией

Мы уже писали про выход Linux 7.0, ядро которого будет использоваться в Ubuntu 26.04 LTS. Просто запустить обновление и уйти на обед не получится, так как многие системы могут не подняться из-за несовместимости конфигураций. По возможности лучше использовать чистую установку или тщательно тестировать обновление на стейджинг-серверах.

Перед обновлением обязательно проверьте следующие пункты:

⚪️cgroup v1 удален: если вы используете старые версии Docker, LXC или специфические скрипты мониторинга, которые ищут /sys/fs/cgroup/memory и т.д., они сломаются. Проверьте текущий режим: mount | grep cgroup.

⚪️Временные файлы (/tmp): теперь это tmpfs. Всё содержимое /tmp хранится в оперативной памяти и исчезает при перезагрузке. Если ваши приложения пишут туда гигабайты логов или кэша, это может «съесть» всю RAM.

⚪️Rust Coreutils: хотя ls и cat теперь на Rust, старые версии доступны под именами gnuls, gnucp и т.д. Проверьте свои скрипты на предмет парсинга вывода этих команд — форматирование может минимально отличаться.

⚪️OpenSSH 10.2. DSA-ключи полностью не поддерживаются. Проверьте ~/.ssh/authorized_keys и known_hosts.

⚪️Переменные окружения: файл ~/.pam_environment больше не читается. Перенесите настройки в .bashrc или /etc/environment.

⚪️Sudo-rs: по умолчанию используется Rust-версия. Если у вас сложные конфиги sudoers с кастомными плагинами, они могут не заработать. Классический sudo доступен как sudo.ws.

⚪️Dovecot 2.4: конфигурационный формат изменился настолько, что старые файлы несовместимы. Понадобится ручная миграция конфигов по официальному гайду.

⚪️Postfix 3.10: по умолчанию работает вне chroot. Если ваша модель безопасности полагалась на chroot-изоляцию Postfix, ее нужно перенастраивать.

⚪️Squid 7.2: сервис не поднимется, если в конфиге остались директивы client_delay_access, ftp_epsv, client_persistent_connections или server_persistent_connections. Удалите их заранее.

⚪️Chrony: стал стандартом для времени. Для существующих систем (обновляемых с 24.04) миграция на него не автоматическая. Нужно установить его вручную (apt install chrony), иначе останется старый systemd-timesyncd.

⚪️APT 3: команда apt-key удалена. Если ваши скрипты установки ПО используют apt-key add, они перестанут работать. Ключи теперь должны лежать строго в /usr/share/keyrings.

⚪️PostgreSQL 18: обладает новой I/O-подсистемой. Обещают прирост скорости до 2 раз, но мажорное обновление базы всегда требует бэкапа и запуска pg_upgrade.

⚪️Samba: если вы используете роль Active Directory DC, обязательно установите пакет samba-ad-dc до начала обновления, иначе роль AD перестанет функционировать.

⚪️SSSD: теперь работает от пользователя sssd, а не от root. Проверьте, есть ли у этого пользователя права на чтение ваших keytab файлов и сертификатов.

@DevOpsKaz 😛

⚡️ PROFIT Telecom Day — 29 мая

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

👈 Регистрация открыта (перенесли с 22 мая на 29-ое)

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

➖ спутниковую связь и магистральные каналы
➖ городскую канализацию
➖ мобильную связь, 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 😛