Все хейтят 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