🔥 Как смена 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 😛

⚡️ State of AI Engineering 2026

Отчет Datadog «State of AI Engineering 2026» основан на анализе телеметрии вызовов LLM у более чем тысячи клиентов компании.

6 ключевых выводов из отчета:

1️⃣ Доминирование мультимодельной архитектуры. 70% организаций используют 3 и более моделей, а доля компаний, применяющих более 6 моделей, почти удвоилась (41%). Прямые вызовы API провайдеров уступают место паттерну Model Gateway (например, OpenRouter или собственные шлюзы).

2️⃣ Накопление технического долга LLM. Инженерные команды быстро внедряют новые релизы, но крайне медленно выводят из эксплуатации старые модели в production.

3️⃣ Использование агентских фреймворков (LangChain, Pydantic AI, LangGraph, Vercel AI SDK и др.) выросло с 9,1% до 17.5% среди организаций. Разработчикам требуется сквозная трассировка (tracing) и телеметрия, чтобы выявлять неэффективную логику.

4️⃣ 69% всех входных токенов приходится на системные промпты: внутренние инструкции, политики безопасности, описания инструментов и схемы данных. На пользовательские промпты приходится лишь 28%.

5️⃣ Главным приоритетом становится Context Engineering — методы точной выборки (RAG), сжатия, дедупликации, суммаризации и формирования четкой иерархии информации, чтобы модель не теряла критические детали в длинном тексте.

6️⃣ Переход от монолитных агентов к микросервисным/мультиагентным архитектурам требует проброса контекста и трассировки через границы сервисов, а также формирования карт сервисов.

Разработка ИИ-систем превращается в дисциплину классической распределенной инженерии. Успех продуктов зависит не от красоты демо-версий, а от наличия непрерывных петель оценки качества (evals), проработанного инжиниринга контекста, контроля бюджетов/лимитов и сквозного мониторинга производительности и расходов.

@DevOpsKaz 😛

🔥 Участвуйте в AWS Innovation Day 2026 — 22 октября, бесплатно

Конференция об искусственном интеллекте, Agentic AI и облачных технологиях AWS пройдет в Астане.

В программе:

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

Среди спикеров — представители AWS, Министерства искусственного интеллекта и цифрового развития РК, АО НИХ «Байтерек», АО «Самрук-Қазына», «Казахтелекома», MUK Group и qCloudy.

Мероприятие ориентировано на руководителей, отвечающих за цифровую трансформацию, AI, данные и технологическую стратегию в государственном и корпоративном секторе.

📅 22 октября 2026, Астана, Astana Hub
🎟️ Участие бесплатное

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

@DevOpsKaz 😛

⚡️ Awesome Site Reliability Engineering

awesome-sre — это один из самых подробных списков на GitHub, посвященный SRE, инженерии надежности и поддержке сложных production-систем.

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

Внутри — тематические категории, охватывающие все аспекты SRE::

⚪️Культура и методология
⚪️Monitoring / Observability
⚪️Incident Response и Post-Mortem
⚪️On-Call
⚪️Chaos Engineering
⚪️Automation и Toil Reduction
⚪️Capacity Planning
⚪️SLO / SLI
⚪️Performance
⚪️Книги, доклады, статьи и гайды

Пользуйтесь, сохраняйте и делитесь с коллегами 🫡

@DevOpsKaz 😛

🔥 «Правильный FinOps в современных superapp»

Делимся записью доклада от Мираса Байгашева, DevOps Team Lead в компании Core 24/7.

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

В своем выступлении Мирас разбирает:

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

⚪️ Реальный потенциал экономии: как оценить переплаты в текущей инфраструктуре и понять, где именно вы теряете бюджет.

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

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

@DevOpsKaz 😛

🔥 Cloudflare собрала логи, трейсы и аналитику в одной observability-платформе

Cloudflare объявила о запуске One Observability Platform — 8 обновлений, которые сводят логи, трейсинг, аналитику, алерты, дашборды и экспорт данных всех продуктов компании в один интерфейс с единым SQL API.

Главный практический эффект — меньше переключения контекста при инцидентах. Расследование, которое раньше требовало переключения между несколькими отдельными интерфейсами и ручной сверки Ray ID, теперь строится вокруг одного рабочего пространства: от Logs к Traces и обратно к SQL API без смены вкладки и синтаксиса запросов.

👈 Узнать новость полностью

В следующие месяцы под общую платформу перейдут и другие продукты, датасеты и сценарии работы.

@DevOpsKaz 😛

🔥 Сервер на смартфоне OnePlus 6 с 26 контейнерами

Предлагаем пятничное чтиво про один интересный эксперимент. С чего все начиналось:

API, которые я размещал для микропроектов, уже не помещались на крохотном арендованном облаке. Да и цены на него собирались поднимать. Из-за всего этого я решил, что пора обзавестись домашним сервером. Небольшой ресёрч привёл меня к проекту Mobian (Debian для мобильных устройств, поддерживаемый энтузиастами)

Спустя полгода на сервере активно 26 докер-контейнеров — и за это время возникла всего одна проблема.

За всё время использования не было ни одного аварийного срабатывания на тему перегрева аккумулятора выше 45 градусов и даже 40 градусов температура, насколько я помню, не достигала.

В статьях ниже вы узнаете:

⚪️ Про установку Mobian
⚪️ Бенчмарки
⚪️ Про SSH и деплой
⚪️ Как устроен CI/CD
⚪️ Про Caddy и Nginx
⚪️ Итоги эксперимента

👈 Читать часть №1
👈 Читать часть №2

Сколько все стоило: ~18 000 тенге за б/у телефон и пара выходных на настройку.

@DevOpsKaz 😛

🔥 ArgoCD Mobile

mobile-for-argocd — мобильное приложение для iOS и Android, разработанное в рамках инкубатора Argo Project Labs. Предназначено для удобного мониторинга и базового управления деплоями в Argo CD прямо со смартфона.

⚪️Мониторинг приложений

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

⚪️Фильтрация и поиск

Сортировка и фильтр по состоянию синхронизации, проекту, namespace и меткам (labels).

⚪️Управление деплоями

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

⚪️Инспекция ресурсов

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

⚪️Безопасная аутентификация

Приложение создано на базе стека React Native / Expo и доступно для установки через App Store и Google Play.

@DevOpsKaz 😛

🚀 Бесплатный курс: Istio — Service Mesh в Kubernetes (EKS)

Istio: Service Mesh + EKS — практический видеокурс на русском языке о том, зачем нужен Service Mesh и как с помощью Istio управлять трафиком между микросервисами.

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

Подойдёт и тем, кто только слышал слово «сервис-меш», и тем, кто уже работает с Kubernetes и хочет добавить в арсенал управление трафиком, отказоустойчивость и observability.

Внутри — 13 видео в двух модулях.

Модуль 1. Основы и установка

⚪️ От монолита к микросервисам — какие проблемы приносит переход
⚪️ Service Mesh & Istio — зачем он нужен и какие задачи решает
⚪️Envoy и паттерн Sidecar
⚪️ Суть Istio через аналогию с Kubernetes
⚪️ Установка Istio в Kubernetes (EKS)
⚪️ Кастомизация установки

Модуль 2. Управление трафиком

⚪️ Gateway, Ingress и Egress
⚪️ Virtual Service — как связать всё воедино
⚪️ Destination Rule и Subsets
⚪️ Fault Injection — тестируем системы на отказ
⚪️ Timeouts & Retries — боремся с нестабильностью
⚪️ Circuit Breaking — защита от каскадных сбоев

Смотрите, сохраняйте и делитесь с коллегами 🤓

@DevOpsKaz 😛

🔥 Мигрируем вашу инфраструктуру в любое облако

В условиях турбулентности правила на рынке меняются быстро: тарифы, доступы, требования. Инфраструктура, завязанная на одно решение, в такое время превращается в риск.

Core 24/7 перенесёт ваши системы в облако, которое подходит вам сейчас. Если нужно, предложим гибридную схему: чувствительные данные остаются на ваших серверах, а приложение работает в облаке.

Аудит → подбор площадки → поэтапный перенос → мониторинг и защита → поддержка 24/7

Расскажем, какой вариант подойдёт именно вашей компании. Консультация бесплатная 👇

👈 Проконсультироваться

@DevOpsKaz 😛