🔥 Третий спикер Cloud Native Community Day 3 апреля — Иван Кабанов, Solutions Architect, Yandex Cloud

Тема доклада: О чем мы говорим, когда говорим об Observability

В докладе Иван разберет, что на практике означает Observability и почему классический стек из разрозненных инструментов (Prometheus, лог-агенты, трейсинг) перестаёт справляться с ростом сложности систем. Поговорим про три столпа — мониторинг, логгинг и трейсинг — и как объединение телеметрии в едином контексте помогает быстрее находить причины инцидентов и работать с SLO.

Разберём, как устроена Observability Platform в Яндексе: какие архитектурные решения позволяют работать с метриками, логами и трейсами в одной системе без ручной «склейки», и как выглядит пайплайн сбора и обработки телеметрии на базе OpenTelemetry.

Отдельно обсудим мониторинг AI/LLM-агентов: какие данные попадают в трейсы и как с помощью OpenTelemetry наблюдать поведение агентов — от латентности и ошибок до качества ответов.

Мероприятие пройдёт при поддержке Yandex Cloud Kazakhstan в их алматинском офисе на крыше.

Мест уже нет, но мы обязательно поделимся докладами с сообществом. Следите за новостями — скоро будем делать более масштабные митапы.

@DevOpsKaz 😛

🔥 Какое облако выбрать для бизнеса в Казахстане?

Мы в Core 24/7 провели независимое исследование — и создали гайд, который поможет сориентироваться на рынке облачных провайдеров (отечественных и зарубежных). Заходите, смотрите, сохраняйте в закладки 🫡

👈 Смотреть гайд

Руководство интерактивное — можно выбрать для сравнения 2 или более провайдера или сразу все.

Что внутри:

⚪️Обзор ключевых характеристик
⚪️Сравнение по возможностям и сервисам
⚪️Сценарии применения
⚪️Примерная стоимость

Core 24/7 — сертифицированный партнёр AWS, Azure, GCP, Yandex Cloud, VK Cloud и Oracle Cloud в Казахстане. Мы помогаем бизнесу выбрать облако под их задачу, мигрировать и настроить с максимальной эффективностью.

@DevOpsKaz 😛

🔥 Cloud Native Community Day — уже завтра

Мероприятие пройдёт при поддержке Yandex Cloud Kazakhstan в их алматинском офисе на крыше. Ждем по адресу 3 апреля к 17:00.

Первый спикер — Мирас Байгашев, «Ingress умер, да здравствует Gateway API»

Второй спикер — Абдухаликов Асир, «CNI в Kubernetes, ценность Cilium и как с ним работать»

Третий спикер — Иван Кабанов, «О чем мы говорим, когда говорим об Observability»

⚪️ Расписание:

17:00-17:30 — регистрация гостей + кофе-брейк
17:30-18:10 — спикер 1 + вопросы
18:10-18:50 — спикер 2 + вопросы
18:50-19:30 — спикер 3 + вопросы
19:30-21:00 — афтепати на крыше с пиццей

🎟️ Ждем всех, кто зарегистрировался ранее.

@DevOpsKaz 😛

🔥 Как OpenAI масштабировала систему мониторинга, чтобы справиться с ростом нагрузки

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

⚪️Выбору правильных инструментов
⚪️Жесткой оптимизации
⚪️Отношению к мониторингу как к сервису, который должен быть удобным и эффективным для каждого в компании

Когда ChatGPT стал популярным, OpenAI столкнулась с проблемой: их система мониторинга на базе Prometheus начала давать сбои под весом миллиардов временных рядов (time series).

Что предприняла компания:

➖ Переход на VictoriaMetrics, которая оказалась более эффективной в использовании дискового пространства и ОЗУ по сравнению с альтернативами.

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

➖ Если разработчикам сложно строить графики или понимать алерты, система бесполезна. Команда Observability упростила процесс добавления новых метрик, сохранив при этом контроль над их качеством.

➖ Компания осознала, что хранить все данные — слишком дорого и неэффективно. Те метрики, к которым никто не обращался в течение 30 дней, можно безболезненно удалять или перестать собирать.

➖ Использование сэмплирования для логов и трассировок, потому что просто нет нужды сохранять 100% запросов в системе трассировки при таких масштабах. Достаточно сохранять небольшую часть успешных запросов и 100% ошибок.

👈 Читать детальный разбор

@DevOpsKaz 😛

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

⚪️ Terragrunt v1.0

Из беты вышел уже популярный open-source инструмент, который представляет собой «тонкую обертку» для Terraform. Terragrunt помогает масштабировать управление IaC, делая код более чистым, поддерживаемым и соответствующим принципу DRY.

⚪️ Tekton стал incubating проектом в CNCF

Это набор готовых инструментов для систем с CI/CD. Tekton помогает строить, тестировать и развертывать в облаках или on-premise. Работает внутри кластеров Kubernetes и не нуждается в физическом сервере.

⚪️ Атака на Trivy — еще не конец

Последствия прошлой атаки все еще ощущаются. Технологические гиганты подвергаются атаке со стороны компрометированного Trivy GitHub Action. На днях злоумышленники похитили исходный код компании Cisco.

@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

🔥 Сервер алертов в бинарнике на 23 МБ

Мы знаем, что многие мечтают о self-hosted платформе для алертов и командного общения специально для DevOps/SRE-команд. Готовые решения (Mattermost, Matrix, Gotify, ntfy) требуют слишком много инфраструктуры, либо не дают ACK (подтверждения), либо приходится переписывать ботов под себя.

Представляем Pusk — работает на своём сервере, без внешних зависимостей.

Особенности:

➖ принимает алерты из мониторинга
➖ позволяет их подтверждать одной кнопкой (и автоматически глушит в Alertmanager)
➖ шлёт push-уведомления даже когда браузер закрыт
➖ имеет встроенный командный чат
➖ миграция существующих ботов — буквально одна строка кода.

Pusk сам определяет способ доставки: webhook, relay или очередь getUpdates. Работает и без внешнего интернета. Единственное исключение — Web Push.

В итоге получился алертинг с ламповым чатиком: принял webhook, показал дежурному, дал нажать ACK, коллега принял. Один бинарник, без внешних сервисов, частично совместим с Telegram Bot API (13 методов из 80+).

👈 Посмотреть на GitHub

Пользуйтесь и делитесь с коллегами 🫡

@DevOpsKaz 😛

⚡️ AppSecFest 2026 — крупнейшая конференция по безопасности приложений уже 15 мая

📍 Алматы | Farabi Hub

Уже в третий раз AppSecFest собирает в одном зале инженеров, DevSecOps-практиков, разработчиков и лидеров IT, чтобы говорить о реальных вызовах безопасности и находить решения, которые работают в продакшене.

Что вас ждет:

➖ реальные кейсы DevSecOps и AppSec
➖ разборы атак, уязвимостей и инженерных решений
➖ инструменты и подходы, которые можно внедрить сразу
➖ живое IT-комьюнити и нетворкинг с сильнейшими специалистами рынка
➖ интерактивы и активности на площадке

💥 подарки от партнеров: Derscanner, MUK:IBM, Sonatype, R-team

👈 Зарегистрироваться

@DevOpsKaz 😛

🔥 Инженер-дирижёр: что реально изменилось с приходом ИИ

Компания Диасофт собрала CTO, DevOps-инженеров и операционных директоров — и спросила: что работает, что нет, и в кого превращается инженер. Вот ключевые мысли.

⚪️ ИИ = воодушевлённый джун, который прочитал тонну кода. Типовые задачи можно отдавать смело. Редкие фреймворки, нетиповая архитектура — ИИ тормозит процесс, а не ускоряет.

⚪️ Конвейер важнее модели. Мы отходим от представления «ИИ делает разработку» в сторону «правильной специализированной модели на каждом этапе конвейера». Юнит-тесты — одна модель, документация — другая, расшифровка встречи с заказчиком — третья.

⚪️ Высоконагруженный продакшен лучше не трогать. Для внутренних инструментов, где падение сервисов не позорит нас перед клиентами ИИ меняет многое. Для внешних prod-систем риски пока не оправданы.

⚪️ ИИ про прошлое. Он знает то, что уже было. Инженер нужен, чтобы думать про то, чего ещё нет: закладывать последствия, предугадывать нестандартное поведение, проектировать логику наперёд.

⚪️Порог входа не снизился — сместился. Раньше нужно было уметь писать код. Теперь нужно уметь управлять оркестром агентов: чувствовать, где модель уйдёт в галлюцинации, где срежет угол, где вообще не применима.

⚪️ «Доверяй, но проверяй» — не метафора. Представьте, что автопилот для малой авиации собрали с помощью ИИ — и вроде работает. Поставили бы на самолёт без проверки? Нет. Также и в нашей сфере.

А вот что на эту тему думает Ильяс Мустафин, СТО JetFinance:

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

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

И это уже видно в работе. Команды легко генерируют новые фичи, потому что «это легко автоматизировать». А через месяц выясняется, что поддерживать никто толком не готов. Техдолг растет так же быстро, как и объем кода.

@DevOpsKaz 😛

🔥 Доклады с Cloud Native Community Day 3 апреля

3 апреля мы провели четвертый митап в рамках инициативы Cloud Native — готовы поделиться докладами с вами.

⚪️Мирас Байгашев, «Ingress умер, да здравствует Gateway API»
⚪️Абдухаликов Асир, «CNI в Kubernetes, ценность Cilium и как с ним работать»
⚪️Иван Кабанов, «О чем мы говорим, когда говорим об Observability»

Фото с мероприятия здесь.

Следите за новостями — следующий митап уже скоро.

@DevOpsKaz 😛

🔥 Vault: секреты, которые администратор прочитать не может

У HashiCorp Vault есть фундаментальная проблема, о которой редко говорят вслух: администратор может прочитать любой секрет, к которому имеет доступ хоть кто-то ещё. Да, есть аудит-логи. Но только если за ними следят, и только если их не выключили.

Казалось бы, решение простое — хранить конфигурацию доступов в Git, проводить ревью и применять через CI/CD. На практике это иллюзия безопасности:

➖ Администратор GitLab может изменить список апруверов
➖ Владелец репо может сделать force push без ревью
➖ Если CI-система имеет токен на изменение конфигурации Vault, достаточно найти этот токен — и вы внутри

Всегда есть один человек или один сервис, компрометация которого даёт полный доступ.

❗️Есть и правильное решение — Vault умеет управлять собой изнутри.

Вот как работает подход:

⚪️Конфигурация хранится в Git как Terraform-файлы
⚪️Коммиты подписываются несколькими PGP-ключами через Git Notes — это кворум
⚪️Vault-плагин периодически проверяет репозиторий и применяет конфигурацию только если подписей достаточно
⚪️Токен доступа к Vault хранится внутри самого Vault как «неизвлекаемый» секрет — никакой CI его прочитать не может
⚪️State Terraform хранится тоже внутри плагина — никакого внешнего S3 не нужно

В итоге: ни у CI, ни у «администратора» нет привилегированного доступа снаружи. Изменить конфигурацию можно только через коммит с кворумом валидных подписей.

👈 Плагин — open source
👈 Полная статья с примерами конфига и кода — на Хабре

@DevOpsKaz 😛

🔥 Kubernetes 1.36 выходит 22 апреля — что меняется

⚪️ Долгожданные изменения для AI/ML-нагрузок

Группы взаимосвязанных подов теперь трактуются как единая сущность — workload-aware preemption. Если один под из ML-задачи вытесняется, вся группа либо держится, либо уходит вместе. Больше не будет ситуации, когда половина distributed training job висит без ресурсов и жжёт деньги.

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

⚪️ DRA продолжает взрослеть

Из новых alpha-фич: видимость доступности ресурсов через ResourcePoolStatusRequest — наконец можно узнать, сколько GPU свободно, без парсинга ResourceClaims по всем неймспейсам. Плюс поддержка списков атрибутов: драйвер теперь может описать устройство с несколькими PCIe-корнями, а не только скалярными значениями.

⚪️ Schedulability по CSI — важно для stateful

Новая фича запрещает шедулинг пода на ноды, где нет нужного CSI-драйвера. Ни одна stateful-нагрузка не попадёт на ноду, которая не сможет примонтировать нужный том.

⚪️ HPA наконец умеет масштабировать до нуля

Фича HPAScaleToZero, которая ждала своего часа с Kubernetes v1.16, в v1.36 включается по умолчанию. Staging и тестовые окружения теперь можно гасить полностью, без idle-подов.

⚪️ Безопасность образов

Kubelet переходит на ephemeral-токены для аутентификации при pull-е образов вместо статических секретов — короткоживущие, автоматически ротируются, привязаны к identity пода.

Полный разбор 20 новых alpha-фич — у Palark

@DevOpsKaz 😛

🔥 Приглашаем на ИТ-конференцию beetech conf 2026 — 23 мая

Стартовали продажи билетов на ежегодную ИТ-конференцию beetech conf 2026, которая объединит представителей технологического сообщества со всего Казахстана. Мероприятие соберет разработчиков, инженеров и специалистов, заинтересованных в развитии современных технологий и обмене практическим опытом.

🎟️ Первые билеты уже доступны по цене early bird — от 15 000 тенге.

В программе 24 доклада:

⚪️почему AI в компаниях часто «не взлетают»
⚪️как ИИ-агенты помогают в бизнесе
⚪️какие подходы реально меняют разработку
⚪️какие кейсы меняют поведение пользователей и прочее

Среди спикеров представители геймифицированного фитнес-стартапа Hero’s Journey, американской компании Riot Games, а также крупных ИТ-компаний, включая Kolesa, Beeline Казахстан, QazCode и другие.

Организаторы также подготовили:

➖ speed-менторинг — короткая личная консультация с лидерами индустрии. В прошлом году все слоты разобрали за 30 минут.
➖ «квартирники» — честные и иногда жесткие разговоры без фильтров. На предыдущих ивентах были подняты темы цифрового развития в регионах, экспорт ИТ-услуг на международные рынки
➖ Epic Fails микрофон — истории про факапы, о которых обычно молчат
➖ и мощный нетворкинг на 1000+ человек, где можно найти не только контакты, но и новые возможности

Стоимость участия будет увеличиваться — не упустите возможность купить дешевле.

👈 Купить билет

Организаторы: QazCode, DAR Tech и Beeline.

@DevOpsKaz 😛

🔥 Сегодня стартует бесплатный курс — подготовка к AWS Certified Developer – Associate

Курс полностью практический: более 10 реальных заданий, где вы будете руками работать с сервисами AWS и в итоге соберёте полноценное облачное приложение. Единственное — обучение на английском языке.

Вот основные темы:

⚪️ Введение в облака и AWS (IAM, CloudWatch, IaC и т.д.)
⚪️ Развёртывание SPA-приложений (S3 + CloudFront)
⚪️ Serverless API (Lambda + API Gateway)
⚪️ Работа с NoSQL (DynamoDB)
⚪️ Глубокая работа с S3 (хранение, события, интеграция)
⚪️ Асинхронное общение микросервисов (SQS + SNS)
⚪️ Авторизация (Cognito + Lambda Authorizer)
⚪️ SQL-базы в облаке (RDS)
⚪️ Контейнеризация (Docker + Elastic Beanstalk)
⚪️ Backend-for-Frontend (BFF) паттерн

В конце — финальный проект. Подготовитесь к экзамену AWS Certified Developer – Associate и сможешь применять навыки на реальной работе.

Продолжительность — 10 недель
Старт: 13 апреля

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

@DevOpsKaz 😛

🔥 MCP-серверы для вашего DevOps-стека

Перевод DevOps инструментов на рельсы MCP — это мощный сдвиг, который превращает ИИ из «советчика» в полноценного оператора. Вместо того чтобы «скармливать» ИИ простые текстовые логи, мы даем ему прямой доступ к API через стандартизированный протокол.

DevOps MCP-стек:

⚪️ Основная инфраструктура / IaC

Terraform MCP Server, Pulumi MCP Server, AWS MCP Server, Azure MCP Server, а также решение вроде Spacelift Intent для политико-ориентированных workflow. Всё это становится «единым мозгом» для изменений инфраструктуры вместо разрозненных скриптов.

⚪️ Контроль версий / Dev Platform

GitHub MCP Server и GitLab MCP Server — чтобы агенты могли создавать pull request’ы, анализировать diff’ы, оставлять комментарии в пайплайнах и полностью замыкать процессы на GitOps.

⚪️ CI/CD и автоматизация пайплайнов

Jenkins MCP Server, Azure DevOps MCP Server, ArgoCD MCP Server и FluxCD MCP Server. Пайплайны перестают быть «чёрными ящиками» и становятся доступными для запросов, анализа и исправлений напрямую через MCP.

⚪️ Kubernetes / Контейнеры

Kubernetes MCP Server + Docker Hub MCP Server и Lens MCP Server. Теперь ИИ-агент может самостоятельно проверить поды, откатить деплоймент или отладить падающий сервис — без необходимости рыскать по пяти разным дашбордам.

⚪️ Наблюдаемость / Мониторинг

Prometheus MCP Server, Grafana MCP Server, Datadog MCP Server. Вы переходите от вопроса «где ссылка на дашборд?» к запросу «объясни, почему выросла latency после последнего деплоя, и свяжи это с конкретным PR».

⚪️ Безопасность, compliance и секреты

HashiCorp Vault MCP Server (через HashiCorp-экосистему), Snyk MCP Server и Trivy MCP Server, Prowler MCP Server, Wiz MCP Server. Проверки безопасности становятся первоклассными вызываемыми инструментами в каждом workflow, а не запоздалым дополнением.

Общий принцип для всего стека: выносите каждую возможность в виде MCP Server → объединяете их в единый согласованный интерфейс агентов → позволяете ИИ взять на себя рутинную интеграционную логику, чтобы люди могли сосредоточиться на архитектуре, надёжности и безопасности.

@DevOpsKaz 😛

⚡️ Yandex Cloud Data Day пройдёт в Алматы

29 апреля эксперты Yandex Cloud расскажут о том, как перенести CRM, 1С, сайты и базы данных в облако быстро, легко и без лишних затрат.

В программе мероприятия:

⚪️ Автоматизация продаж, учёта и работы с клиентами на базе 1С: как упростить ключевые процессы и снизить операционную нагрузку
⚪️ Стабильная работа бизнес-приложений: как выстроить инфраструктуру без сбоев и простоев
⚪️ Управляемые базы данных PostgreSQL и MySQL: как работать без администрирования и рисков потери данных
⚪️ Облачная инфраструктура без IT-штата: как снизить нагрузку на команду и упростить поддержку
⚪️ Запуск 1С в облаке: как развернуть и поддерживать систему без сложной настройки
⚪️ PostgreSQL в Yandex Cloud: как обеспечить производительность и отказоустойчивость для бизнес-приложений
⚪️ WordPress в облаке с MySQL: с рекомендованными настройками безопасности, SSL-сертификатами, резервным копированием и отказоустойчивостью
⚪️ Готовая инфраструктура для сайтов и бизнес-приложений: как запускать проекты за минуты, а не за недели

Мероприятие будет полезно владельцам бизнеса, ИТ-руководителям, 1С-специалистам, разработчикам, фрилансерам и интеграторам.

Участие бесплатное по предварительной регистрации по ссылке.

📍 Офис Yandex Qazaqstan (Алматы, проспект Аль-Фараби, 11/1)

@DevOpsKaz 😛

🔥 Первый стабильный релиз ядра Linux 7.0

Да, именно 7.0 — после 6.19 Линус просто устал считать большие цифры и решил «сбросить счётчик». Длинные номера версий его утомляют. Новая версия — это 15 624 патча от 2477 разработчиков (патч весит 56 МБ). Теперь ядро будет использоваться в Ubuntu 26.04 LTS.

Самое важное в обновлении:

➖ Rust — больше не эксперимент. Код на языке Rust в ядре официально лишился статуса экспериментального. Это важный шаг к повышению безопасности и стабильности системы
➖ Поддержка «железа» будущего. В ядро заложили фундамент для работы с процессорами Intel Panther Lake, Nova Lake и AMD Zen
➖ Умная файловая система. XFS теперь поддерживает автономное самовосстановление, а производительность записи в EXT4 заметно выросла
➖ Сетевой рывок. Значительно повышена производительность сети UDP благодаря новым механизмам встраивания функций
➖ Новый механизм фильтрации для io_uring
➖ И ещё тонна драйверов и оптимизаций

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

@DevOpsKaz 😛

🔥 Доклады с KubeCon EU + CloudNativeCon 2026

Подъехали записи докладов с европейского KubeCon — 408 видео в этом плейлисте на YouTube. Всё самое горячее, важное и интересное. Есть короткие и длинные выступления.

Также есть записи с мероприятий:

⚪️ ArgoCon Europe 2026 (31 видео)
⚪️ FluxCon Europe 2026 (10)
⚪️ Open Source SecurityCon 2026 (16)

Сохраняйте в закладки, возвращайтесь к посту при необходимости и делитесь с коллегами 🫡

У кого английский не очень, можно смотреть с синхронным переводом Яндекс.Браузера.

@DevOpsKaz 😛

🚀 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 😛