EasyТеория7 min

Обзор SRE

Что такое Site Reliability Engineering: SLI/SLO/SLA, error budgets, toil reduction и культура надёжности

Что такое Site Reliability Engineering

SRE — дисциплина, которая применяет инженерные подходы к задачам эксплуатации. Термин ввёл Google в начале 2000-х. Основная идея: надёжность — это самая важная функциональность системы, потому что без неё остальные функции бесполезны.

SRE-инженер — это software engineer, который занимается операционными задачами, используя автоматизацию и инженерные практики.

Основные принципы SRE

Принцип Описание
Embracing Risk 100% надёжность — неправильная цель. Нужен баланс
Service Level Objectives Измеримые цели по надёжности
Eliminating Toil Автоматизация рутинной ручной работы
Monitoring Наблюдаемость как основа принятия решений
Automation Software engineering для решения ops-задач
Release Engineering Надёжные и предсказуемые релизы
Simplicity Простота как prerequisite надёжности

SLI, SLO и SLA

Три ключевых концепции для измерения и управления надёжностью.

SLI — Service Level Indicator

SLI — это количественная метрика качества сервиса. Выражается как доля (от 0 до 100%).

Примеры SLI:

Тип SLI Формула Пример
Availability Успешные запросы / Все запросы 99.95% запросов возвращают 2xx/3xx
Latency Быстрые запросы / Все запросы 95% запросов < 200ms
Throughput Обработанные / Полученные 99.9% сообщений обработаны
Correctness Корректные / Все результаты 99.99% расчётов верны
Freshness Свежие данные / Все данные 99% данных обновлены за последние 5 минут

SLO — Service Level Objective

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

SLO: 99.9% запросов должны быть успешны за 28-дневный период
SLO: 95-й перцентиль задержки < 300ms за 28-дневный период

Важно: SLO не должен быть 100%. Стремление к абсолютной надёжности экспоненциально увеличивает стоимость и замедляет скорость разработки.

SLA — Service Level Agreement

SLA — это контракт с клиентом, включающий последствия нарушения (компенсации, штрафы). SLA всегда мягче, чем SLO.

SLA: 99.9% uptime → при нарушении: 10% скидка
SLO: 99.95% uptime → внутренняя цель, запас прочности для SLA

Расчёт SLI

<?php

declare(strict_types=1);

final readonly class SliCalculator
{
    /**
     * Calculate availability SLI over a time window.
     *
     * @param int $totalRequests Total number of requests in the window
     * @param int $failedRequests Number of failed requests (5xx)
     * @return float Availability as a percentage (0-100)
     */
    public function calculateAvailability(int $totalRequests, int $failedRequests): float
    {
        if ($totalRequests === 0) {
            return 100.0;
        }

        $successfulRequests = $totalRequests - $failedRequests;

        return round(($successfulRequests / $totalRequests) * 100, 4);
    }

    /**
     * Calculate latency SLI (percentage of requests within threshold).
     *
     * @param array<float> $latencies Array of request latencies in ms
     * @param float $thresholdMs Latency threshold in milliseconds
     * @return float Percentage of requests within threshold
     */
    public function calculateLatencySli(array $latencies, float $thresholdMs): float
    {
        if (empty($latencies)) {
            return 100.0;
        }

        $withinThreshold = count(array_filter(
            $latencies,
            static fn(float $latency): bool => $latency <= $thresholdMs
        ));

        return round(($withinThreshold / count($latencies)) * 100, 4);
    }

    /**
     * Check if current SLI meets the SLO target.
     */
    public function meetsSlo(float $currentSli, float $sloTarget): bool
    {
        return $currentSli >= $sloTarget;
    }
}

// Usage
$calculator = new SliCalculator();
$availability = $calculator->calculateAvailability(
    totalRequests: 1_000_000,
    failedRequests: 500,
);
// Result: 99.95%

$meetsSlo = $calculator->meetsSlo($availability, sloTarget: 99.9);
// Result: true — we are within our error budget
## Error Budget

Error Budget — это допустимое количество ошибок за период, рассчитанное из SLO.

Формула

Error Budget = 1 - SLO

При SLO 99.9% за 30 дней:

  • Error Budget = 0.1% = 43.2 минуты простоя
  • Или ~1000 ошибок из 1 миллиона запросов

Политики Error Budget

Состояние бюджета Действия
> 50% осталось Нормальная работа, новые фичи
25-50% осталось Осторожность, дополнительное ревью
< 25% осталось Замедлить релизы, фокус на надёжность
Исчерпан Стоп релизов, только фиксы надёжности
<?php

declare(strict_types=1);

final readonly class ErrorBudget
{
    public function __construct(
        private float $sloTarget,
        private int $windowDays = 28,
    ) {}

    /**
     * Calculate total error budget in minutes.
     */
    public function totalBudgetMinutes(): float
    {
        $totalMinutes = $this->windowDays * 24 * 60;
        $budgetFraction = 1 - ($this->sloTarget / 100);

        return $totalMinutes * $budgetFraction;
    }

    /**
     * Calculate remaining error budget.
     *
     * @param float $downtimeMinutes Downtime consumed so far
     * @return array{remaining_minutes: float, remaining_percent: float, status: string}
     */
    public function remaining(float $downtimeMinutes): array
    {
        $total = $this->totalBudgetMinutes();
        $remaining = $total - $downtimeMinutes;
        $remainingPercent = ($remaining / $total) * 100;

        $status = match (true) {
            $remainingPercent > 50 => 'healthy',
            $remainingPercent > 25 => 'caution',
            $remainingPercent > 0  => 'critical',
            default                => 'exhausted',
        };

        return [
            'remaining_minutes' => round($remaining, 2),
            'remaining_percent' => round($remainingPercent, 2),
            'status' => $status,
        ];
    }
}

$budget = new ErrorBudget(sloTarget: 99.9, windowDays: 28);
// Total budget: ~40.32 minutes

$status = $budget->remaining(downtimeMinutes: 15.0);
// remaining_percent: ~62.8%, status: "healthy"
## Toil — рутинная работа

Toil — это работа, которая:

  • Ручная — требует человеческого вмешательства
  • Повторяющаяся — делается снова и снова
  • Автоматизируемая — может быть заменена скриптом
  • Тактическая — реактивная, а не проактивная
  • Не несёт ценности — не улучшает сервис

Правило Google: SRE-инженер должен тратить не более 50% времени на toil. Остальное — на engineering, который уменьшает toil в будущем.

Примеры Toil и автоматизации

Toil Автоматизация
Ручной деплой CI/CD pipeline
Перезапуск сервисов Self-healing + auto-restart
Ротация логов Logrotate + retention policy
Выдача доступов Self-service + автоматическое одобрение
Масштабирование вручную Autoscaling
Ручная проверка health Health checks + alerting

Модель зрелости SRE

Организации проходят несколько стадий внедрения SRE:

Уровень Характеристика Практики
0 — Ad Hoc Тушение пожаров Ручной мониторинг, нет SLO
1 — Reactive Реакция на инциденты Базовый мониторинг, алерты
2 — Proactive Предотвращение проблем SLI/SLO, error budgets, postmortems
3 — Managed Системный подход Автоматизация, capacity planning
4 — Optimized Непрерывное улучшение Chaos engineering, ML-based ops

Ключевые метрики SRE

Four Golden Signals (Google)

  1. Latency — время обработки запроса
  2. Traffic — количество запросов к системе
  3. Errors — частота ошибок
  4. Saturation — насколько загружены ресурсы

RED Method (для микросервисов)

  • Rate — количество запросов в секунду
  • Errors — количество ошибок
  • Duration — время обработки запроса

USE Method (для инфраструктуры)

  • Utilization — процент использования ресурса
  • Saturation — степень очередей / перегрузки
  • Errors — количество ошибок ресурса

Итоги

Концепция Суть
SRE Инженерный подход к эксплуатации
SLI Метрика качества (число)
SLO Целевое значение метрики
SLA Контракт с последствиями
Error Budget Допустимый запас ошибок
Toil Рутина, которую нужно автоматизировать

Главный принцип SRE: Надёжность — это не бинарное состояние. Это спектр, и задача SRE — найти правильный баланс между надёжностью и скоростью развития продукта.