SRE: Site Reliability Engineering

2003 год: Google нанимает первого SRE - Ben Treynor Sloss. Задача: обеспечить reliability поисковика который обрабатывает миллиарды запросов в день. Решение: не больше людей дежурящих ночью, а engineering подход к reliability. Error budgets убрали политические конфликты между разработкой и operations. Сегодня SRE практики используют Amazon, Netflix, Microsoft, Spotify.

• **Google SRE Book**: открытая книга о SRE практиках (sre.google/sre-book). Стала стандартом индустрии для reliability engineering - переведена на десятки языков
• **Atlassian Statuspage**: компания раскрывает SLO для своих продуктов (Jira, Confluence) публично - клиенты видят реальные метрики, не только 'все системы работают'
• **PagerDuty**: платформа для incident management используется тысячами SRE команд. Данные PagerDuty показывают среднее MTTR (Mean Time To Recovery) по индустрии

SLO, SLI, SLA

SRE (Site Reliability Engineering) - дисциплина созданная Google в 2003 году Беном Трейнором. Главная идея: reliability is a product feature, а не просто операционная задача. Три ключевых концепции: SLI (Service Level Indicator) - измеримый показатель (процент успешных запросов), SLO (Service Level Objective) - целевое значение SLI (99.9% успешных запросов за 30 дней), SLA (Service Level Agreement) - юридически обязывающий контракт с последствиями за нарушение.

Хорошие SLI: измеримы в реальном времени, отражают user experience (не server CPU, а request success rate), контролируемы командой. Типичные SLI: availability (% времени сервис доступен), latency (% запросов ответивших за X мс), error rate (% запросов с ошибками), throughput (запросов в секунду). Google рекомендует 3-5 SLI для сервиса - больше создаёт operational overhead без дополнительной ценности.

Error Budget

Error Budget - количество допустимых отказов в рамках SLO за период. SLO 99.9% availability за месяц -> error budget = 0.1% = 43.8 минут downtime в месяц. Error budget решает конфликт между reliability и velocity: пока бюджет есть - команда может рисковать (деплоить чаще, экспериментировать). Когда бюджет исчерпан - все усилия на reliability, никаких рискованных изменений.

Error budget policy - формальное соглашение: если error budget исчерпан, feature development останавливается до восстановления reliability. Это убирает political tension между разработчиками (хотят деплоить) и operations (боятся изменений). Обе стороны смотрят на один объективный показатель. Google SRE: если SRE команда исчерпала error budget из-за проблем reliability - они имеют право заморозить деплои.

Toil и Automation

Toil (рутинная работа) в SRE - ручная, повторяющаяся, автоматизируемая операционная работа без долгосрочной ценности. Примеры: ручные деплои по чеклисту, перезапуск сервиса при memory leak вместо исправления, ручная очистка логов, ответы на однотипные алерты. Google SRE правило: не более 50% времени на toil. Если больше - нужна автоматизация. Остальные 50% - engineering work (автоматизация, улучшение reliability).

Измерение toil: количество ручных операций в неделю, время на повторяющиеся задачи vs engineering. Тест: 'если бы нас было в 10 раз больше пользователей - нам нужно было бы в 10 раз больше людей для этой задачи?' Если да - это toil, нужна автоматизация. Runbooks - первый шаг: документирование ручных процессов. Второй - автоматизация runbook'а. Третий - устранение причины по которой runbook вообще нужен.

Incident Management

Incident management - структурированный процесс реагирования на production проблемы. Google SRE incident severity: SEV1 (полный outage, все hands on deck), SEV2 (значительная деградация, immediate response), SEV3 (частичная деградация, response в рабочее время), SEV4 (minor issue, плановое исправление). Incident Commander - единая точка координации: принимает решения, делегирует, избегает параллельных действий без координации.

Blameless Postmortem - анализ инцидента после устранения. Ключевой принцип: не виноватые, а системные проблемы. John Allspaw (Etsy): 'engineers who find themselves in the middle of an incident response are valuable engineers'. Postmortem содержит: timeline событий, impact, root cause(s), что сработало хорошо, что плохо, action items с owner и датой. Action items из postmortem - основной способ системных улучшений.

Связанные темы

SRE связывает процессы разработки с production reliability:

• Observability: логи, метрики, трейсы — SLI измеряются через observability инструменты. Без хорошего monitoring невозможно определить выполняется ли SLO
• Chaos Engineering — Chaos Engineering - proactive проверка что reliability targets выдерживаются под нагрузкой и при отказах

Вопросы для размышления

• SLO 99.99% звучит лучше чем 99.9% - почему не всегда нужно стремиться к максимальной availability?
• Как error budget policy меняет взаимодействие между development и operations командами?
• Blameless postmortem культура - что мешает её внедрению в командах и как преодолеть сопротивление?

Связанные уроки

• devops-10