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

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

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

— SLI/SLO должны быть измеримыми и связаны с пользовательским опытом, а не с удобством графиков.
— Error budget нужен не для отчета, а как стоп-кран для релизов, когда система уже ест слишком много риска.
— Toil надо считать и вычищать: если ручная операция повторяется, она уже кандидат в автоматизацию. Автоматизация — это не опция, а необходимость.

Инцидент-менеджмент без постмортема — просто дорогой чат. После каждого серьезного сбоя фиксируйте три вещи: триггер, путь деградации и точку, где мониторинг должен был сработать раньше. Не ищите виноватых; ищите слабое звено в цепочке наблюдаемости, конфигурации или процесса.

Хорошая практика — делать алерты по симптомам, а не по каждому отклонению метрики. Иначе on-call быстро превращается в упражнение по игнорированию шума. Мониторинг должен быть проактивным, а не реактивным.

Если SRE-процессы не уменьшают toil, не улучшают SLO и не делают инциденты понятнее, это не практика, а ритуал. Значит, где-то перепутали инженерную дисциплину с красивыми диаграммами.