💛 Разбираем 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 😛

🔥 Сервисы на Rust

Автор объясняет, почему Rust — отличный выбор для средних по размеру backend-сервисов, несмотря на меньшую "продуктивность" по сравнению с Go. В Rust богатая система типов, проверки компилятора и zero-cost-абстракции избавляют от багов бизнес-логики.

В статье разбирается HTTP-стек Rust с tokio, hyper, axum для сервера, reqwest для клиента и tracing для наблюдаемости. Автор предлагает классическую трехуровневую архитектуру кода - HTTP/worker-слой, слой сервисов с бизнес-логикой и "тупой" repository-слой для работы с БД, где каждый слой общается только с соседним.

Автор также накидывает про фоновые задачи через очередь, крон-задачи, кэширование на уровне сервисов.

В целом, у Rust уже достаточно богатый стек для продакшен разработки.

Поддержать проект на boosty и читать в MAX

⚡️ От обычных гейтов в 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 😛

⚡️ Бесплатный офлайн-воркшоп KZ Data Community в Алматы — 27 августа

Спикеры:
⚪️ Екатерина Рехерт — «Ваш ИИ несёт чушь? Основы промпт-инжиниринга и Microsoft Copilot»
⚪️ Михаил Пасечный — «Не просто чат-бот: как Copilot и Claude встраиваются в data-workflow»

📅 27 августа, 19:00
Офис Beeline, пересечение Тимирязева × Ауэзова

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

👉 Регистрируйтесь по ССЫЛКЕ