Каждый SRE знает это чувство: открываешь «Site Reliability Engineering» от Google, читаешь про SLI/SLO, Error Budgets, и думаешь: «ого, круто, надо внедрить у себя в конторе». Проходит полгода. Книга пылится на полке, инциденты по-прежнему разбираются как получится, алерты пишутся вручную, мониторится все, что можно, метрики собираются все, что существуют и ничего не изменилось.
Проблема не в книгах. Проблема в том, что вся литература про SRE — это не инструкция, а описание паттернов. Их нельзя тупо скопировать. Их нужно адаптировать под реалии своей конторы.
Как не застрять в теории ради теории?
Почему «сделать как в Google» не работает
Масштаб и контекст
Google писал свои практики для тысяч микросервисов, команд в 10+ инженеров на сервис и собственной инфраструктуры (Borg, Monarch и т.д.)
А в обычной среднестатистической конторе (даже в той, которая считает себя флагманом рынка) реальность, скорее всего, выглядит примерно так:
- 25 сервисов, которые «надо бы разделить, описать и привести в порядок»
- 2-3 задолбаных инженера на все это хозяйство
- Managed Kubernetes в облаке и AlertManager
- ни документации, ни ранбуков, релизы вручную
- все, как всегда
Тупо копировать из книжек процессы Google — значит тратить ресурсы на то, что никогда не принесёт никакой отдачи.
Культурные различия
В Google роль SRE это отдельная роль с четкими границами.
А у нас SRE может быть названием должности, но по факту «DevOps-инженер, который ещё и код пишет и мониторинг настраивает». Или инженером L3 которого хз почему (модно, наверное) переименовали в SRE, не поменяв ничего. Или вообще Incident manager + Problem manager + писатель алертов + вообще все, что умудрились на него свалить.
Про основные понятия
Возьмём SLO (Service Level Objective). В книге это:
«Целевой уровень надёжности сервиса, измеряемый через SLI»
На практике это три разных задачи:
| Уровень | Вопрос | Сложность |
|---|---|---|
| Метрика (SLI) | Что меряем? Latency? Availability? Что считать «успехом»? | Средняя |
| Цель (SLO) | 99,9%? Или 99,99%? Почему именно столько? | Высокая |
| Процесс | Кто следит? Что делать при превышении? Кто принимает решение о «надёжность или фича»? | Очень высокая |
Не нужно внедрять SLO целиком, сразу, как в книжке. Выбери один сервис, один SLI, один временной горизонт (например, 30 дней). Протестируй механику, увидь засады, подумай, что-то измени под реалии…
Каждая SRE-практика решает конкретную проблему. Не существует «хороших практик» в вакууме, есть «практики, подходящие или решающие нашу боль».
| Боль | Практика из книги | Минимальная версия |
|---|---|---|
| Не знаем, работает ли сервис | SLI/SLO | Один dashboard с ключевой метрикой + alert на порог |
| Одни и те же инциденты тушим часами | Incident Command System | Роли на время инцидента без автоматизации + четкое описание обязанностей каждой роли |
| Релизы ломают прод, после каждого релиза две недели чиним | Error Budget | Ручной подсчёт ошибок за неделю, обсуждение на ретро |
| Задолбали алерты по каждому чиху круглосуточно | Alert fatigue management | Правило: «если alert не требует действия за 15 минут, то выключаем его» |
SRE-практики это 30% техническая часть, остальные 70% — соглашения между людьми.
Например, внедрение Error Budget
- выбираем один критичный сервис
- определяем один SLI (например, availability по HTTP 200)
- считаем вручную за последние 30 дней
- договариваемся с командой разработки или продуктологами: «когда бюджет на ошибки закончится — следующие две недели только фиксим баги и работаем над надежностью»
- смотрим: работает ли порог? Или он слишком жёсткий? Или он слишком мягкий?
- реагируют ли команды на исчерпание бюджета? Или, как всегда, забили?
- нужна ли автоматизация подсчёта?
- автоматизируем расчёт
- добавляем еще сервисы/продукты
- или признаем: «в текущей культуре и на текущем этапе зрелости компании это не работает, пробуем иначе»
Стереотипы
У нас нет ресурсов на SRE
SRE это не отдельная команда в 20 человек, SRE это набор практик, не обязательно выделенная роль. Можно начать с того, что дать некоторым инженерам 20% из их рабочего времени (например, день в неделю) на улучшение наблюдаемости продукта. И не путайте мониторинг и наблюдаемость, это разные вещи.
Нужно сначала настроить идеальный мониторинг и алертинг
Не надо откладывать SLO до того мифического момента, когда «все метрики будут собираться правильно». Используйте то, что есть: логи, метрики, подсчет скриптом на bash из access-логов. Идеальное враг хорошего.
Внедрили — значит, работает и будет работать само
Считать задачу выполненной после настройки дашборда или проведения тренинга по postmortem ошибка :) Меряйте outcome, не output. Не «написали 100 постмортемов», а «MTTR снизилось на 30%».
Как читать такие книги
Применяйте к любой концепции из книги:
- прочитайте главу, выделите 1-2 конкретные практики, не теоретические принципы.
- внедрите в минимальном масштабе (один сервис, одна команда, 2-4 недели).
- задайте вопросы:
- изменилось ли поведение команды?
- снизилось ли время на рутину?
- стало ли понятнее, где проблемы?
- помогло хоть чем-то?
Если ответ «нет» — у вас эта практика не работает в вашем контексте. Но это нормально, нужно адаптировать практику под себя или отказаться от нее.
| Книга | Что можно взять | Что адаптировать |
|---|---|---|
| «Site Reliability Engineering» (Google) | Философия Error Budget, структура postmortem | Масштаб практик, организационная структура |
| «The Site Reliability Workbook» | Конкретные шаблоны SLO, runbook | Автоматизация |
| «Seeking SRE» | Разнообразие подходов в разных компаниях | Истории «как сделано у них» — вдохновляться, думать, но не копировать тупо |
| «Building Secure & Reliable Systems» | Модели угроз для надёжности | Уровень формальности процессов |
SRE-книги это не свод правил и рецептов, которые вам помогут стать Гуглом, а набор проверенных гипотез. Ваша задача не внедрить больше практик, а найти минимальный набор, который решает конкретные проблемы.
Начните с одного сервиса. Одной метрики. Одного соглашения с командой. Проверьте работает ли этот подход. Масштабируйте только то, что приносит результат.
Идеальная SRE-организация это та, которая соответствует вашему масштабу, культуре и болям, а не та, что описана в книге.
Если вам не повезло с руководителями, которым это или не интересно, или не вписывается в какие-то их коммиты, или портит какие-то их показатели, или им просто лень в этом разбираться — то вам не повезло :(
