SRE — это дисциплина, применяющая инженерные принципы к операционным задачам, с целью создания программного обеспечения как масштабируемой и высоконадежной системы. Основная цель — повышение надежности, эффективности и производительности сервисов.

Ключевые принципы SRE:

Измерения и мониторинг: Использование метрик для определения состояния системы (SLI, SLO, SLA).
Управление ошибками (Error Budget): Допустимый уровень отказов или недоступности сервиса. Позволяет балансировать между новшествами и стабильностью.
Автоматизация: Максимальная автоматизация рутинных задач (установки, развертывания, реагирование на инциденты).
Устранение ручного труда (Toil): Активное снижение количества повторяющихся, ручных и не имеющих долгосрочной ценности операций.
Реагирование на инциденты: Четкие процессы выявления, устранения и анализа первопричин сбоев.
Postmortems: Процесс документирования и анализа инцидентов для извлечения уроков и предотвращения повторения.

Основные отличия SRE от DevOps:

Аспект	SRE	DevOps
Фокус	Надежность, доступность, производительность	Сотрудничество, автоматизация, быстрая доставка
Подход	Инженерный, основанный на метриках	Культурный, набор практик
Цели	Минимизация ручного труда, управление ошибками	Непрерывная интеграция/доставка
Реализация	Часто инженеры с фокусом на операционные задачи	Сотрудничество между Dev и Ops командами
Измерение	SLI, SLO, Error Budget	Метрики CI/CD, время доставки

DevOps — это скорее культурное движение и набор практик для сокращения разрыва между разработкой и операциями. SRE же является конкретной реализацией инженерии операций, часто применяя инженерные методы к решению проблем операционного характера, обеспечивая при этом высокий уровень надежности, чего требует DevOps. SRE можно рассматривать как специфический способ реализации принципов DevOps, где reliability (надежность) является ключевым элементом.

Пример расчета SLO:

Допустим, мы хотим, чтобы наш API был доступен 99.9% времени за месяц.

// Общее количество секунд в месяце
TotalSecondsInMonth = 30 * 24 * 60 * 60 // приблизительно 2592000 секунд

// Целевое время доступности
TargetAvailability = 99.9%

// Допустимое время простоя
AllowedDowntimeInSeconds = TotalSecondsInMonth * (1 - TargetAvailability/100)
// AllowedDowntimeInSeconds = 2592000 * (1 - 0.999) = 2592000 * 0.001 = 2592 секунд

// Допустимое время простоя в минутах
AllowedDowntimeInMinutes = AllowedDowntimeInSeconds / 60
// AllowedDowntimeInMinutes = 2592 / 60 = 43.2 минуты

В этом случае SLO будет "API должен быть доступен в течение 99.9% времени за месяц, что соответствует не более чем 43.2 минутам совокупного простоя". SLI может быть метрика успеха HTTP-запросов (например, доля запросов с кодом 2xx). Error budget составит 0.1% времени, или 43.2 минуты простоя. Если мы превысим этот бюджет, должны быть приняты меры по повышению надежности, возможно, ценой замедления выпуска новых фич, пока надежность не будет восстановлена до целевого уровня.

Что такое Site Reliability Engineering (SRE) и чем он отличается от DevOps?