Антипаттерн: SRE-процессы в команде из двух человек

MAATRIX

Кто-то из двух инженеров прочитал книгу Google SRE, вдохновился и предложил внедрить error budget, расписать SLO для каждого сервиса и завести формальный процесс post-mortem с ролями фасилитатора и секретаря. Через месяц выясняется, что оба тратят по несколько часов в неделю на документы и отчётность, которую больше никто не читает, а на само приложение времени остаётся меньше, чем до внедрения «зрелых практик». Это частый и предсказуемый антипаттерн: процессы, спроектированные для организаций с десятками и сотнями инженеров, напрямую переносят на команду, где эти же самые два человека и пишут код, и отвечают на алерты, и разговаривают друг с другом каждый день без всякого протокола.

Откуда берётся соблазн скопировать SRE один в один

Книги и доклады про SRE — качественный материал, написанный людьми, которые решали реальные проблемы координации в Google, Netflix и подобных компаниях. Проблема не в содержании, а в контексте: там error budget нужен, чтобы примирить product-команду, которая хочет катить фичи, и SRE-команду, которая отвечает за надёжность — это две разные группы людей с разными KPI, и без формального механизма они бы конфликтовали на каждом релизе. SLO по каждому сервису нужен, потому что сервисов сотни, ими владеют разные команды, и без явной границы ответственности непонятно, кто чинит деградацию на стыке двух систем. Ротация дежурств по расписанию нужна, потому что в пуле 8-15 инженеров, и без формального графика никто не будет знать, чья сейчас смена.

Когда всё это читает инженер команды из двух человек, инструменты выглядят объективно полезными — так оно и есть, в своём контексте. Соблазн в том, чтобы скопировать процесс целиком, не спросив себя: а какую именно проблему координации он решает, и есть ли эта проблема у нас вообще? В команде из двух человек, которые сидят в одном чате и разговаривают друг с другом лично каждый день, часть проблем, для которых придумали формальные SRE-процессы, просто не существует — а вот накладные расходы на сам процесс переносятся один в один, потому что документация, встречи и отчётность стоят времени независимо от размера команды, которая их производит.

Error budget: механизм для переговоров между командами, а не чек-лист

Error budget — это, по сути, контракт: сервис может позволить себе X минут простоя или Y% ошибок в месяц, и пока бюджет не исчерпан, product-команда свободно катит фичи, а как только исчерпан — приоритет автоматически смещается на надёжность, и это решение уже не обсуждается заново на каждом созвоне, потому что правило согласовано заранее. Ценность механизма — снять необходимость договариваться каждый раз, когда интересы двух групп людей расходятся.

В команде из двух человек эта проблема отсутствует структурно: если продукт лихорадит, оба это видят одновременно и оба могут в моменте решить «на этой неделе не катим новых фич, чиним стабильность» — без комитета, без формального заморожения релизов, без ссылки на цифру бюджета. Формальный error budget в таком масштабе не убирает переговоры — переговоров и так почти нет, потому что решение принимают те же два человека, которые и пишут код. Зато он добавляет накладные расходы: нужно вести дашборд с расчётом бюджета, договариваться о методике подсчёта (по каким запросам, за какой период), периодически сверяться с ним и объяснять самим себе, почему цифра выглядит именно так. Это работа, которая в компании с сотней инженеров окупается тем, что избавляет от десятков конфликтных разговоров в месяц — а в команде из двух человек не избавляет практически ни от чего, потому что конфликтовать особо не с кем.

Что можно оставить полезного: простое ощущение «на этой неделе слишком много всего падает, притормаживаем с фичами» — но как разговор за пять минут, а не как формула с окном и процентилями, которую нужно поддерживать в актуальном состоянии.

SLO на каждый сервис: граница ответственности там, где границы нет

Гранулярный SLO для каждого микросервиса решает конкретную задачу: когда сервисов сотни и ими владеют разные команды, нужен явный контракт «этот сервис обязуется отвечать за 200мс в 99% случаев», чтобы команда, которая от него зависит, могла на это рассчитывать и не выясняла отношения на словах при каждой деградации. SLO — это, по сути, формализованная граница ответственности между людьми, которые физически не сидят рядом и не обсуждают состояние системы каждый день.

Если у вас два человека и три-пять сервисов (а часто и вовсе монолит), эта граница ответственности не нужна — оба и так знают, какой компонент капризный, а какой стабильный, потому что оба его писали и оба чинили последний раз, когда он падал. Формальный SLO-документ на каждый сервис в таком масштабе означает: завести отдельный дашборд под каждый компонент, договориться о целевых значениях, которые в итоге основаны не на измерениях реальной потребности бизнеса, а на интуиции («пусть будет 99,5%, звучит солидно»), и потом периодически пересматривать эти цифры на встречах, которых тоже больше ни для чего не нужно было бы созывать.

Что стоит оставить: один-два верхнеуровневых ориентира на весь продукт целиком — например, «главная страница отвечает быстрее двух секунд» и «оплата не падает дольше пяти минут подряд» — зафиксированные не как формальный SLO-документ с процентилями, а как простое общее понимание, куда смотреть в первую очередь при инциденте. Разница не в терминологии, а в объёме бюрократии вокруг цифры: одна фраза в общем README против отдельного файла на каждый из пяти сервисов с методикой расчёта и историей пересмотров.

Формальный post-mortem с множеством участников: во что он превращается вдвоём

Сами принципы разбора инцидентов — blameless-подход (без поиска виноватого), восстановление хронологии, поиск корневой причины, конкретные action items с ответственным и сроком — полезны в любой команде, даже если в ней один человек. Подробно про то, как писать такой разбор без превращения в формальность, разобрано в статье про разбор инцидента, чтобы из него реально учились. Проблема не в принципах, а именно в форме процесса, которую копируют вместе с ними: в крупной компании формальный post-mortem — это отдельная встреча с фасилитатором, который не участвовал в инциденте (чтобы разбор был объективным), секретарём, который ведёт протокол, и списком заинтересованных сторон из разных команд, которых нужно оповестить и собрать.

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

Рабочий минимум для двух человек — три вопроса в общем документе, без роли, повестки и приглашений:

# Разбор: падение API 14 августа, 23:40-00:15

Что случилось

• 23:40 — алерт: 5xx на /api/orders, ошибка растёт
• 23:47 — выяснили: миграция БД заблокировала таблицу orders
• 00:15 — откатили миграцию, ошибки прекратились

Почему это произошло

• Миграция с ALTER TABLE без online-режима, таблица большая,

блокировка держалась дольше, чем ожидали на тесте (там таблица маленькая)

Что меняем

• [ ] Добавить проверку размера таблицы перед миграцией в чек-лист — Иван, до 20.08
• [ ] Тестировать миграции на копии прод-объёма данных, а не на пустой БД — Мария, до 25.08

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

Ротация дежурств по расписанию: схема, которая не делится на двоих

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

Для двух человек формальный график ротации — это фикция вдвойне: «дежурит» по факту тот, кто сейчас не спит и в курсе, что именно чинить, а не тот, чья очередь по календарю. Заводить инструмент вроде PagerDuty с многоуровневой эскалацией, расписанием на квартал вперёд и политиками замены в отпуске в такой ситуации — это настройка системы, которая формально решает проблему пула из восьми человек, которой у вас нет. Тратится время на настройку интеграций и обучение инструменту, а не на то, что реально снижает риск: письменный runbook на частые инциденты и явно названный резервный контакт на случай, если единственный человек, который обычно чинит прод, недоступен.

Какие принципы SRE работают в любом масштабе, а какие требуют размера команды

Полезно разделить SRE не на «внедрять всё» или «не внедрять ничего», а по тому, какую проблему координации решает конкретная практика — и есть ли эта проблема у вас на самом деле:

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

Что делать вместо копирования книги: минимальный набор для двух человек

Практический ориентир — не «внедрить SRE» или «не внедрять SRE», а собрать минимальный набор практик под свой реальный масштаб и осознанно оставить остальное на потом:

• Мониторинг с небольшим числом алертов, которые реально требуют действия — 5-10 критичных проверок, а не полсотни метрик «на всякий случай». Как выбрать разумные пороги без шума, который через месяц перестанут читать, разобрано в статье про алерты, которые не бесят.
• Один-два простых ориентира по надёжности на весь продукт, а не формальный SLO-документ на каждый сервис — зафиксированные одной фразой в общем README, а не в отдельном файле с методикой расчёта.
• Лёгкий post-mortem в общем документе в тот же день, без отдельной встречи, ролей и слайдов — три вопроса: что случилось, почему, что меняем, с конкретным ответственным и сроком.
• Явно названный резервный контакт вместо формального графика ротации — кто подхватывает, если основной человек недоступен, и где лежит доступ, а не готовая интеграция с многоуровневой эскалацией под пул, которого нет.
• Runbook на 1-2 страницы на самые частые инциденты, написанный заранее, а не в момент, когда сервис уже лежит.

Момент, когда стоит пересмотреть этот минимум в сторону более формальных практик, — не фиксированное число месяцев, а конкретные структурные сигналы: в команде появился третий-четвёртый человек и решения по приоритетам стали расходиться настолько, что их приходится проговаривать отдельно; появились сервисы, которыми владеют явно разные люди; количество ночных инцидентов выросло настолько, что неформальное «кто не спит, тот и чинит» стало источником выгорания, а не разовым неудобством. До этого момента формальный процесс не столько защищает от риска, сколько создаёт видимость зрелости — ценой реального времени, которое можно было потратить на продукт.

Частые вопросы