4 записи с тегом "sre"

SRE-лид в mid-size fintech сказал фразу, определяющую observability-решения 2026: «Datadog — это iPhone observability: дорого, отполировано, и я жалею, что у меня есть выбор». На рынке сейчас три credible позиции: Datadog как интегрированный дефолт, Grafana как open-source-first альтернатива, Honeycomb как wide-events-специалист. Каждый оптимизирован под разный failure mode, и выбор не того не вылезет в первый квартал — он вылезет через $2M годового счёта и команду, всё ещё не отвечающую на «почему latency скакал во вторник?».

Annual Survey CNCF 2024 зафиксировал: 86% cloud-native организаций используют OpenTelemetry в той или иной форме — звучит как стандартизация рынка. На практике OTel — пайплайн, не destination; каждый шоп, гоняющий его, всё равно выбирает один из этих трёх стэков (или Splunk, New Relic, Dynatrace — их коснёмся кратко), чтобы реально хранить, запрашивать и визуализировать данные. Собственное исследование observability maturity от Honeycomb показывает: команды, переходящие на wide events, режут время расследования новых инцидентов на 40-60%, но только когда культура адаптируется — одним инструментом lift не даётся.

Лучший SRE ушла в прошлом квартале. На exit-интервью она не сказала «выгорание», но последние три месяца в её календаре — 14 ночных пагеров, 2 выходных на инцидентах и звонок в 3 утра в день рождения. Опрос Catchpoint / DevOps Institute 2021 года среди 500+ on-call инженеров показал: 67% сообщают о симптомах выгорания, напрямую связанных с нагрузкой от пейджера. SRE-книга Google ставит потолок — 2 инцидента на смену; дальше ротация считается нездоровой. У большинства команд, которые мы измеряем, этот потолок пробивается в первую неделю.

On-call лечится. Это задача расписания и социотехники, а не слабости тех, кто «не справляется». Ниже — playbook из 9 правил, который держит SLA и ваших сильных инженеров в команде дольше второй ротации.

В среднем post-mortem пишется 4 часа и порождает ноль action items, которые команда закрывает в течение 30 дней. Мы посмотрели на 120 post-mortem документов у трёх наших on-prem клиентов перед тем, как собрать этот шаблон. 83% action items оставались в статусе "open" через полгода. Это не разбор инцидента — это кладбище документов.

Post-mortem имеет смысл писать только если он что-то меняет. Всё остальное — прикрытие.

Книга Google Site Reliability Engineering (2016) популяризировала контринтуитивный принцип: примите неизбежность сбоев и инвестируйте в скорость восстановления. Исследования DORA подтвердили это данными — разница между элитными и отстающими командами не в том, что у элитных меньше инцидентов, а в том, что они восстанавливаются менее чем за час вместо недели. Каждая инженерная организация инвестирует в предотвращение сбоев. Немногие инвестируют в быстрое восстановление после них. Данные говорят, что приоритеты расставлены наоборот.