Слегка отойдем от рабочих моментов...

И так, Dispatch — это безумно залипательная вещь на 10 часов, заполненная шикарными шутками, чёрным юмором, подколами и матюками.

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

Визуальная составляющая — просто шик, это замечательный мультик в стиле…а черт его знает что это за стиль, где иногда надо что-то выбрать, чтобы решить свою или чужую судьбу. Атмосфера насыщенная, саундтрек давит в нужный момент, а диалоги написаны с таким расчётом, что половину времени ты либо смеёшься, либо сидишь в шоке от развития событий.

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

А ещё там можно романсить двух красоток, что добавляет реиграбельности — хочется пройти ещё раз, чтобы увидеть все ветки сюжета и альтернативные концовки их лайнов.
Финал игры - просто отвал башки, с кайфом просидел все 9 часов и 8 эпизодов замечательной истории о любви, предательстве, дружбе и всей прочей ерунды.

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

Время чуть-чуть погрустить...
Итак, 12 числа, ровно через неделю, я покидаю Dodo Engineering.
Это было исключительно моё решение, которое далось тяжело. Но надо двигаться дальше...
Я всё ещё считаю, что за почти 11 лет моей IT-карьеры это самое лучшее место, где я работал. Начиная с онбординга и вливания в команду, заканчивая технологиями, опытом и свободой.
Ко всему прочему, я считаю, что именно в этой команде у меня был лучший лид и техлид, с которыми приходилось работать.
А текущая команда observability, которую лидировал я, - одни из самых заряженных и горящих парней, что я видел.
Специально для тех, кто интересуется, куда я, прикладываю намекающую картинку.
А Dodo всегда останется у меня в сердечке ❤️

Не так давно я скидывал ресерч от DevCrowd и...
Ресерч закончился, с результатами можно ознакомиться по ссылке в репосте.
Спасибо ребятам за интересный опрос, за возможность поучаствовать и "помочь" в нем :)

Все хейтят Grafana - а я вот её похвалю.

Несколько месяцев назад подключил всю свою хоум-лабу и все свои VPS к Grafana Cloud на бесплатном тарифе. И знаете, что? Кайфую.

Начну с боли, которую я ожидал. Обычно когда дело касается "облачных" решений для мониторинга, в голове сразу возникает:
- Дорого
- Настраивается часов 6, документация неясная или куча костылей
- Сервис упадёт и будет недоступен
- Дешевые тарифы режут по функциям так, что толку нет

Но Grafana Cloud удивил. Вот что я вижу в реальности:

Бесплатный тариф - это не издевательство над пользователями.
У меня сейчас в аккаунте:
- 6,7k метрик (включено 10k)
- 192 МБ логов из ingester (включено 50GB)
- И кучу синтетик-тестов, трейсов, host hours - всё включено и не трогается

Честно, для хоум-лабы и VPS-ок это смотрится как неограниченное количество.

Настройка 0 вообще минут на пять.
Тут самое крутое: мне не нужен отдельный Prometheus. Я поднял Grafana Alloy по команде что дала интеграция, дал ему конфиг (буквально JSON готовый), и он сам начал собирать метрики, логи, трейсы и слать их в облако. Никаких remote_write, никаких танцев с Helm и сертификатами. Alloy - это агент от Grafana, который делает всё в одном месте и просто работает.

Дашборды открываются быстро (но не всегда).
Я привык, что облачные решения тормозят, но тут - раз, и уже вижу свои графики. PromQL работает, алерты срабатывают, логи ищутся.

Это реально стандарт индустрии.
Я здесь не первый год работаю с метриками и мониторингом. Grafana - то самое решение, на которое смотрят даже большие компании и говорят: "ок, вот это хорошо сделано, это то что нам точно нужно".

Поэтому пока все вокруг ругаются на Grafana (и, может быть, справедливо!), я вот сидю, смотрю на свои дашборды, на состояние своей инфры, и просто... спокойно пью чай.

Если у вас есть хоум-лаба, vps-ки, какие-то сервисы, и вы ещё не подключили их туда - не усложняйте. Alloy + Grafana Cloud на фри-плане настраивается за вечер. Потом спасибо говорить будете.

#sre #observability #grafana #alloy #homelab #vps #мониторинг

Очень часто слышу споры и вопросы - а в чем разница между SRE/DevOps/Cloud Engineer/Platform Engineer?

Нашел тут статью на эту тему, которая мне очень понравилась, перевел ее для вас, оригинал по ссылке в конце :)

В современном мире технологий границы между ролями DevOps-инженера, SRE, Cloud Engineer и Platform Engineer часто размыты — эти термины постоянно путают между собой. Но есть нюанс: инструменты и культура пересекаются, а вот цели и фокус у каждой роли — разные.

Если вы когда-нибудь задумывались, «Это просто разные названия одной и той же профессии?» — давайте разберёмся 👇

🔹 DevOps Engineer — архитектор автоматизации
Фокус: CI/CD, автоматизация и Infrastructure as Code (IaC).
Цель: ускорить доставку софта, сохранив стабильность и повторяемость.
Инструменты: Jenkins, Docker, Kubernetes, Terraform.

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

🔹 SRE (Site Reliability Engineer) — хранитель надёжности
Фокус: отказоустойчивость, масштабируемость, мониторинг, инциденты.
Цель: обеспечить стабильность и доступность систем даже под нагрузкой.
Инструменты: Prometheus, Grafana, SLO/SLI, PagerDuty, on-call практики.

Культура SRE пошла от Google и основывается на идее: «эксплуатация — это та же инженерная задача».
SRE применяют программное мышление к операционным проблемам: автоматизируют обнаружение инцидентов, следят за здоровьем систем и формулируют измеримые цели надёжности (SLO).
Если DevOps ускоряет, то SRE не даёт скорости сломать стабильность — он балансирует инновации и устойчивость.

🔹 Cloud Engineer — архитектор облака
Фокус: проектирование, развёртывание и сопровождение облаков (AWS, Azure, GCP).
Цель: строить безопасные, масштабируемые и экономичные облачные среды.
Инструменты: EC2, S3, IAM, VPC, CloudFormation, Azure Resource Manager.

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

🔹 Platform Engineer — инженер, делающий разработку удобной
Фокус: внутренние платформы, инструменты, автоматизация процессов.
Цель: создать комфортный self-service-интерфейс для разработчиков.
Инструменты: Kubernetes, ArgoCD, Backstage, Crossplane.

Platform-инженеры развивают идеи DevOps дальше — они не просто автоматизируют пайплайны, а создают готовые внутренние платформы, где разработчики самостоятельно деплоят и наблюдают за своими сервисами.
Их приоритет — Developer Experience (DevEx): стандартизированные процессы, «золотые пути» и удобные инструменты, которые снимают зависимость от инфраструктурных команд.

⚙️ Как эти роли работают вместе
- DevOps строит CI/CD пайплайны и автоматизирует сборки.
- SRE внедряет метрики, мониторинг и процессы надёжности.
- Cloud Engineer создаёт и поддерживает облачную инфраструктуру.
- Platform Engineer объединяет всё это в единую self-service платформу для разработчиков.

Когда эти роли работают согласованно, компания получает идеальный баланс: скорость, надёжность и масштабируемость.

🧭 Кратко:
DevOps → скорость + автоматизация
SRE → надёжность + доступность
Cloud Engineer → облачная экспертиза
Platform Engineer → удобство + внутренние инструменты

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

Или проще: DevOps строит мост, SRE укрепляет его, Cloud Engineer заливает фундамент, а Platform Engineer делает так, чтобы по мосту удобно ходить.

💡 Итог:
В 2025 и дальше выигрывают компании, которые объединяют эти подходы — где автоматизация, надёжность, облачные практики и DevEx работают как единая экосистема.

С оригиналом можно ознакомиться тут

#sre #devops #platformengineering #cloudengineering

Ну что, новый год, новая работа, новые знания.

Хочу порекомендовать вам шикарную штуку, которая подойдёт и новичкам в SRE, и «старичкам», которые уже успели подзабыть базу.
Сайт sre.in100.dev - аккуратная коллекция выжимки по SRE: книги, статьи, доклады и инструменты по надёжности в одном месте, без воды и бесконечных «подписок на вебинар».

Зачем ещё один сайт про SRE
Когда начинаешь строить надёжность в команде, легко утонуть в хаосе: гуглодоки, статьи на Habr, доклады, книги - всё в разных вкладках, и половина вообще не по делу.
sre.in100.dev закрывает эту боль: даёт точку входа и «каркас» - от базового понимания SLO/SLI и error budget до практик алёртинга, обcёрвабилити и постмортемов.

Что внутри
Разделы по ключевым темам SRE: основы, мониторинг и наблюдаемость, инцидент‑менеджмент, культура, книги и курсы - по ним удобно идти сверху вниз как по учебному плану.
У каждой ссылки есть короткое описание: зачем читать, для кого, о чём материал (теория, практика, кейс), так что не приходится открывать десяток статей «на удачу».

Как этим пользоваться SRE‑лиду
Если вы тимлид или единственный SRE в компании, сайт можно использовать как дорожную карту: сегодня - обcёрвабилити, завтра - политика SLO, послезавтра - шаблоны постмортемов.
Материалы удобно раздавать точечно: разработчикам - блок про error budget, менеджерам - статьи про баланс фичей и надёжности, новичкам - базовые вводные по роли SRE.

Чем это лучше рандомного гуглинга
Подборка куратора завязана на реальные практики: меньше маркетинга, больше конкретики про метрики, дежурства и разбор инцидентов, как это принято в живых SRE‑командах.
Ресурс живой: по структуре видно, что его легко расширять новыми ссылками и секциями, превращая в внутренний «учебник» по надёжности для вашей команды.

Что можно сделать уже сегодня
Пройдитесь по разделу с основами, соберите список материалов «к обязательному прочтению» и положите его в README вашей платформенной или инфраструктурной репы.
Добавьте sre.in100.dev в онбординг SRE/DevOps: как только человек заводит первые алерты или SLO, у него уже есть понятный набор ссылок, а не случайные статьи из поиска.

Вывод: если вы строите или прокачиваете SRE в себе или вашей команде, этот сайт может стать тем самым стартовым набором, который экономит часы гуглинга и помогает говорить о надёжности с командой на одном языке.

#sre #learning #onboarding

5 антипаттернов алертов

На новом месте работы я заметил, что алерты сливаются в общий чат и это жутко неудобно. Первое же, что я сделал - отключил уведомления :) Значит, что-то явно не так.
Решил собрать антипаттерны и рассказать об этом.

Алертов много, а пользы мало - значит, в системе есть вот это:

1. Алертит всё подряд
Проблема: Люди настраивают алерт на каждый возможный сценарий. Результат: 2000+ алертов в неделю, но только 3% требуют действия.
Лучшая практика: Google SRE рекомендуют 4 Golden Signals:
• Latency - как быстро отвечает система
• Traffic - сколько запросов приходит
• Errors - сколько ошибок
• Saturation - как насыщена система (CPU, память, диск)
Этого хватает на 80% проблем. Остальное - noise.
Действие: Перепроверьте все алерты. Если алерт не про эти 4 сигнала - удалите или переделайте.

2. Нет severity
Проблема: Все алерты одинаковые. Получаешь 50 нотификаций в час и не знаешь, что критично, а что нет.
Лучшая практика: Четыре уровня:
DISASTER - Сервис упал, есть реальные users affected
→ ЗВОНОК СЕЙЧАС, пока разговариваешь
CRITICAL - Сервис работает, но деградация
→ Разбери сегодня, но можно за час
HIGH - Тренд плохой, может стать проблемой
→ Разбери завтра, добавь в спринт
WARNING - Отслеживаем, но пока OK
→ Смотри в дашборд, не звони
Результат в VK: 98% Critical алертов получают реакцию в первые минуты.

3. Нет runbook
Проблема: Alert сработал в 3 часа ночи. On-call инженер смотрит на название алерта и не понимает, что делать. Результат: 1–2 часа на поиск информации или escalation разработчикам.
Лучшая практика: Каждый Disaster/Critical алерт ДОЛЖЕН иметь runbook.
Что включить в runbook:
• Что произошло - что именно означает этот алерт (на человеческом языке, не техно-жаргон)
• Что проверить - какие логи смотреть, какие метрики
• Как чинить - пошаговые шаги для on-call инженера
• Время - runbook должен решаться за 10 минут без escalation
Правило: Если алерт не решается за 10 минут и в нём нет инструкции - это не алерт, это шум.
LinkedIn пример: On-call получал 50 страниц в неделю из-за плохо структурированных runbook. После переделки - спит по ночам.

4. Нет владельца
Проблема: Алерт срабатывает, но никто не знает, кто за него отвечает. Ticket гуляет по сотрудникам. Никто не знает, чинить ли это или это "expected behavior".
"Алерт без ответственного - это не алерт."
Лучшая практика: Каждый алерт должен иметь владельца (может быть team).
Владелец отвечает за:
• Обновление runbook, когда меняется сервис
• Мониторинг False Positive rate этого алерта
• Удаление/переделку, если алерт не помогает
Мотивация простая: если алерт плохой - его будут будить ночью.

5. Нет SLO
Проблема: Алерты на static thresholds:
• "CPU > 90%" - alert
• "Memory > 85%" - alert
• "Latency > 500ms" - alert
Но 95% времени эти метрики выше threshold, и ничего не ломается. Результат: игнор.
Лучшая практика: Переходи на SLO-based alerting (error budgets + multi-burn-rate).
Что такое SLO-based alerting:
Вместо: "CPU > 90%"
На: "Как быстро горит ваш error budget?"
Примеры:
• SLO: 99,9% uptime (error budget: 43 минуты в месяц)
• Если за день потратили 20 минут budget - спокойно, впереди ещё 23
• Если за день потратили 40 минут - WARNING, тренд плохой
• Если за час потратили 10 минут - CRITICAL, горит со скоростью 240 минут в день!
Multi-burn-rate alerts:
• 14.4x burn rate (будет истощен через 2 дня) = PAGE NOW
• 6x burn rate (будет истощен через 5 дней) = CREATE TICKET
• 3x burn rate (будет истощен через 10 дней) = MONITOR
• 1x burn rate (планируется) = смотри дашборд, не алертим
Результат: SLO-driven approach может снизить alert noise на 80%, но catch real issues ЛУЧШЕ, потому что alert срабатывает только когда реально горит.

#sre #observability #alerts #slo #sla #sli

ПОЧЕМУ ЭТО ВАЖНО
73% outage происходят из-за ПРОИГНОРИРОВАННЫХ алертов.
Это не значит, что систему нужно мониторить лучше. Это значит, что мониторим, но дежурный видит 300 алертов и игнорит все.
Масштаб проблемы:
• Команды получают 2000+ алертов в неделю, но только 3% требуют действия
• 67% алертов игнорируются ежедневно
• 85% - это ложные срабатывания
• Cost: $5,600/минута downtime для enterprise
Парадокс Alert Fatigue:
• Нужно видеть ВСЕ проблемы
• Но когда их слишком много - пропускаешь РЕАЛЬНЫЕ проблемы
• Нужно найти баланс через правильную настройку

ПРАВИЛЬНЫЙ ПОДХОД
Метрика качества алертов: Signal-to-Noise Ratio

Signal-to-noise = (actionable alerts) / (total alerts)

• Здоровая система: 30–50% actionable
• Проблемная система: <10% actionable
Если видишь, что <10% алертов требуют действия - бери это в приоритет, переделывай систему.

Вывод: Лучше 3 полезных алерта, чем 300 шумных. А ещё лучше - алерт, который можно реально починить за 10 минут.

#sre #observability #alerts #slo #sla #sli

ЭТОТ ШАБЛОН ПОСТМОРТЕМА РЕШИЛ ВСЕ МОИ ПРОБЛЕМЫ

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

Постмортемы часто откладывают, потому что «нет времени нормально написать». Но правда в том, что самый полезный постмортем - это тот, который вы сделали хоть как-то, и уже можете из него вытащить пользу: действия, владельцев, изменения.

Минимальный бар “полезно”

Если у вас есть только это - уже ок:
Impact: что сломалось и кому/чему стало больно (1–2 предложения).
Timeline: 5–10 ключевых событий (по минутам/часам).
Root cause / contributing factors: что реально привело к эффекту (не “у нас всё плохо”, а конкретика).
Action items: 1–5 пунктов, которые уменьшают вероятность/влияние повтора.

В Google SRE прямо подсвечивают, что постмортем без конкретных action items - неэффективен, а action items без понятных владельцев часто не закрываются. Ещё один типичный антипаттерн - “слишком много владельцев у постмортема”: лучше один владелец как single point of contact и несколько коллабораторов.
​
“Мы думали, проблема в одном…”

Очень частый сценарий: начали разбирать инцидент, и внезапно выяснилось, что «корень» вообще в другом месте, а по пути всплывает куча неочевидных зависимостей/подводных камней.

Это нормально - и это как раз ценность постмортема: он вытаскивает факты наружу и превращает “кажется, у нас X” в “на самом деле, у нас Y + 3 contributing factors + план, что с этим делать”.

Пример из мира реального.

У GitHub в пост-инцидент анализе есть показательная деталь: краткая потеря связности на 43 секунды запустила цепочку событий, которая привела к деградации сервиса на 24 часа и 11 минут. При этом они отдельно фиксируют последствия (например, показ устаревших/несогласованных данных) и описывают ход восстановления как последовательность фаз, а не «всё починили».
​
Практическое правило

Сделайте “черновой” постмортем в течение 10-12 часов (с момента окончания инцидента), даже если половина пунктов пока “TBD”. Но action items - только такие, у которых есть владелец и проверяемый финальный результат (это тоже прямо рекомендуют как признак хороших action items).



Текст специально обезличенного постмортема из Додо можно почитать тут или тут.
Я все еще считаю, что это один из лучших вариантов "шаблона" постмортема что я встречал когда либо.

​Вопрос к вам: что чаще мешает сделать постмортем “хоть как-то” - отсутствие шаблона, нехватка времени, или ощущение, что «всё равно ничего не поменяется»?

#sre #postmortem

SLO-based alerting: как сделать не хуже, чем было

В прошлом посте про алерты я сказал про SLO-based alerting. Время раскрыть что это такое и как с этим жить.
Когда люди «внедряют SLO», часто всё заканчивается тем, что к старым алертам просто добавляют ещё пару дашбордов и одну-две новых нотификации. В итоге шум остался, SLO «есть», но на них никто не смотрит.

Антипаттерны SLO-алертинга

SLO как ещё один threshold на метрику
«Если за 10 минут ошибок ≥ порога - шлём алерт». Формально это SLO, по факту - тот же метрик-алерт, только сложнее. Любой всплеск = пейджер, даже если по error budget мы вообще не страдаем.

Оповещаем «по симптомам», а не по SLO
Алерты идут по CPU, памяти, очередям, отдельным эндпоинтам - но не по тому, что реально описано в SLO. В итоге on-call живёт в мире инфраструктуры, а не пользовательского опыта.

Один burn rate на все случаи жизни
Одна граница «если burn rate > X - буди» не различает: «горит всё, срочно просыпайся» и «медленно проедаем бюджет, можно спокойно посмотреть завтра».

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

Паттерны, которые работают лучше

Многооконный burn rate (multi-window, multi-burn)
Идея из Google SRE:
- короткое «быстро горим» окно (минуты–часы) → пейджер;
- длинное «медленно утекаем» окно (сутки–недели) → тикет/задача.
Так SLO-алерты и про пожар, и про «мы системно ухудшаемся».

Пейджим только по угрозе error budget
Не по каждому 5xx, а когда текущее поведение реально угрожает выбить нас из SLO за период. Всё остальное - в тикеты, отчёты, дашборды, но не к on-call ночью.

SLO → правила игры, а не просто график
Есть SLO → есть политика: что делаем, если бюджет выжгли (freeze релизов, приоритет на фиксы, ограничения экспериментов). Иначе алерт «SLO нарушен» - просто ещё один красный прямоугольник.

Генерация правил, а не ручной зоопарк
Инструменты вроде Sloth помогают: описал SLO в YAML → получил Prometheus recording rules, burn-rate алерты и дашборды. Не нужно каждый раз изобретать запросы. Ребята из коммунити ALLSLO на этом месте вообще запилили свой форк под свои требования - и это нормальный путь, когда SLO становятся частью платформы, а не «ручной магией». Аналогично сделали ВсеИнструменты в лице Димы @r3code - их форк. А Кир @silabeer в ВК сделал свой инструмент.

Постепенное внедрение, а не «SLO везде»
1) Берём 1-2 критичных сервиса.
2) Для каждого - один SLO (например, 99.9% успешных запросов за 30 дней).
3) Описываем его в Sloth (или аналогичный инструмент), настраиваем multi-window burn rate, выводим на дашборд.
4) Проживаем пару инцидентов, учимся принимать решения по бюджету.
5) Только потом разматываем это на остальные сервисы.


В итоге «SLO-based alerting» - это не про ещё один вид алертов, а про смену логики: мы пейджим только тогда, когда страдают пользователи и реальный error budget, и делаем это по понятным правилам. Всё остальное - фон.

Slow is the new down: 5 антипаттернов, из-за которых вы не видите деградацию

«Система работает» - любимая фраза дежурного инженера в 3 часа ночи. Uptime 99.9%, алертов нет. Но пользователи уже пишут в поддержку, что «всё тормозит».

Я специально разбираю именно антипаттерны, а не best practices. Списки в духе «сделайте SLO, внедрите трейсинг, настройте synthetic monitoring» все уже читали. Но реальные проблемы обычно прячутся не в незнании, а в привычках: что именно вы смотрите, на что алертите и что считаете «нормальной работой».

И так, начнем!

1. Алерты только на error rate, но не на latency
Классика жанра: p99 улетел в 10 секунд, ошибок ноль, Grafana молчит. Формально система «жива», фактически для пользователя она уже сломана.
Эта логика не новая: Amazon ещё много лет назад показывал, что каждые дополнительные 100 ms задержки снижали продажи примерно на 1%.
Если у вас есть SLO только на availability, но нет SLO или хотя бы алертов на tail latency (p95/p99), у вас есть мониторинг аварий, но не мониторинг производительности.

2. Смотрите на average, а не на percentiles
Средняя latency почти всегда успокаивает сильнее, чем должна.
Если 90% запросов отвечают за 100 ms, а 10% висят по 5 s, среднее может выглядеть ещё «приемлемо». Но именно в этих хвостах и живёт реальная пользовательская боль.
Поэтому смотреть нужно не только на average, а на p95 и p99. Именно они показывают, как система ведёт себя для тех, кому сейчас хуже всего.

3. Нет baseline - нет и деградации
Если вы не знаете, как выглядела нормальная работа неделю назад, то любое замедление легко объясняется фразой «ну вроде так и было».
Так деградация и живёт неделями после деплоя, пока не придёт жалоба от крупного клиента.
Полезно сравнивать метрики не только с фиксированным порогом, но и с той же точкой неделю назад в то же время: это помогает увидеть постепенное ухудшение на фоне сезонности и дневных паттернов.

4. Мониторите сервис, но не зависимости и не пользовательский путь
Ваш API может отвечать за 200 ms, но внутри ждать базу, кеш, DNS, внешний API или сеть между ними. На дашборде сервис зелёный, а пользовательский сценарий уже «разваливается».
Официальная документация OpenTelemetry хорошо формулирует, зачем здесь нужен tracing: trace показывает путь одного запроса через несколько сервисов и помогает понять, где именно ушло время.
Без трейсинга зависимости часто остаются чёрным ящиком. А без synthetic checks или RUM на критические user journeys вы меряете систему изнутри, а не то, что реально видит пользователь.

5. Нагрузочное тестирование только перед релизом
Если вы проверяете производительность только перед большим релизом, то узнаёте о деградации слишком поздно.
Медленные регрессии чаще приходят не как «всё упало», а как накопительный эффект: изменился план запроса, убрали индекс, вырос объём данных, поменялась библиотека, усилилась конкуренция за CPU.
Поэтому зрелая практика сегодня - не только разовые load tests, но и регулярные synthetic latency checks, плюс continuous profiling (Pyroscope, Parca), чтобы ловить деградацию до того, как о ней напишет клиент.

SRE Report 2026 фиксирует важную вещь: почти две трети респондентов уже считают деградацию производительности настолько же серьёзной, как и даунтайм. Но только 26% организаций действительно проверяют, как улучшение производительности влияет на бизнес-метрики вроде revenue или NPS.

То есть проблема уже признана. Но измерять её по-настоящему умеют пока немногие.

Медленная система - это инцидент без пейджера.
Что из этого у вас до сих пор не настроено?

#sre #observability #performance #latency #opentelemetry

Привет, я Макс Гусев - SRE Team Lead в RWB.

В IT больше 11 лет: прошёл путь от простого инженера до TechLead SRE в финтехе и Lead Observability SRE Team в Dodo Engineering. Сейчас в RWB выстраиваю SRE-процессы, строю отказоустойчивые системы и разбираюсь, как не тонуть в тойле и как выглядит нормальный инцидент-менеджмент. На конференциях рассказываю про внедрение SRE и зачем это бизнесу и разработчикам.

Этот канал - заметки по SRE и observability: алерты, SLO, инциденты, метрики, инструменты - из практики, не из учебника. Иногда - автоматизация, хоумлаб и короткий оффтоп.

С чего начать читать
• Пять антипаттернов алертов
• SLO-based alerting: как не сделать хуже
• «Медленно» = «лежит»: антипаттерны деградации
• Минимальный полезный постмортем + примеры

Если материал зашёл - перешлите коллегам, буду благодарен.

Вопросы по темам постов - в комментариях к посту или в личку.

Wheel of Misfortune: зачем это SRE и как из него извлекать пользу

Что это?
Wheel of Misfortune (иногда встречается и название вроде «Walk the Plank») - это ролевая игра про инцидент: ведущий (Game Master) задаёт сценарий - вымышленный или основанный на прошлом сбое (что приоритетнее), а «дежурный» по очереди рассказывает, что именно сделал бы: какие алерты смотрит, какие запросы к метрикам и логам, кого пингует, как эскалирует. Остальная команда наблюдает и подключается к разбору. В материалах Google SRE это описано как регулярная практика, близкая к настольной RPG: вы в «лабиринте одинаковых консолей мониторинга», цель - отработать мышление и протокол до реального пейджа (ускорение выхода на дежурство).

Чем полезно именно SRE.
Инцидент - это не только root cause, но и управление вниманием, временем, коммуникацией и эскалацией при неполной картине. WoM даёт низкий риск для прода: можно намеренно тренировать редкие сценарии и процедуры (в том числе кто командир инцидента, как объявлять major и вести коммуникации). Это симуляция, а не реальное отключение: обучение через «низкие ставки» (Google Cloud: DiRT и Wheel of Misfortune). Рядом по смыслу - координированные учения вроде DiRT, но там другой масштаб подготовки и другой профиль риска.

Как из песочницы сделать пользу - практика.
1. Сценарии из жизни. Опирайтесь на постмортемы, странные прод-кейсы и гипотезы про будущий релиз. Если нужен зерновой набор тем, посмотрите публичное обсуждение сценариев в инфраструктурных командах - например, идеи в духе failover кластера, потери ноды, жёсткой деградации и отката деплоя (issue GitLab): не готовый сценарий, а ориентир, что описывать в своих .md или JSON.
2. Дебриф с артефактом. После сессии зафиксируйте: где споткнулись о runbook или дашборд, один конкретный шаг - обновить алерт, ссылку в playbook или порог. Без этого легко уехать в «поиграли и забыли».
3. Качество ведущего. GM выдаёт последовательно то, что запросил игрок (вид графиков, вывод команд, фрагменты логов), без преждевременного «значит вот что»: как в жизни, сигнал приходит сырой (тот же материал Google Cloud).
4. Ротация и чужие углы. Меняйте дежурного на «сцене», GM и зрителей; после хода игрока собирайте альтернативные пути отладки - так смешиваются стили мышления и знания не копятся у одного человека.
5. Связка с коммуникациями. В реальном учении команды вроде GOV.UK PaaS показывают, как к техническому расследованию добавить роль коммуникаций: сцена с пейджером и smoke tests, шаблон вопросов вроде «что сделаете первым?», «что ожидаете увидеть?», отдельно - ответственные за тексты для пользователей. Это хороший образец, если хотите тренировать не только grep по логам (запись в блоге UK government technology).

Дополнительный угол.
В Open Practice Library формулируют ещё одну пользу: при грамотной подводке игра помогает проверить гипотезы о том, как ведут себя мониторинг и алертинг - не вместо реальных проверок инфраструктуры, но как разговор «ожидание vs реальность» в команде.

Инструменты и примеры контента.
Классический open-source проект - dastergon/wheel-of-misfortune: сценарии в general_incidents.json, есть sample-файл, поддержка Ink для ветвящихся интерактивных историй; демо и инструкции можно отдать команде без установки. Есть форки: у twstewart42 - например, тёмная тема и выбор «дежурного»; автор описывает ежемесячный слот, порядка двух инцидентов за час и мок blameless postmortem после сессии (пост в блоге). У alphagov/paas-unlucky-dip - вариант с бэкендом для списков сценариев, если сценарии часто меняются. Идеи формулировок «что ломаем» в учениях (в духе утёкших ключей, компрометации аккаунта) можно подсмотреть в смежных drill-гайдах - например, раздел 18F про incident response drills: это не бренд WoM, но полезный каталог заготовок для своих текстов.

Wheel of Misfortune - дешёвый по риску тренажёр инцидентного мышления, процедур и ролей. Выгода измеряется не «мы провели игру», а обновлёнными runbook’ами, более предсказуемой эскалацией и тем, что на реальном пейдже меньше трения и сюрпризов.

#SRE #WheelOfMisfortune #incident_response #oncall

5 антипаттернов on-call дежурств, которые сжигают команду

На новом месте я сразу полез смотреть как устроен on-call. И увидел знакомую картину: алертов много, реальных инцидентов мало (если сравнивать с ложными), дежурят одни и те же люди, runbook'ов нет - или они не актуальные, или пустые. Классика, я уже даже не удивляюсь. Базовая ситуация, когда SRE не было и практики не применялись.

Но пришло время всё исправлять.

Тема горячая: Catchpoint SRE Report 2026 показывает - 70% SRE называют on-call стресс прямой причиной выгорания, тойл вырос до 34% рабочего времени. PagerDuty фиксирует: из ~50 алертов в неделю на инженера только 2-5% требуют действия.

1. Все алерты - P1
Нет severity → каждый алерт будит ночью → через неделю мозг отключается. 44% организаций получили аутедж из-за проигнорированных алертов, 67% инженеров признаются, что dismissают без разбора.
Решение: DISASTER → CRITICAL → HIGH → WARNING. Если всё P1 - значит ничего не P1.

2. Один герой на линии
Один человек дежурит неделями, потому что «знает систему лучше всех». Google SRE рекомендует: макс. 2 инцидента за смену, минимум 50% времени - на проектную работу, не на тушение пожаров.
Решение: primary + secondary, ротация раз в неделю. Wheel of Misfortune - чтобы дежурить мог каждый, а не только «тот самый Андрей».

3. Runbook? Какой runbook?
Алерт в 3 ночи, on-call не понимает что делать. 40 минут на пинги в Mattermost и эскалацию. incident.io подтверждает: без runbook время разрешения x3-4.
Решение: нет runbook = нет алерта. Внутри: что случилось, что проверить, как чинить, когда эскалировать. Цель - 10 минут без эскалации.

4. Дежурство без компенсации
Инженер не спит ночами. Компенсация: спасибо в Mattermost ноль. Google прямо говорит: out-of-hours работа должна компенсироваться - отгулами или деньгами, с капом на кол-во смен.

5. Нет follow-up после инцидента
Починили → забыли → через неделю тот же алерт в 3 ночи. Runframe: тойл вырос до 30%, при этом 16% говорят что AI только добавил работы. Машины пока не спасают.
Решение: инцидент → постмортем (мой шаблон) → action items с владельцем. Без follow-up вы чините симптомы, а не систему.

Здоровый on-call - не героизм, а инженерная практика. Плохой on-call - инцидент без конца.

Что из этого есть у вас?:)

#sre #oncall #alerts #burnout

AI SRE Agent не заменит on-call

PagerDuty 12 марта 2026 выкатили Spring 2026 release с важным сигналом: SRE Agent как virtual responder, которого можно будет добавлять в schedules и escalation policies. Он первым смотрит на инцидент, делает triage/diagnosis и только потом будит человека.

Звучит как мечта: в 03:17 просыпается не инженер, а коробка с LLM внутри. Спасибо, я и так достаточно страдал.

Но горячий тейк такой: AI в incident response не чинит плохой SRE-процесс. Он делает его быстрее, дороже и увереннее в своей неправоте.

1. Если нет SLO - агент не знает, что важно

AI может сгруппировать алерты и предложить гипотезу. Но он не знает, что для бизнеса больнее: 500 ошибок в админке или +800 ms на checkout.

Это всё ещё решают SLI/SLO и error budget. Без них agent будет сортировать шум по громкости, а не по impact. Получится быстрый дежурный без контекста.

2. Если телеметрия каша - AI будет гадать
OpenTelemetry semantic conventions - это база для корреляции: единые имена для traces, metrics, logs, profiles и resources. А log correlation позволяет связывать логи с traces через trace/span id.

Если в одном сервисе service, в другом app, в логах нет trace_id, владельцы живут в голове у Сережи, а деплои не связаны с инцидентами - агент будет играть в угадайку.

Сначала сделайте так, чтобы человек мог за 10 минут собрать timeline. Потом зовите AI ускорять это до одной минуты.

3. Давать write-права сразу - плохая идея

Вендоры уже говорят про approved remediations, rollback, scaling и автономные действия. Если сценарий типовой, зачем будить человека?

Но начинать надо не с "пусть сам чинит прод", а с read-only режима:
- собрать timeline;
- показать связанные алерты;
- найти похожие инциденты;
- подсветить последний deploy;
- предложить запросы к логам/трейсам;
- показать, какой runbook устарел.

Только потом - действия по allowlist: rollback canary, scale-up, рестарт consumer'а, отключение фиче-флага. И всё это должно попадать в аудит и постмортем.

Автономность без guardrails - это chaos engineering без календаря.

4. "AI написал RCA" - ещё не RCA

Root cause без доказательств - это не root cause, а уверенный autocomplete.

Нормальный AI-помощник должен показывать evidence: какая метрика изменилась, какой trace это подтверждает, какой deploy был рядом, какие логи связаны тем же trace_id.

Если агент не показывает доказательства - его выводы нельзя использовать для remediation. Максимум - как гипотезу для on-call.

5. AI не убирает toil автоматически

Catchpoint SRE Report 2026 охлаждает хайп: median toil у инженеров вырос до 34%. Почти половина респондентов говорит, что AI снизил toil, но треть не видит изменений, а часть получила новую нагрузку.

Самый неприятный пункт: только 13% уверены, что могут мониторить reliability AI/ML-компонентов.

То есть менеджмент уже видит "AI transformation", а инженер в 3 ночи всё ещё проверяет, не наврал ли ему новый помощник. Красота.

Что я бы мерил перед внедрением AI SRE:
- минуты от page до первого нормального timeline;
- процент алертов с владельцем, severity и runbook;
- сколько алертов агент сгруппировал правильно, а сколько спрятал зря;
- сколько раз AI-сводка сократила расследование или добавила проверки;
- сколько remediation-действий прошли без отката.

И только после этого можно говорить, что AI помогает reliability, а не просто красиво пересказывает дашборды.

AI SRE Agent - это не замена on-call. Это усилитель для команды, у которой уже есть SLO, нормальная телеметрия, runbook'и, ownership и культура постмортемов.

Если этого нет, AI станет новым участником инцидента. С доступом к продакшену. Что может пойти не так?

Вопрос к вам: вы бы пустили AI-агента в свой on-call хотя бы в read-only режиме?

#sre #observability #oncall #ai #incidentresponse