Что такое 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 — это допустимое количество ошибок за период, рассчитанное из 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 — это работа, которая:
- Ручная — требует человеческого вмешательства
- Повторяющаяся — делается снова и снова
- Автоматизируемая — может быть заменена скриптом
- Тактическая — реактивная, а не проактивная
- Не несёт ценности — не улучшает сервис
Правило 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)
- Latency — время обработки запроса
- Traffic — количество запросов к системе
- Errors — частота ошибок
- Saturation — насколько загружены ресурсы
RED Method (для микросервисов)
- Rate — количество запросов в секунду
- Errors — количество ошибок
- Duration — время обработки запроса
USE Method (для инфраструктуры)
- Utilization — процент использования ресурса
- Saturation — степень очередей / перегрузки
- Errors — количество ошибок ресурса
Итоги
| Концепция | Суть |
|---|---|
| SRE | Инженерный подход к эксплуатации |
| SLI | Метрика качества (число) |
| SLO | Целевое значение метрики |
| SLA | Контракт с последствиями |
| Error Budget | Допустимый запас ошибок |
| Toil | Рутина, которую нужно автоматизировать |
Главный принцип SRE: Надёжность — это не бинарное состояние. Это спектр, и задача SRE — найти правильный баланс между надёжностью и скоростью развития продукта.