🔥 Миграция микросервисов из одного namespace в другой без простоя

Ключевой процесс — сохранить старые DNS как точки совместимости. В старом namespace временно оставляем Service типа ExternalName, который перенаправляет запросы на сервис в новом namespace.

👈 Опираемся на гайд CNCF, чтобы узнать как мигрировать, за какие шаги и какие тонкости учесть.

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

⚪️ из payment в payments
⚪️ из общего namespace в namespace команды
⚪️ из временного namespace в production namespace
⚪️ между namespace разных окружений внутри одного кластера

Внутренний и внешний трафик нужно рассматривать отдельно: перенос Service сам по себе не решает проблему Ingress.

@DevOpsKaz 😛

⚡️ Как выстроить быстрорастущую AI-инфраструктуру для ритейла в облаке: опыт 4SELL

Летом 4SELL переехала в Yandex Cloud — всего за 3 недели и своими силами.

Сооснователь стартапа Роман Белопольский и архитектор Yandex Cloud Иван Кабанов рассказывают, какие потребности были у платформы и как выглядит финальная облачная архитектура, которая сейчас отвечает за обработку 100% транзакций.

Кратко: инфраструктура платформы построена на управляемых сервисах Yandex Cloud. Yandex Managed Service for Kubernetes® и Yandex Compute Cloud используются для запуска бэкенд-сервисов, API-серверов и компонентов обработки аудиопотоков. POS-транзакции, данные сотрудников, бонусы и метрики хранятся в Yandex Managed Service for PostgreSQL, а диалоги и результаты аналитики — в Yandex Object Storage. Аудиофайлы используют только для транскрибации и не хранят после обработки.

⚪️Отдельные сервисы отвечают за сбор метрик и журналов, изолированную сетевую инфраструктуру и защищённые каналы передачи данных, хранение образов приложений, управление SSL-сертификатами и балансировку нагрузки.

⚪️При этом всё хранится локально — в казахстанском ЦОД.

Сейчас валовая рентабельность платформы составляет 60%, а LTV/CAC превышает 3,95 и продолжает расти.

👈 Подробнее о кейсах клиентов и опыте переезда — в подкасте с Романом и Иваном.

⚡️ Полезные материалы по итогам доклада Мираса Байгашева «Правильный FinOps в современных superapp»

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

База и стандарты FinOps

⚪️FinOps Foundation — главный мировой хаб и сообщество по FinOps
⚪️FinOps Framework — фундаментальный фреймворк и лучшие практики
⚪️Спецификация FOCUS — открытый стандарт данных для биллинга и учета облачных затрат

Доклады и реальные кейсы компаний

⚪️Making Unit Economics Actionable — как сделать юнит-экономику рабочим инструментом для инженеров
⚪️Hybrid Cost Transparency on PlayStation — кейс Sony по обеспечению прозрачности гибридных затрат
⚪️Engineering Cost per Feature at Canva with OpenTelemetry — как Canva считает стоимость разработки отдельных фич с помощью OpenTelemetry
⚪️Extending FinOps to On-Prem (Target) — как ретейлер Target распространяет FinOps-практики за пределы облака на локальные дата-центры
⚪️Making FOCUS Work in Practice — опыт Elo по внедрению спецификации FOCUS для не-облачной инфраструктуры
⚪️Cloud Budget & Forecast Process (Atlassian) — как в Atlassian устроены процессы бюджетирования и прогнозирования облачных расходов
⚪️Anomaly Detection with Looker on Google Cloud — автоматическое обнаружение аномалий в аномальном росте затрат в GCP

Инструменты и решения

⚪️OpsMan AI — наш продукт для управления и оптимизации инфраструктуры (Документация OpsMan AI)
⚪️Kubecost — мониторинг и оптимизация расходов внутри Kubernetes
⚪️Infracost — оценка изменения стоимости инфраструктуры еще до применения terraform apply
⚪️Kube-green — снижение нагрузки и гашение ресурсов K8s в нерабочее время

Токеномика

⚪️Tokenomics Foundation — портал о проектировании и экономике токенов
⚪️Tokenomics Stack — пятиуровневая модель стека токеномики
⚪️Big-T Notation — формальный язык и нотация для описания токеномических систем

@DevOpsKaz 😛

🔥 Как смена SRE-работы похожа на смену самолёта

В авиации есть термин Type Conversion — процесс, когда опытный пилот пересаживается на новый тип самолёта. Он не учится летать заново: физика полёта та же, но кабина и тумблеры другие.

Билл Данкан (SRE-инженер и пилот) отлично перенёс эту концепцию на онбординг в новую DevOps/SRE-команду. Вот 4 правила, которые помогут не упасть в первый месяц:

1️⃣ Принципы не меняются

Аэродинамика одинакова для Cessna и Boeing. Бюджеты ошибок, контроль blast radius и дисциплина быстрых откатов не зависят от компании — вы приносите эти знания с собой в первый день.

2️⃣ Приборы те же, панель — другая

Скорость и высота отображаются везде. В прод-системах это Latency, Error Rate, Saturation (методы RED/USE). На новом месте меняется только табло: Datadog, Grafana или забытый дашборд. Задача первой недели — понять, где смотрят метрики и какие из них «врут» под нагрузкой.

3️⃣ Опасайтесь старой мышечной памяти

Вы умеете катить релизы. Но если прошлый опыт — это GitOps + ArgoCD, а в новой компании — ручной деплой через Jenkins, автопилот сыграет против вас. Ошибки в первый месяц происходят не от недостатка квалификации, а от применения старых привычек к новым рычагам.

4️⃣ Запоминайте критические цифры

В авиации есть V-speeds — специфичные для каждого борта критические скорости. Попытка зайти на посадку на параметрах другого самолёта приведет к катастрофе. В SRE это пороги онколла, целевые SLO, определение SEV1 и цепочки эскалаций. Их нужно выучить назубок из ранбуков и постмортемов еще до первого ночного дежурства.

Не пытайтесь в первые недели лететь «соло». Изучите системы, поспрашивайте опытных пилотов (инженеров) и не делайте выводов о переключателях, пока лично не проверите, за что они отвечают.

@DevOpsKaz 😛

🚀 Yandex Qazaqstan, Astana Hub и Alem ai Foundation открыли набор в ML School Kazakhstan на двухгодичную программу по машинному обучению
 
Что в программе:

⚪️ алгоритмы, Python, C++ или Rust, классическое машинное обучение
⚪️ deep learning: нейросети, трансформеры, генеративные модели и современные подходы к обучению
⚪️ специализации: NLP, компьютерное зрение, рекомендательные системы, речевые технологии, RL
⚪️ инженерный трек: CUDA, Go, распределённое обучение и оптимизация инференса
⚪️ проектная и исследовательская практика
 
Практическая часть программы включает встречи с ML-специалистами Yandex и других технологических компаний страны. Студенты будут разбирать примеры реальных систем, их архитектуру и логику.
 
Обучение будет проходить очно на базе alem ai в Астане 2-3 раза в неделю.
 
👈 Подать заявку на отбор можно до 8 октября 2026 года.

❗️ Требуется предварительно зарегистрироваться на платформе.
 
@DevOpsKaz 😛

⚡️ ИИ снес деплой: что делать?

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

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

В новой статье разбираем, как ограничить ущерб от автономных ошибок.

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

@DevOpsKaz 😛

🔥 Перестаньте будить дежурных из-за CPU > 80%

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

Предлагаем инженерный подход к дизайну алертов по принципам Google SRE от коллег:

⚪️ Почему алертить на нагрузку процессора или диск — плохая идея, и как ориентироваться на 4 золотых сигнала (Latency, Traffic, Errors, Saturation)
⚪️ Как отслеживать скорость сгорания SLO вместо наивных порогов
⚪️ Один инцидент — одно уведомление, без спама из 100 сообщений в чате
⚪️ Что реально заслуживает ночного звонка, а что может подождать до утра
⚪️ Почему алерт без инструкции по решению — это не алерт, а бесполезная паника

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

👈 Читать полностью

@DevOpsKaz 😛