Платформа как продукт: у неё есть пользователи и они могут уйти

Компания на 80 продуктовых инженеров и 42 сервиса. Полтора года назад собрали платформенную команду — пять человек. Сделали шаблоны сервисов, единый пайплайн, каталог, портал. На квартальном обзоре слайд: «42 из 42 сервисов подключены, принятие 100 %». Через неделю после слайда я потратил час на grep по репозиториям: искал в CI-конфигах прямые вызовы aws, kubectl и terraform в обход платформенных шагов.

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

Пользователь, который ничего не платит, но может уйти

Инфраструктурный проект заканчивается, когда он сдан; продукт не заканчивается никогда. Внутренняя платформа ведёт себя как продукт по одной причине — потребление добровольно по факту, даже когда обязательно по регламенту. Регламент управляет тем, что команда напишет в отчёте, а не тем, что она напишет в .gitlab-ci.yml.

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

Уход при этом почти никогда не выглядит как громкий отказ:

1. Обход. Команда формально на платформе, но критичный шаг делает сама — обычно выкат, доступы или данные. Признак: прямой вызов облачного CLI с комментарием «временно».
2. Заморозка. Шаблон взяли один раз и не обновлялись: формально пользователь, фактически форк. Худший вариант — платформа отвечает за то, чем не управляет.
3. Эмиграция. Отдельный аккаунт, кластер, CI — «у нас особенный случай». Так делают сильные команды с политическим весом, и их уход больнее всего: за ними идут подражатели.

Все три невидимы для метрики «количество подключённых сервисов» и все три видны за час в git.

Кто именно ваш пользователь

Слово «разработчик» слишком крупное, чтобы что-то проектировать: у платформы минимум пять пользователей с разными задачами, и они конфликтуют.

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

Метрики принятия важнее полноты функций

Полноту функций платформенная команда двигает в одиночку, принятие — только вместе с пользователями; поэтому первая метрика так соблазнительна и так бесполезна. Прежде чем считать принятие, определите, что такое «пользуется», — проверяемо, по артефактам.

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

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

Принятие — не бинарное состояние, а траектория с характерными точками отвала.

Две стрелки важнее прочих. Использует → Опирается — момент, когда команда перестаёт держать запасной путь; до него метрики завышены, потому что у половины «пользователей» в кармане лежит старый скрипт. Опирается → Обошла — один инцидент, где платформа оказалась и причиной, и препятствием для починки, откатывает доверие на год. Отсюда следствие: надёжность платформы — не техническая характеристика, а метрика принятия (SLI и SLO, бюджет ошибок).

Три типовых способа провалиться

Обёртка над облаком, которая только мешает

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

name: payments-api
runtime: java21
resources: { profile: standard }   # платформа выбрала cpu/memory/probes сама
raw:                               # люк: то, что платформа не покрывает
  reason: "медленный старт JVM с прогревом кеша, нужен свой startupProbe"
  owner: team-payments
  review_at: 2026-11-01
  spec: { startupProbe: { httpGet: { path: /healthz, port: 8080 }, failureThreshold: 30 } }

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

Портал, которым никто не пользуется

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

Признаки смерти не совпадают с посещаемостью: заходы бывают высокими, если через портал раздают ссылки. Смотреть надо на долю действий против «посмотреть и уйти», долю карточек, обновившихся автоматически за месяц, и число открытий портала дежурным в инциденте. Отсюда практика: портал строится последним и только на автоматически собираемых данных — владелец из CODEOWNERS, версия из реестра образов, SLO из мониторинга. И отдельно: портал не платформа; платформа — то, что происходит после git push.

«Мы сделали абстракцию» поверх трёх разных потребностей

Самый дорогой провал, потому что выглядит как хорошая инженерия. Приходят три команды: одной нужна очередь для фоновой обработки картинок, второй — для событий домена с гарантией порядка, третьей — буфер перед медленным внешним API. Платформа видит слово «очередь» трижды и делает единый сервис. Дальше предсказуемо: первой не нужен порядок, зато нужна дешёвая пропускная способность; второй порядок критичен, а объём мал; третьей важны backpressure и повторы. Интерфейс обрастает флагами ordered, dlq_policy, max_in_flight, retry_backoff, dedup_window, конфигурация превращается в язык программирования без отладчика, а платформа — в горлышко для любого изменения. Диагностика — вопрос не о форме запроса, а о том, что произойдёт при изменении.

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

Где скрывать сложность и где это вредно — Абстракции.

Золотой путь: помощь ровно до тех пор, пока это путь

«Золотой путь» (paved road) — предопределённый способ сделать типовую вещь: создать сервис, добавить очередь, выкатиться. Термин популяризовал Netflix в контексте full-cycle-разработки (Full Cycle Developers at Netflix). Разница между дорогой и забором формулируется одной строкой: дорога — самый дешёвый путь, забор — единственный.

Забор возникает не от злого умысла, а от сдвига: платформе дают полномочия блокировать, но не дают ответственности за скорость поставки. Как только появилась кнопка «не пропустить» и не появилось метрики «сколько мы стоили командам в днях ожидания», путь превращается в забор за квартал. Это школьный пример локальной оптимизации: подсистема улучшает свой показатель, а поток через систему замедляется (локальная оптимизация).

Что делать с командой, которой золотой путь не подходит

Вариантов ровно четыре, выбирать надо явно.

1. Расширить путь. Кейс общий, просто не покрыт: похожий запрос уже был у двух других команд или вытекает из требований, которые скоро придут ко всем. Цена — рост сложности пути для остальных, этим и опасно.
2. Вынести общий кусок вниз. Кейс не общий, но под ним есть общая часть: не «единый сервис очередей», а «единый способ получить доступ и наблюдаемость для любой очереди».
3. Дать явное отклонение. Кейс уникален и таким останется — договор, а не молчаливое разрешение.
4. Признать, что команда не ваш пользователь. Жёсткое железо, встроенные системы, регуляторный контур: натянуть на них общий путь дороже, чем содержать два.

Договор об отклонении должен быть коротким и формальным, иначе он превращается в вечное исключение, о котором никто не помнит:

# deviations/team-ledger-custom-deploy.yaml
team: team-ledger
deviation: собственный процесс выката вместо платформенного
reason: сверка балансов требует остановки обработки на 40 секунд, платформа так не умеет
team_takes_on:                # что команда берёт на себя явно
  - дежурство по своему выкату 24/7
  - обновление базового образа в течение 14 дней после релиза платформы
platform_provides: [базовый образ и сканирование, доступы, метрики и логи]
review_at: 2026-12-01         # дата пересмотра обязательна
sunset_condition: платформа поддержит drain-and-hold — переезд за квартал

Три обязательных элемента: что команда берёт на себя (обычно дежурство и безопасность), дата пересмотра, условие закрытия. Без даты отклонение становится вечным; без явной передачи ответственности платформа отвечает за то, чем не управляет. Подробнее — в следующей главе, Золотой путь.

Первый день как продуктовая воронка

Возьмите нового инженера, дайте задачу «поднять сервис-заглушку и довести до прода» и смотрите молча, ничего не подсказывая.

Ни один шаг не был технически сложным. Всё время съели два класса проблем: ошибки, которые не говорят, что делать дальше, и шаги, требующие живого человека. Первое чинится текстом ошибок — самая дешёвая инвестиция в опыт разработчика; второе — самообслуживанием (Самообслуживание). Метрика, которую стоит завести прямо сейчас: медиана и p90 от создания репозитория до первого выката по когортам новых сервисов (Опыт разработчика).

Сколько стоит платформенная команда

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

# Окупаемость платформенной команды в человеко-месяцах. Модель грубая: её задача
# не предсказать будущее, а показать, насколько ответ зависит от принятия.
MONTH_HOURS = 4.33 * 40    # человеко-месяц ≈ 173 рабочих часа
PRODUCT, PLATFORM = 80, 5  # инженеров в продуктовых командах и на платформе
SAVED_WEEK = 7.0           # экономия на ПРИНЯВШЕГО инженера в неделю, на плато
MIGRATION = 0.5            # разовая цена переезда, человеко-месяцев на инженера
RAMP = 12                  # за сколько месяцев принятие выходит на плато

def simulate(adoption: float, horizon: int = 24):
    """Список (месяц, накопленные затраты, накопленная экономия)."""
    adopted = PRODUCT * adoption
    steady = adopted * SAVED_WEEK * 4.33 / MONTH_HOURS   # экономия в месяц на плато
    cost, saving, rows = 0.0, 0.0, []
    for month in range(1, horizon + 1):
        cost += PLATFORM                                 # платим каждый месяц целиком
        saving += steady * min(month, RAMP) / RAMP       # выигрыш нарастает постепенно
        if month <= RAMP:
            saving -= adopted * MIGRATION / RAMP         # налог на переезд
        rows.append((month, cost, saving))
    return rows

for adoption in (0.70, 0.35, 0.12):
    rows = simulate(adoption)
    be = next((m for m, c, s in rows if s >= c), "не наступает")
    _, cost, saving = rows[-1]
    print(f"принятие {adoption:.0%}: окупаемость — {be}, "
          f"за 24 мес. затраты {cost:.0f}, экономия {saving:.0f}")

# принятие 70%: окупаемость — 18, за 24 мес. затраты 120, экономия 153
# принятие 35%: окупаемость — не наступает, затраты 120, экономия 77
# принятие 12%: окупаемость — не наступает, затраты 120, экономия 26

Сложность — O(горизонт) по времени и памяти; существенна не она, а чувствительность результата.

• Платформа окупается поздно и только при высоком принятии. При 35 % она не окупается вообще — не потому, что плохая, а потому, что постоянные затраты делятся на слишком малое число пользователей: механизм любого продукта с высокой фиксированной себестоимостью.
• Экономия должна быть большой на человека. Семь часов в неделю на принявшего инженера — почти день; если платформа экономит сорок минут, при таком составе она не окупится никогда.
• Миграция — ваш минус в начале. Команды платят временем раньше, чем получают выигрыш; чем дороже переезд, тем выше шанс, что его бросят на середине (Миграции).
• Соотношение размеров важнее абсолютных чисел. Пять на восемьдесят — 6 % мощности разработки; пять на двадцать — 25 %, и такая платформа обязана экономить каждому не меньше дня в неделю (Платформа в небольшой компании).

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

Цена владения инструментами

Отдельная болезнь — решение от инструмента: «мы делаем платформу, значит нам нужны Kubernetes, Backstage и каталог». У инструмента есть цена владения, и назвать её надо до внедрения.

Техника по этим инструментам — в треке DevOps: Kubernetes, Terraform и IaC, Helm и GitOps, стоимость облака. Здесь важны два правила. Двух ремонтников: инструмент принят, когда его умеют чинить минимум двое и оба доступны в рабочее время; один энтузиаст — не принятие, а будущий инцидент с формулировкой «а он уволился». Заранее написанного выхода: до внедрения опишите, как будете отказываться, если не подойдёт; «никак, мы навсегда» означает, что решение дороже, чем кажется. И оговорка про моду: то, что платформенная инженерия обзавелась зрелостными моделями (CNCF Platform Engineering Maturity Model), не означает, что вашей компании нужен полный набор: «мы на втором уровне, надо на третий» — это цель платформенной команды, а не пользователей.

Контракт платформы: SLO, поддержка, депрекация

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

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

Как вести исследование внутри компании

Опрос «что вам добавить» даёт список функций, а не проблем; пользователи внутри компании к тому же вежливы. Работают наблюдения: час рядом с новичком в его первый день; классификация тикетов по причинам (пять одинаковых вопросов — дефект интерфейса, а не документации); разбор форков шаблона (что поменяли все — кандидат в дефолт, что поменял один — в люк); неделя дежурства в продуктовой команде. И самое дешёвое — чтение чужих пайплайнов: обходы видны в коде, и каждый из них заявка, которую до вас не донесли.

#!/usr/bin/env bash
# Ищем обходы платформы в CI-конфигурациях. Не для наказания, а для бэклога.
set -euo pipefail
for repo in repos/*/; do
  ci=$(find "$repo" -maxdepth 2 \( -name '.gitlab-ci.yml' -o -path '*.github/workflows/*' \) || true)
  [ -z "$ci" ] && continue
  hits=$(grep -nE '(^|[^a-z])(aws|gcloud|az|kubectl|terraform|helm) ' $ci || true)  # мимо платформы
  skips=$(grep -nE 'PLATFORM_(SKIP|BYPASS)|--no-platform-checks' $ci || true)       # проверки off
  [ -n "$hits$skips" ] && printf '\n=== %s\n%s\n%s\n' "$repo" "$hits" "$skips"
done

Главный тезис, который эти наблюдения проверяют: платформа должна снижать когнитивную нагрузку команды, а не переносить её (границы команд).

Типичные ошибки

• Считать функции вместо пользователей. «Мы закрыли 14 задач» — не отчёт о ценности.
• Верить мандату. 100 % покрытия при 26 % глубины — это отчёт, а не результат.
• Продавать покупателю, а не пользователю. Инженер голосует обходом, и голос решающий.
• Строить портал первым. Витрина без товара живёт один квартал.
• Обобщать по названию. Три «очереди» могут быть тремя разными задачами, а абстракция без владельца дежурства — общий отказ без общей ответственности.
• Не считать цену миграции. Её платят временем пользователей, и она всегда больше оценки.
• Внедрять инструмент как цель. Kubernetes и Backstage — статьи расходов, а не достижения; отклонение без срока пересмотра — второй стандарт, который вы не признали.
• Мерить среднее. Платформа ломается на хвостах: p90 сборки и худший первый день.

Мини-итог

Платформа — продукт с добровольным потреблением, высокой фиксированной себестоимостью и конкурентом в виде скрипта на 60 строк. Отсюда:

1. Определите «пользуется» проверяемо, по артефактам; меряйте глубину и добровольную долю.
2. Ищите обходы регулярно и относитесь к ним как к бэклогу, а не как к нарушениям.
3. Держите золотой путь путём: легальная альтернатива и отклонения с датой пересмотра.
4. Посчитайте окупаемость честно, с миграционным налогом, и пересчитывайте раз в полгода.
5. Называйте цену владения каждым инструментом до внедрения и пишите план выхода.
6. Дайте платформе SLO, дежурство и правила депрекации — она в критическом пути у других.

Проверочный вопрос на каждый обзор: если бы завтра пользование платформой стало полностью добровольным, сколько команд остались бы? Не знаете ответа — не знаете, есть ли у вас продукт.

Источники

• Bottcher, E. What I Talk About When I Talk About Platforms, 2018 — определение платформы через самообслуживание и добровольность.
• Skelton, M., Pais, M. Team Topologies, 2019 — «тончайшая жизнеспособная платформа» и платформенная команда как поставщик сервиса.
• Fournier, C., Nowland, I. Platform Engineering: A Guide for Technical, Product, and People Leaders, O’Reilly, 2024 — экономика платформенной команды и разговор с бизнесом.
• CNCF TAG App Delivery. Platforms White Paper и Platform Engineering Maturity Model.
• Noda, A., Storey, M.-A., Forsgren, N., Greiler, M. DevEx: What Actually Drives Productivity, ACM Queue, 2023; там же — The SPACE of Developer Productivity, 2021.
• Full Cycle Developers at Netflix, 2018; Google SRE Eliminating Toil; DORA — метрики поставки.

Что дальше

Главный инструмент удержания пользователей — золотой путь: способ сделать типовое дело быстро и правильно. Он же — самый частый способ всё испортить, превратившись из дороги в шлагбаум. Золотой путь: помощь, которая не должна стать забором.