Wiki
DevOps

SRE — что это простыми словами

SRE (Site Reliability Engineering) — подход Google к эксплуатации: разработчики отвечают за uptime своих сервисов. Ключевые понятия: SLO, error budget, blameless postmortem.

SRE (Site Reliability Engineering) — подход к эксплуатации ПО, разработанный Google (Ben Treynor, 2003). Ключевая идея: разработчики отвечают за надёжность своих сервисов в production, а не отдельная "эксплуатация". SRE-команды пишут код автоматизации и инструменты, а не рутинно чинят инциденты.

Ключевые практики: (1) SLO + error budget — если сервис укладывается в 99.9 %, у команды 43 мин downtime/месяц как "бюджет". Пока бюджет есть — можно катить фичи. Кончился — freeze features, чинить надёжность. (2) Blameless postmortem — разбор инцидентов без поиска виноватого, фокус на процессах и системах. (3) 50/50 toil vs project work — не более 50 % времени на рутину.

Артефакты: runbook (пошаговое действия при типовых инцидентах), on-call rotation (недельные дежурства), error budget policy (что делаем, если бюджет исчерпан), SLO document (для каждого сервиса).

Практика для стартапа: не нужно нанимать "SRE-команду", достаточно принять принципы. Один инженер + Prometheus + PagerDuty + SLO-документ — уже SRE. Книга Google "Site Reliability Engineering" (бесплатно на sre.google/books) — обязательное чтение.

Частые вопросы

SRE или DevOps — в чём разница?
DevOps — культура (dev+ops сотрудничают). SRE — конкретная реализация с чёткими метриками (SLO, error budget). SRE ⊂ DevOps.
Нужен ли SRE в 5-человеческом стартапе?
Принципы — да (SLO + мониторинг + runbook). Отдельная роль SRE — от 30+ инженеров.

Смотрите также