Team Topologies

«Мы внедрили Team Topologies» обычно означает «мы переименовали часть команд в Platform и Stream-Aligned». Это не Team Topologies, это реорг с новой табличкой. Skelton и Pais построили диагностическую рамку: четыре фундаментальных типа команд и три режима взаимодействия. Ценность — не в том, как назвать команды, а в том, чтобы (а) осознанно проектировать team API и режимы взаимодействия, (б) удерживать когнитивную нагрузку команды в пределах её способности, (в) использовать inverse Conway maneuver — структурировать команды так, чтобы получить желаемую архитектуру. Лист — про применение рамки в SRE-контексте: где работает платформенная SRE-команда, где embedded, где режим enabling.

Я считаю, что без этой рамки спор «централизованная SRE против embedded» просто бессмыслен. Это не альтернативы. Это разные режимы взаимодействия, которые спокойно сосуществуют в одной организации, и вопрос всегда в том, какой из них уместен для конкретного продукта. Граница с SRE Onboarding — там про вход одного инженера в SRE-практику; здесь — про дизайн SRE-команд на уровне организации. Граница с Dev Team Partnership — там про динамику отношений с продуктовой командой в моменте; здесь — про формальную структуру и режим, в котором эта динамика происходит.

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

Главный навык на уровне L5 — распознавать, какой режим взаимодействия уместен в моменте, и явно выбирать его, а не сваливаться в дефолтный «как привыкли». Collaboration на полгода с продуктовой командой выглядит близко и быстро, но через квартал блокирует обе команды и съедает их когнитивную ёмкость. X-as-a-Service выглядит холодно и формально, зато масштабируется на 20+ команд без блокировок. Режим facilitating выглядит как помощь, но без критерия выхода команда enabling превращается в постоянный костыль. Каждый режим уместен в своих условиях; путать их — корень большинства организационных пробуксовок, которые я наблюдаю.

Различает четыре типа команд (stream-aligned, platform, enabling, complicated-subsystem) и три режима взаимодействия (collaboration, X-as-a-Service, facilitating). Читает структуру организации через эту рамку.
Описывает team API своей команды: что мы делаем, как с нами связаться, за какое время отвечаем, через какие интерфейсы (каталог сервисов, runbook’и, форма запроса, канал дежурного).

Проектирует взаимодействие своей SRE-команды с продуктовыми: какой режим (collaboration на старте → X-as-a-Service на масштабе), какие критерии выхода, какие обязательства по срокам ответа.
Применяет inverse Conway maneuver: формулирует, какая архитектура нужна, и уже из неё выводит границы команд. Например: микросервисная архитектура → stream-aligned teams, каждая владеет своим сервисом целиком; общий runtime и наблюдаемость — platform team.
Удерживает когнитивную нагрузку команды в пределах её ёмкости: если команда владеет более чем 7±2 сервисами или знаком технологий, это сигнал разделить команду или вложиться в платформу.
Распознаёт сигналы расхождения: затянувшийся collaboration без выхода, platform team в роли узкого места, enabling team, превратившаяся в постоянную операционную поддержку.

L6+

Внедряет Team Topologies на уровне всей SRE-функции: какие команды нужны, в каком режиме они работают с продуктовыми, как меняются с ростом организации.
Ведёт переговоры с руководством о реорганизации команд в логике topology, а не «по головам»: обоснование через когнитивную нагрузку, метрики потока (DORA) и устойчивость team API.

Материалы

Книги

Matthew Skelton, Manuel Pais — Team Topologies (IT Revolution, 1-е изд. 2019, 2-е изд. 2025). Основной источник. Если читать одну книгу — эту. Рабочая база — главы про четыре типа команд и про три режима взаимодействия; остальное полезно для контекста. Во втором издании platform team уточнена как platform grouping, а когнитивная нагрузка поднята до принципа проектирования; нумерация глав между изданиями отличается, поэтому ссылаться стоит на название главы, а не на номер.
Mel Conway — How Do Committees Invent? (Datamation, 1968). Оригинальная статья Conway’s Law. Не Team Topologies, но фундамент — без понимания «структура коммуникации → структура системы» рамка Skelton/Pais висит в воздухе.
Nicole Forsgren, Jez Humble, Gene Kim — Accelerate (IT Revolution, 2018). Глава 4 «Architecture» — эмпирическое подтверждение, что слабо связанные команды и слабо связанная архитектура коррелируют с высокой производительностью. Книга-предтеча Team Topologies; вместе читаются лучше, чем по отдельности.

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

Matthew Skelton, Manuel Pais — teamtopologies.com (живой сайт + блог). Регулярные кейсы и уточнения; полезен в первую очередь раздел «Industry examples». Skelton сам публикует ответы на типичные неверные интерпретации.
Критику рамки стоит искать отдельно: у неё есть системная слабость — четыре типа команд и три режима взаимодействия описывают целевое состояние, но почти ничего не говорят про переход из текущего. Всё, что я видел в публичном поле, — это либо восторженные внедрения, либо частные жалобы; вменяемого разбора «где рамка ломается» мне не попадалось.
Henrik Kniberg — Spotify Engineering Culture (2014). Не Team Topologies, но модель Spotify постоянно упоминают рядом. Skelton явно пишет, что модель Spotify часто неверно копируют, — статья помогает понять разницу.

Инструменты

Team API Canvas — однополосный документ команды: purpose, communications channels, response time, dependencies, on-call schedule. По моим наблюдениям, самый дешёвый артефакт Team Topologies и одновременно самый ценный: он превращает «мы платформенная команда» в конкретный контракт с потребителями.
Ключевые концепции Team Topologies — в том числе inverse Conway maneuver: на доске рисуем желаемую архитектуру и уже из неё выводим границы команд. Полезно на старте реструктуризации.
Оценка когнитивной нагрузки — качественная: сколько сервисов и технологий команда держит в голове, чтобы просто продолжать работать. Skelton предлагает шкалу 1–5; на практике чаще берут светофор, и этого хватает. Без такой оценки вложения в платформу делаются вслепую.
Каталог сервисов с явным владельцем и team API — Backstage и аналоги. Без каталога команды тратят время на выяснение, кому принадлежит сервис, и рамка проигрывает там, где должна была помочь.

Best practices

Главный публичный кейс, который полезно прочитать рядом с книгой — эволюция SRE в Google в логике topology. Google SRE начинался как embedded в продуктовых командах, с явным production readiness review; потом стандартизовался в централизованную функцию — по сути platform team со своим API: общий подход к SLO, инфраструктура дежурств, шаблоны постмортемов; дальше пришёл к смешанному режиму — центральная платформенная SRE, embedded SRE в крупнейших продуктах, консультирующий режим enabling для остальных. Дело здесь не в отсутствии у Google единой модели. Просто разным продуктам нужен разный режим взаимодействия с SRE, и зрелая организация это допускает. Если читаете лист и думаете «у нас должна быть одна модель» — эта траектория Google — главное возражение.

Короткие правила:

Четыре типа команд — это диагностика, а не названия должностей. Переименовать инфраструктурную команду в «Platform» и считать рамку внедрённой — ход дешёвый и ничего не меняющий. Вопрос ставится иначе: эта команда действительно отдаёт платформу самообслуживания, которая снимает когнитивную нагрузку с продуктовых команд? Если нет — она не platform team, как её ни назови.
Collaboration — временный режим, не дефолт. Работать близко с продуктовой командой постоянно приятно и незаметно затратно: режим съедает когнитивную ёмкость обеих сторон. Collaboration уместен в окне высокой неопределённости — новый продукт, незнакомая область — и с самого начала имеет критерий перехода к X-as-a-Service.

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

Подробнее:

Когнитивная нагрузка — главное ограничение, которое я наблюдаю в SRE-командах. Стандартный путь: SRE-команда из 4 человек начинает поддерживать 5 сервисов, потом 12, потом 25. Где-то между двенадцатью и двадцатью пятью проявляется знакомая картина: всего не знает никто, инциденты лечатся вопросом «кто помнит этот сервис», runbook’и устаревают, а дежурство превращается в лотерею. Это не проблема «нужно больше людей», это проблема превышения когнитивной ёмкости. Решений два: либо разделить команду на stream-aligned (каждая владеет тремя-пятью сервисами целиком), либо вложиться в платформу — наблюдаемость, деплой, инструменты вокруг SLO, — чтобы поднять эффективную ёмкость. По моим наблюдениям, большинство SRE-команд выбирают «больше людей», что не решает проблему: при 8 людях на 50 сервисов когнитивная нагрузка распределена, но каждый отдельный человек всё равно не помещается в свою область.

Платформенная команда без клиентоориентации превращается в бюрократический шлагбаум. Один из самых частых сценариев, которые я вижу: централизованная SRE-команда становится приёмной комиссией, которая рассматривает запросы продуктовых команд и блокирует изменения в проде. Это не Platform Team по Skelton/Pais. Платформа самообслуживаемая по определению: продуктовые команды пользуются ею через документированный team API, без очереди заявок и личного вмешательства. Если каждый запрос требует ткнуть человека в платформенный канал — это не платформа, а прежний отдел эксплуатации с новой вывеской. Тест простой: уберите всех людей из платформенной команды на неделю — что сломается? Если ничего критичного — платформа есть. Если всё — платформы нет, есть ops.

Inverse Conway maneuver работает только при поддержке сверху. Skelton/Pais описывают изменение структуры команд под желаемую архитектуру как первичное действие. На практике это перестановка людей, а такие решения принимает CTO или VP. Я регулярно вижу попытки провернуть манёвр снизу: инженеры рисуют team API, проводят ретроспективу, договариваются о границах — и упираются в существующую структуру подчинения. Без поддержки сверху рамка остаётся артефактом сессий у доски. Если её нет, начните с малого: один документ team API для своей SRE-команды, опубликованный для продуктовых. Это уже Team Topologies в действии, без реструктуризации.

SRE-функция эволюционирует через типы команд, не отбрасывает их. Траектория, которую я наблюдаю в разных организациях, повторяется почти дословно: (1) embedded SRE в каждой продуктовой команде на старте, пока продуктов один-два; (2) enabling SRE — небольшая команда, которая помогает продуктовым освоить практики, где-то на 5-15 продуктах; (3) platform SRE — централизованная команда, отдающая надёжность как самообслуживаемую платформу, от 15 продуктов; (4) гибрид — платформенная SRE как ядро, embedded SRE в самых критичных продуктах, enabling SRE для входа новых команд. Каждый шаг добавляет тип, а не отменяет предыдущий. Настоящий антипаттерн — зафиксироваться на одной модели и тащить её через все этапы.

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

Dev Team Partnership — этот лист описывает динамику партнёрства; Team Topologies задаёт режим (collaboration / X-as-a-Service / facilitating), в котором эта динамика происходит. Без явного режима партнёрство остаётся подразумеваемым.
SRE Onboarding — сценарий onboarding зависит от того, в какую команду попадает новый инженер: embedded, платформенная и enabling — это три разные программы и три разные первые недели.
Service Ownership — владение сервисом — прямое следствие топологии: stream-aligned team владеет сервисом целиком, платформенная — инфраструктурой; без явной топологии каталог сервисов получается дырявым.
Communities of Practice — CoP — механизм обмена знаниями поперёк топологии, особенно когда продуктовые команды работают изолированно; платформенная команда часто ведёт такое сообщество по надёжности.
Career Ladders — путь инженера часто проходит через разные типы команд: младший в embedded, старший в платформенной, staff в enabling. Без понимания топологии лестница читается плоско.
Runbooks — часть team API: runbook’и stream-aligned team на свои сервисы, runbook’и platform team на использование платформы.
DORA Metrics — DORA измеряет поток продуктовой команды; растущее время до продакшена часто сигнализирует о неверно собранной топологии — платформа стала узким местом или интерфейса X-as-a-Service просто нет.

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

SRE Maturity Assessment (TBD) — соседний L2-концепт под этим L1; включает оценку, в каком режиме topology организация находится сейчас и куда движется. Кандидат на отдельный лист.
SRE Model Adoption (TBD) — практическая часть выбора и перехода между режимами (embedded → платформа → гибрид); может быть отдельным листом или частью этого.
Internal Developer Portal (TBD) — практическая реализация витрины платформы через Backstage / Port / Cortex. Сам L1 Platform Engineering уже выделен в Engineering, а продуктовая рамка вокруг него описана в Platform as a Product; портал остаётся кандидатом на отдельный лист там же.

Ещё два вопроса открыты по существу, не по плану. Первый — издание. Лист написан по первому, второе (2025) я целиком не читал: по описанию издателя platform team там уточнена как platform grouping, когнитивная нагрузка поднята до принципа проектирования, а рамка расширена на трансформацию организации целиком. Сохранилась ли без изменений связка «четыре типа команд плюс три режима взаимодействия» и как перенумерованы главы — не проверено, поэтому номера глав из листа убраны. Кто читал второе издание, правки приветствуются PR’ом.

Второй — малые организации. Я не уверен, как корректно применять Team Topologies там, где людей меньше двадцати и формальные team boundaries размыты. Skelton и Pais пишут про средние и крупные компании, а на фазе стартапа рамка чаще превращается в лишние накладные расходы, чем помогает. Если у кого-то есть работающая практика — расскажите PR’ом.