Практики SRE, которые реально снижают число инцидентов, а не украшают презентации

Практики SRE, которые реально снижают число инцидентов, а не украшают презентации

SRE — это не «дежурим и героически тушим». Это набор дисциплин, где надежность измеряется, а не обсуждается на созвоне. База проста: — SLI должны отражать пользовательский опыт, а не внутреннюю удобность; — SLO задают допустимый бюджет ошибок; — error budget ограничивает скорость изменений, если сервис уже нестабилен.

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

Еще один обязательный слой — управление изменениями. Любой релиз должен иметь понятный rollback, а критичные операции — быть автоматизированы. Автоматизация — это не опция, а необходимость. Ручной ввод в проде обычно заканчивается историей с одинаковым финалом: «почему это не воспроизвелось локально».

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

Держите надежность в цифрах, а не в ощущениях: если метрика не влияет на решение, она декоративная.