Платформа в небольшой компании: с чего начать и когда не начинать

Компания на 24 инженера, пять продуктовых команд, девятнадцать сервисов. На встрече техлидов кто-то произносит фразу, ради которой написан весь трек: «нам нужна платформа». Дальше обычно происходит одно из двух. Либо ничего — потому что все согласились, но ни у кого нет времени. Либо самого сильного инженера снимают с продукта «на квартал», он поднимает Kubernetes, пишет service.yaml и уходит через год в другую компанию, оставив после себя слой, который никто не умеет чинить, и три команды, которые деплоятся мимо.

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

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

Главный вопрос: что именно у вас повторяется

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

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

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

Нулевой шаг: замер на две недели

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

Журналы конвейера дают самую честную часть картины, потому что их никто не заполняет вручную:

# Сколько часов за две недели ушло на ожидание сборок сверх десяти минут.
# Порог в 10 минут — это то, после чего человек переключается на другую задачу.
gh api -X GET "repos/$ORG/$REPO/actions/runs" --paginate \
  -f created=">=$(date -d '14 days ago' +%F)" \
  --jq '.workflow_runs[]
        | select(.conclusion != null)
        | (.updated_at | fromdateiso8601) - (.run_started_at | fromdateiso8601)' \
| awk '{ over = $1 - 600; if (over > 0) sum += over; n++ }
       END { printf "запусков: %d, ожидание сверх 10 минут: %.1f ч\n", n, sum/3600 }'

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

Вот как выглядит результат такого замера в компании из примера. Календарь двух недель — 1920 инженеро-часов.

Три оговорки, без которых эта таблица врёт.

Час ожидания — не потерянный час. Человек переключается на другую задачу; потеря — это стоимость переключения и то, что задача не закрывается сегодня. Считайте ожидание, но не считайте его целиком спасаемым: коэффициент 0,3–0,4 ближе к правде, чем единица, и в колонке «дёшево вернуть» он уже применён.

Вернуть — не значит вернуть сразу. Сорок восемь часов за две недели — это потолок, до которого вы будете идти квартал, потратив на дорогу сто пятьдесят часов.

Замер сам стоит денег. Две недели дневников и шесть разговоров — это примерно двадцать часов чужого времени плюс ваши. Это лучшее вложение из возможных: оно единственное, которое одинаково полезно и при решении «строим», и при решении «не строим».

Арифметика полставки

Теперь считаем. Сорок восемь часов за две недели — это около 104 часов в месяц потенциального возврата. Половина ставки инженера — 75 часов в месяц, которые не пошли в продукт. Разница кажется приятной ровно до тех пор, пока вы не добавите множитель принятия.

# Окупается ли платформенное усилие в компании из 24 инженеров и 5 команд.
HOURS_PER_FTE_MONTH = 150   # рабочих часов инженера в месяц
BUILD_COST_HOURS = 150      # разовые вложения в постройку первых сервисов


def net_monthly(saved_h_month: float, fte: float, adoption: float) -> float:
    """Чистая выгода в часах за месяц: возвращённое время минус стоимость усилия.

    saved_h_month — потолок экономии при полном принятии;
    adoption      — доля команд, которые действительно перешли на общий путь.
    """
    return saved_h_month * adoption - HOURS_PER_FTE_MONTH * fte


for adoption in (1.0, 0.8, 0.6, 0.4):
    net = net_monthly(104, fte=0.5, adoption=adoption)
    payback = BUILD_COST_HOURS / net if net > 0 else float("inf")
    print(f"принятие {adoption:.0%}: {net:+6.1f} ч/мес, окупаемость постройки: {payback:.1f} мес")

принятие 100%:  +29.0 ч/мес, окупаемость постройки: 5.2 мес
принятие  80%:   +8.2 ч/мес, окупаемость постройки: 18.3 мес
принятие  60%:  -12.6 ч/мес, окупаемость постройки: inf
принятие  40%:  -33.4 ч/мес, окупаемость постройки: inf

Это главная таблица главы, и стоит посмотреть на неё пристально. При принятии 60 % половина ставки в компании из двадцати четырёх инженеров — чистый убыток. Не «медленно окупается»: убыток, каждый месяц, навсегда. При 80 % окупаемость постройки — полтора года, то есть дольше, чем живёт средняя внутренняя инициатива и, часто, чем работает в компании её автор.

Отсюда три следствия, которые определяют всю остальную главу.

1. Принятие — не отчётность, а условие существования. В крупной компании низкое принятие означает, что платформа приносит меньше, чем могла бы. В маленькой оно означает, что платформа приносит минус. Метрика «сколько процентов выкатов идёт общим путём» здесь важнее любой другой (принятие).
2. Полная ставка почти никогда не оправдана. Чтобы окупить 150 часов в месяц на 24 инженерах, надо возвращать каждому по полтора часа в неделю — не «в среднем по ощущениям», а проверяемо. Такое бывает, но это редкая ситуация запущенности, а не норма.
3. Каждый лишний компонент съедает маржу целиком. Свой кластер — это плюс 1–1,5 ставки постоянного расхода. При марже в 29 часов в месяц компонент, требующий 20 часов в месяц на поддержку, обнуляет всю затею.

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

Когда не начинать: семь честных «нет»

Отказ от постройки — полноценный результат работы, а не признание поражения. Ниже семь ситуаций, в которых правильный ответ — «сейчас нет», с указанием, что делать вместо.

1. У вас меньше трёх продуктовых команд. Повтора почти нет, а согласование съест больше, чем сэкономит унификация. Вместо: договорённости в одном файле и общий шаблон репозитория.

2. Продукт ещё ищет рынок. Архитектура сменится раньше, чем платформа окупится; всё, что вы зацементируете, придётся ломать. Вместо: управляемые сервисы и максимально скучный стек (скучные технологии).

3. Никто не измерял, куда уходит время. Без замера вы строите не платформу, а гипотезу о платформе. Вместо: две недели замера — это дешевле любого другого шага.

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

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

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

7. «Платформа» в вашей голове — это Kubernetes и портал. Инструмент, выбранный до задачи, — самый дорогой из возможных способов не решить задачу. Вместо: вернуться к списку повторов.

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

Признаки, что пора

Симметричный список. Каждый признак проверяем сегодня, без опросов.

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

Три и больше признаков — есть о чём говорить. Один-два — чините точечно, слой не нужен.

Лестница: сколько платформы уместно при вашем размере

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

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

Что делать вместо платформы, пока вас мало

Скучные решения, которые закрывают 80 % боли при почти нулевой цене владения. Ни одно из них не требует нового постоянного расхода.

Один шаблон репозитория вместо генератора. Репозиторий-шаблон в вашем хостинге git, из которого создаются новые сервисы: Dockerfile, конвейер, healthcheck, структура логов, базовый дашборд, README с командами запуска. Это форк, а не абстракция: копия расходится, и это нормально (шаблоны сервисов). Цена владения — час в месяц на актуализацию.

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

Управляемое всё, что можно купить. База данных, очередь, хранилище объектов, секреты, вход по SSO. Управляемый сервис стоит денег, свой — стоит людей; при двадцати четырёх инженерах люди дороже (стоимость облака, выбор БД).

Одна страница «как у нас всё устроено» вместо портала. Ссылки, владельцы, дежурные, порядок выката и отката. Обновляется вручную раз в месяц и всё равно точнее, чем каталог, который пытались наполнять автоматически и бросили.

Список сервисов, собираемый из репозиториев. Три десятка строк, которые ходят по организации в git, читают файл service.yaml и печатают таблицу «сервис — владелец — язык — версия базового образа». Это не каталог, это отчёт о дрейфе, и он полезнее каталога, пока сервисов меньше сорока.

Минимальный контракт сервиса. Не сорок полей, а пять — тех, без которых нельзя эксплуатировать:

# service.yaml — ровно то, что нужно платформе и дежурному, и ничего больше.
name: billing-api
owner: team-payments          # группа, а не человек; из неё берётся адресат алертов
tier: 1                       # 1 — падение видит клиент, 2 — терпит до утра
runtime: go1.23               # определяет базовый образ и набор проверок в конвейере
oncall: "#payments-oncall"    # куда пишет алерт, если сервис нездоров
# Всё остальное — лимиты, переменные, миграции — живёт рядом с кодом сервиса
# и платформу не касается. Поле добавляется только после третьего запроса.

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

Три вещи, которые окупаются почти всегда

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

Первое: время сборки. Это самая недооценённая позиция, потому что боль размазана по всем и не принадлежит никому. Кэш зависимостей, параллельные работы, отказ от пересборки того, что не менялось, — обычно два-три дня работы и минус 40–50 % времени ожидания. Побочный эффект важнее прямого: когда сборка укладывается в десять минут, люди перестают складывать правки в большие ветки, и меняется размер поставки (DORA).

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

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

Всё, что справа на диаграмме, — не «плохо». Это «не сейчас»: цена владения превышает доступную вам маржу.

Золотой путь на одну страницу

Золотой путь маленькой компании должен помещаться на одну страницу и в один шаблон. Не потому, что вы не способны на большее, а потому, что путь длиннее страницы никто не прочитает, а значит, он не путь, а декларация.

Рабочий формат — семь пунктов, каждый с конкретной командой или ссылкой: как создать сервис, как запустить локально, как выкатить, как откатить, где логи и метрики, как получить доступ к чему-нибудь, кому писать, когда сломалось. Всё. Подробное устройство пути и его типовые болезни — в главе про золотой путь.

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

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

Ситуация не гипотетическая: у вас четыре команды на Go со stateless-сервисами и одна, которая делает модели на Python, тянет GPU, гоняет часовые батчи и не влезает в ваш шаблон ни одним пунктом. Неправильных ответов два: «затащить любой ценой» и «пусть живут как хотят».

Правильный — договориться о минимальном общем интерфейсе и отпустить остальное:

Формат записи отклонения — обычный файл в репозитории платформы, который читается за минуту:

# deviations.md — отклонения от золотого пути: живой документ, а не список нарушителей
- team: ml-platform
  deviates: базовый образ, лимиты ресурсов, форма healthcheck
  keeps: владелец в service.yaml, логи в общий сток, метка расходов, откат одной командой
  reason: GPU-рантайм и часовые батч-задачи; шаблон рассчитан на stateless HTTP
  owner_oncall: команда ML дежурит по своим сервисам сама
  review: 2027-02-01          # не «навсегда», но и не «через месяц»
  platform_action: собрать третий такой запрос — сделать отдельный шаблон под батчи

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

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

Кто это делает: ротация вместо команды

Ответ «выделим человека» в компании на двадцать четыре инженера обычно преждевременен. Работающая промежуточная форма — ротация владения путями: один инженер из продуктовых команд на спринт берёт на себя общие пути, тратит на это до 20 % времени и передаёт дальше.

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

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

Про состав, границы и дежурство настоящей платформенной команды — глава 13; про то, как переводить команды на новое, не срывая поставку, — глава про миграции.

Цена владения: пересчёт на двадцать пять инженеров

Ни один инструмент не хорош и не плох. У каждого есть постоянный расход, который платит ваша команда, а не вендор, — и в маленькой компании этот расход надо сравнивать не с «удобно», а с маржой в 29 часов в месяц из расчёта выше.

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

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

Четыре провала маленькой платформы

Типовые провалы из обзорной главы на малом масштабе выглядят чуть иначе — дешевле в абсолютных числах и опаснее в относительных.

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

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

3. «Мы сделали абстракцию» поверх трёх разных потребностей. Один service.yaml на HTTP-API, ночной батч и сервис с диском: через год в нём сорок полей, из которых двадцать пять игнорируются в двух случаях из трёх. Диагноз: доля полей, используемых менее чем пятой частью сервисов; число ветвлений вида «если тип = batch, то это поле означает другое». Лечение: правило трёх и три честных шаблона вместо одного универсального.

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

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

Что мерить, когда пользователей двадцать

Главное отличие малого масштаба в измерениях: опросы не работают. При двадцати четырёх респондентах и типичном отклике в половину вы получаете двенадцать анкет — на этом нельзя построить ни тренд, ни сравнение; любое изменение будет внутри шума. Зато на таком размере доступно то, что недоступно большим: можно поговорить со всеми. Шесть разговоров по двадцать минут раз в квартал дадут больше, чем любой NPS.

Числа, которые стоит держать, — пять, и все дешёвые:

Последняя строка — обязательная. Замер повторяется той же методикой, что и нулевой, иначе сравнивать не с чем. Что мерить в опыте разработчика по-взрослому и как не обмануть себя средними — глава 03; почему у платформы должны быть свои SLO и как их формулировать — SLI и SLO и глава про наблюдаемость платформы.

Учение «от пустого репозитория до прода» стоит описать отдельно, потому что оно бесценно и почти ничего не стоит. Раз в квартал берёте инженера, который не участвовал в постройке пути, и просите завести новый сервис по документации, засекая время и записывая каждое место, где он застрял. Полдня работы одного человека даёт список дефектов платформы, точнее любого опроса.

План на 90 дней

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

Три правила, которые делают этот план честным.

Одна боль, а не список. Соблазн взять три сразу возникает всегда и всегда заканчивается тремя недоделанными. Одна боль, доведённая до конца в одной команде, даёт вам и результат, и оценку трудоёмкости для остальных.

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

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

Когда платформу пора сворачивать

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

• Управляемый сервис догнал вашу самоделку. Ваш слой писался, когда у провайдера этого не было. Теперь есть, стоит денег вместо людей и умеет больше. Считайте: годовая стоимость поддержки против годовой стоимости подписки плюс миграция.
• Команд стало меньше. Экономия пропорциональна числу потребителей; при падении с двенадцати команд до четырёх та же платформа уходит в минус по той же формуле.
• Принятие не растёт два квартала подряд, несмотря на исправления. Это ответ пользователей, а не их лень.
• Расход на поддержку выше стоимости миграции на стандартное решение. Разовая цена перехода один раз, расход на поддержку — каждый месяц.

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

Чек-лист самопроверки

Двенадцать вопросов. «Да» засчитывается, только если ответ проверяем сегодня, а не «в принципе».

1. Мы знаем в часах, сколько времени в месяц уходит на повторяющуюся не-продуктовую работу?
2. Мы можем назвать три конкретных повтора и цену каждого?
3. Мы знаем долю выкатов в прод, идущих общим путём, за последний месяц?
4. Мы знаем, почему остальные идут мимо, — со слов тех, кто идёт мимо?
5. Новый инженер доходит до первого прод-выката за один день, и это проверено на живом человеке?
6. Золотой путь помещается на одну страницу, и на ней есть команда отката?
7. У каждого отклонения от пути есть запись, причина, дежурный и срок пересмотра?
8. У платформенной работы есть один владелец с именем — или явная ротация с журналом решений?
9. Мы знаем стоимость нашей платформенной работы в часах и сравниваем её с возвращёнными часами?
10. Записано правило остановки: при каком числе мы прекращаем, а не добавляем функции?
11. Если завтра уйдёт главный автор платформы, выкат продолжит работать — и это проверялось?
12. Каждый наш платформенный компонент можно назвать вместе с его постоянным расходом в часах?

Меньше пяти «да» — вам рано строить, начните с вопроса 1: две недели замера. Пять–девять — вы на правильной ступени лестницы, добирайте пропущенное. Десять и больше — можно думать о выделенном владельце и следующей ступени.

Что читать, а что пропустить

Соседние треки портала, которые заменяют половину книг по теме: DevOps — конвейеры, контейнеры, инфраструктура как код; SRE — SLO, дежурства, инциденты; системное мышление — локальная оптимизация и точки воздействия; продуктовое управление — метрики и приоритизация.

Мини-итог

• Платформа делает одно: берёт повторяющуюся работу и делает её один раз лучше. Нет повтора — нет экономии, и никакая архитектура этого не изменит. Первый вопрос не «какая платформа нужна», а «что здесь делается пять раз».
• Замер за две недели — журналы конвейера, дневники, шесть разговоров — стоит около двадцати чужих часов и одинаково полезен при любом решении. Без него вы строите гипотезу о платформе.
• Арифметика беспощадна: при потолке экономии в 104 часа в месяц и половине ставки (75 часов) чистая выгода составляет 29 часов в месяц при полном принятии, 8 часов при 80 % и уходит в минус при 60 %. Постройка окупается за 5 месяцев, за полтора года или никогда — разница только в принятии.
• Полная ставка на двадцати четырёх инженерах требует возвращать каждому полтора часа в неделю проверяемо. Это редкость. Норма для этого размера — ротация с бюджетом до 20 % времени.
• Семь причин не начинать: меньше трёх команд, продукт ещё ищет рынок, нет замера, платформой затыкают конфликт, кандидат — лучший продуктовый инженер, нет владельца на два года, «платформа» в голове означает Kubernetes и портал.
• Лестница проходится по ступеням: соглашения, ротация, выделенный владелец, команда, доменные платформы. Прыжок через ступень даёт слой, которым некому пользоваться.
• Три вещи окупаются почти всегда: время сборки, воспроизводимый локальный запуск, доступы без человека в цепочке. Всё остальное — «не сейчас», потому что цена владения превышает маржу.
• Золотой путь на одну страницу, отклонения — в файле с причиной, дежурством и сроком пересмотра. Три одинаковых отклонения означают второй шаблон, а не сорок первое поле в первом.
• Kubernetes — конструктор для сборки платформ, а не платформа; Backstage — фреймворк на TypeScript, а не готовый продукт. У каждого компонента есть постоянный расход в долях ставки, и при марже в 29 часов в месяц один лишний компонент обнуляет затею. Сначала попробуйте купить.
• Опросы на двадцати респондентах — шум. Работают пять дешёвых чисел, шесть разговоров в квартал и учение «от пустого репозитория до прода» с секундомером.
• Правило остановки записывается до начала работы. Это единственное, что отличает продукт от мандата, и единственное, что позволяет свернуть платформу без позора для того, кто её строил.

Источники

• Matthew Skelton, Manuel Pais. Team Topologies, IT Revolution, 2019 — платформа как способ снизить когнитивную нагрузку, thinnest viable platform.
• Evan Bottcher. What I Talk About When I Talk About Platforms, martinfowler.com, 2018.
• CNCF TAG App Delivery. Platforms White Paper, Platform Engineering Maturity Model.
• DORA Research 2024 — в том числе о неоднозначном влиянии внутренних платформ на скорость поставки.
• Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler. DevEx: What Actually Drives Productivity, ACM Queue, 2023.
• Nicole Forsgren et al. The SPACE of Developer Productivity, ACM Queue, 2021.
• Nicole Forsgren, Jez Humble, Gene Kim. Accelerate, IT Revolution, 2018.
• Camille Fournier, Ian Nowland. Platform Engineering: A Guide for Technical, Product, and People Leaders, O’Reilly, 2025.
• Gene Kim, Jez Humble, Patrick Debois, John Willis. The DevOps Handbook, 2nd ed., IT Revolution, 2021.
• Dan McKinley. Choose Boring Technology — бюджет инноваций.
• Kubernetes. Политика патч-релизов и окно поддержки; Backstage: Adopting; OpenTelemetry — то, что стоит взять из коробки.
• Randall Munroe. xkcd 927: Standards.

Что дальше

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

Куда идти дальше, зависит от того, во что вы упёрлись.

• Упёрлись в технику: конвейеры, контейнеры, инфраструктура как код — DevOps: стратегии выката, Terraform и IaC, стоимость облака.
• Упёрлись в надёжность собственной платформы — SRE: SLI и SLO, дежурство, устранение рутины.
• Упёрлись в границы команд и когнитивную нагрузку — инженерное лидерство: Team Topologies, техническая стратегия, технический долг как разговор с бизнесом.
• Упёрлись в то, что улучшение части ухудшает целое — системное мышление: локальная оптимизация, точки воздействия, архетипы.
• Упёрлись в «как приоритизировать и как доказать ценность» — продуктовое управление: метрики, приоритизация, исследование.
• Смежное по ситуации: секреты и доступы, тесты в конвейере, выбор и миграция БД, прокси и балансировка, метрики поставки.

Общая карта треков портала и порядок прохождения — в дорожной карте.

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