Dev Team Partnership

«Разработчики пишут, эксплуатация держит прод». У этой схемы два предсказуемых исхода. Эксплуатация превращается в штрафную команду, где надёжность — забота только её; разработчики не учатся писать надёжный код, потому что не несут последствий. Подход SRE ломает разделение в одном месте: обе стороны тратят один error budget и отвечают за одну метрику успеха. Этот лист — про дисциплину партнёрства: явный контракт взаимодействия, общее дежурство там, где оно возможно, PRR (Production Readiness Review) как обязательный рубеж перед запуском, критерии выхода. Без них партнёрство за полгода откатывается обратно к разделению «мы пишем, вы держите».

Что должен уметь

Главный навык на уровне L5 — договариваться о контракте взаимодействия в явном виде, а не «помогаем как можем». Я регулярно вижу команды, где SRE и разработчики называют себя партнёрами, а на первом серьёзном инциденте выясняется, что никто не знал точно, кто чем владеет, на каких условиях SRE подключается и как отходит. Без письменного контракта партнёрство — это игра в надежду, и проигрывается она ровно там, где нужнее всего.

Различает три типовые модели сотрудничества: embedded SRE (внутри продуктовой команды), consulting SRE (приходящий по запросу) и platform SRE (предоставляет общие сервисы).
Понимает, что за uptime SRE не отвечает в одиночку; читает документы о взаимодействии между SRE и командой разработки.

Работает внутри продуктовой команды как embedded SRE: ходит на планирование, приносит соображения по надёжности на design review, помогает писать корректные SLI вместе с разработчиками.
Проводит Production Readiness Review (PRR) для нового сервиса: проверяет SLO, runbook, наблюдаемость, запас мощности, зависимости — фиксирует пробелы до запуска.

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

L6+

Проектирует модель встраивания SRE для продуктовой области из нескольких команд: где embedded, где consulting, где platform.
Разбирает конфликты владения и мотивации между разработкой и SRE: пересматривает контракт при систематическом нарушении SLO, не скатываясь в поиск виноватых.
Проверяет, что за рычагами партнёрства стоит решение руководства: остановка релизов, PRR как рубеж и возврат дежурства согласованы выше команды. Без этого сужает модель до того, под что согласие есть.

Материалы

Книги

Betsy Beyer et al. — The Site Reliability Workbook (O’Reilly, 2018), глава 1 «How SRE Relates to DevOps». Место SRE в парадигме DevOps.
Betsy Beyer et al. — The Site Reliability Workbook, глава 18 «SRE Engagement Model». По моим наблюдениям, главный источник по моделям подключения (PRR, simple PRR, ongoing) — на него ссылаются чаще, чем на любую статью по теме.
David N. Blank-Edelman (ред.) — Seeking SRE (O’Reilly, 2018). Сборник: разделы про устройство организации, embedded против consulting, масштабирование SRE.
Matthew Skelton, Manuel Pais — Team Topologies (IT Revolution, 1-е изд. 2019, 2-е изд. 2025). Типы команд (stream-aligned / platform / complicated-subsystem / enabling) — SRE укладывается в несколько в зависимости от модели.
Nicole Forsgren, Jez Humble, Gene Kim — Accelerate (IT Revolution, 2018). Эмпирика DORA про межкомандное взаимодействие.

Статьи и доклады

Google SRE — practices and processes. Подборка материалов о том, как у них устроено взаимодействие SRE с продуктовыми командами: engagement model, критерии, при которых SRE берёт сервис на поддержку, и при которых возвращает обратно.
Liz Fong-Jones — доклады на SREcon. Доводы за общую ответственность и против выделенных SRE-«пожарных»; по моим наблюдениям, к этой теме она возвращается из года в год.
DORA — State of DevOps Report. Исследования о том, как устроено взаимодействие между командами.
Мой разбор — Надежность — это не продукт SRE, или почему мы всё понимали не так? (Telegram, март 2026). Короткий пост о том, что надёжность нельзя произвести силами одной SRE-команды и отдать бизнесу: сервисом владеет тот, кто его делает, а требуемый уровень надёжности — вопрос продуктовый. К книгам выше добавляет третью сторону, продукт: по моим наблюдениям, в разговоре о партнёрстве её забывают первой.

Инструменты

Чеклист готовности к продакшену — внутрикомандный документ, фиксирующий пробелы до запуска. По моим наблюдениям, готовый шаблон здесь не берут почти никогда: чеклист собирают под себя, а за референсами идут в SRE Workbook (гл. 18) и в публикации Spotify / Shopify / Lyft.
Контракт взаимодействия в формате RFC — markdown в репозитории команды: кто чем владеет, SLO, дежурство, критерии выхода. Стандарта нет, но структура повторяется во многих SRE-командах, и чаще всего документ живёт рядом с кодом, а не в вики.

Best practices

Надёжность — общая ответственность. Это не лозунг, а требование к устройству метрик: пока надёжность поделена на «наше» и «ваше», проигрывают обе стороны сразу, потому что SRE превращаются в штрафную команду, а разработчики так и не учатся писать код, который держится в проде дольше квартала. Нужна одна цифра на двоих. Error budget как раз такая: обе команды его и тратят, и защищают.

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

Общее дежурство с продуктовой командой даёт самую сильную обратную связь. «SRE дежурят за всех, разработчики узнают про падения из ретро» — типовой антипаттерн. Ритуал тяжёлый. Пейджер не любит никто, но он окупается: люди начинают писать код, который не падает в три ночи. Я регулярно вижу, как общее дежурство вводят постепенно — сначала только рабочие часы, потом полная ротация, — и через 6–12 месяцев качество кода в проде меняется заметно, причём меняется само, без отдельной программы «повышения качества». Из всех механизмов партнёрства этот работает сильнее прочих.

Критерий выхода — обязательная часть договорённости. Иначе получается «SRE подключились к сервису и остались навсегда»: команда становится бутылочным горлышком, а новые продукты не могут получить SRE, потому что вся ёмкость уже разобрана. Контракт описывает, когда дежурство возвращается разработке — например, после года стабильного SLO. Без выхода модель не масштабируется.

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

Знание идёт в обе стороны. Обычная асимметрия выглядит так: SRE учат разработчиков практикам эксплуатации, а доменное знание обратно не течёт. В инциденте это стоит дорого — дежурный принимает осторожные и неоптимальные решения просто потому, что не понимает бизнес-логику сервиса и не хочет одним движением сделать хуже, чем есть. Задача tech lead — передать доменное знание: через runbook, совместные разборы, парную отладку. Иначе партнёрство остаётся на бумаге.

У всех механизмов выше одна цена, и платит её не SRE. PRR сдвигает запуск. Общее дежурство забирает у разработчиков время, которое планировалось на фичи. Сгоревший бюджет останавливает релизы. Каждый из трёх рычагов работает, пока за ним стоит решение руководства, и в книгах Google это сказано прямо. В первой главе SRE Book: возврат лишней операционной нагрузки разработчикам хорошо работает, когда вся организация понимает, зачем этот предохранитель существует. В двадцатой главе Workbook: право SRE-команды регулировать свою нагрузку требует ясного и заранее взятого обязательства высшего руководства. А в первой главе Workbook есть слово для случая, когда этого нет, rename-and-shame: группу переименовали в SRE, больше ничего не поменяли, и стыдят её же, когда обещанного улучшения не случилось.

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

Связанные листья

SLO / Budget Review — главный регулярный ритуал, где партнёрство проверяется работой с общим error budget.
SLI-based Alerting — SLI формулируются совместно с продуктовой командой, а не спускаются SRE сверху.
Runbooks — общее владение: runbook пишут вместе, иначе SRE дежурит вслепую по чужому сервису.
Postmortem Culture — общий разбор с обеими сторонами за столом — обязательное условие, без него партнёрство не переживает первый крупный инцидент.
Incident Response — роли в инциденте (IC и остальные) распределяются между SRE и разработчиками в зависимости от выбранной модели взаимодействия.
Change Governance — PRR — формальная граница «команда готова к продакшену», и там он описан как обязательный рубеж.
DORA Metrics — совместное чтение DORA-метрик с разработкой: главный канал, где общая ответственность за поставку превращается в работу с общими цифрами.
Team Topologies — этот лист про динамику партнёрства; Team Topologies задаёт режим (collaboration / X-as-a-Service / facilitating). Без явного режима партнёрство остаётся подразумеваемым.
Stakeholder Management — работа с инженерами — частный случай; соседний лист расширяет охват на не-инженеров (продукт, руководство, финансы, юристы). Разговор с инженером и разговор с финансистом требуют разных навыков.

Открытые вопросы

Как масштабировать модель взаимодействия на десяток и больше продуктовых команд при ограниченном составе SRE? Стандартный ответ — уходить в сторону platform SRE и enabling teams (Team Topologies). Вопрос в порогах: в какой момент переключаться, у меня хорошего ответа нет.