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

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

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

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

Отдельный слой — автоматизация и наблюдаемость. Ручные действия допустимы только как временная мера; всё повторяющееся уходит в runbook и скрипт. Мониторинг должен быть проактивным, а не реактивным: ловить рост латентности, очередей, ошибок и saturation до того, как пользователь увидит 500-ю. Безопасность начинается с доступа — и с понятных границ ответственности между командами.

Хорошая SRE-практика не убирает инциденты, она делает их короче, дешевле и предсказуемее. Автоматизация — это не опция, а необходимость.