<b>Практики SRE, которые реально снижают число ночных инцидентов</b>

<b>Практики SRE, которые реально снижают число ночных инцидентов</b>

SRE — это не «дежурим и героически тушим». Это набор привычек, которые делают систему предсказуемой, а баги — дорогими для появления. Давайте разберем архитектуру решения.

— Определяйте SLO до запуска фичи, а не после первого падения. Если сервис критичен, измеряйте доступность, латентность и ошибочный бюджет, иначе спор о «нормальной деградации» закончится на проде.
— Инструментируйте всё, что влияет на пользовательский путь: не только CPU и memory, но и очередь, внешние зависимости, таймауты, процент ретраев. Мониторинг должен быть проактивным, а не реактивным.

Runbook должен отвечать на три вопроса: как понять, что сломалось; как безопасно откатить; кого и когда звать. Если в инструкции есть фраза «проверить логи», а дальше пустота — это не runbook, а памятник оптимизму. Код работает, но есть нюансы.

— Автоматизируйте рутинные операции: деплой, rollback, масштабирование, очистку мусора, ротацию секретов. Ручной процесс всегда ломается в самый неудобный момент, обычно с участием дедлайна и чьей-то уверенности.

Считайте инцидент завершённым только после postmortem с конкретным action item: метрика, алерт, тест, лимит или guardrail. Без этого система просто ждёт повторения сценария. Автоматизация — это не опция, а необходимость.