Три года назад команда включила feature-флаги — казалось, это ответственный подход: постепенные раскатки, kill switch, A/B-тесты. Сегодня в flag-сервисе 87 живых флагов, и никто в команде не может объяснить, что делают 34 из них. Два флага прямо сейчас противоречат друг другу в проде. Один должен был быть удалён в 2024. Airbnb публично описал тот же сценарий в 2023 — они дошли до 6000+ флагов, прежде чем полный аудит заставил сделать чистку. GitHub отчитался о 3700 одновременно работающих экспериментах на пике.

Проблема не в feature-флагах. Проблема в том, что команды считают флаги бесплатными — дёшево добавить, не видно обслуживать. Этот плейбук — lifecycle-фреймворк, который работает для команд от 10 до 200 инженеров, подкреплённый данными 100+ B2B-компаний, которые мы трекаем через IDE heartbeats. Цель: чтобы количество флагов росло примерно с размером команды, а не с её возрастом.

Крупный автопоставщик, с которым я консультировал в 2024, получил production-баг во вторник в 03:15. Фикс написали за 8 минут и выкатывали 19 дней — потому что требовался софт-апдейт PLC на 14 производственных ячейках, каждую из которых можно было обновить только в 4-минутное окно между сменами. Средний lead time инженерной команды на офисной IT-стороне — 31 час. На shop-floor-стороне — 14 дней. Та же команда, тот же репозиторий, две разные вселенные constraint'ов delivery.

Manufacturing software engineering — это Agile, столкнувшийся с железом. Практики, работающие в SaaS-стартапе — deploy-whenever, feature flags, canary-релизы — сталкиваются с регулируемой реальностью plant floor: цели OEE, стоимость changeover, разделение OT/IT и production-линии, которые нельзя остановить ради деплоя. Исследование Deloitte Smart Factory 2023 обнаружило, что 73% производителей называют «интеграцию IT/OT» главным барьером цифровизации. Дело не в технологии — дело в том, что метрики и ритуалы, придуманные для чистого софта, ломаются, когда софт касается физического процесса.

Twilio поддерживает 14 активных версий API. Stripe фиксирует каждого клиента на версии, активной на момент регистрации, и держит версии аж с 2011 года. GitHub REST параллельно ведёт три major-версии и шлёт deprecation-заголовки за 12 месяцев до отключения. Ваша команда, скорее всего, пытается выжить с одной — и спорит, куда пихать версию: в URL, header или Accept.

Этот спор на самом деле — три разных решения, склеенных в один аргумент: где живёт версия, как скоупятся breaking changes и когда старые версии умирают. Правильный ответ на одно не спасёт, если два других кривые. Это плейбук на основе того, как реально работают компании с публичным API на скейле, плюс что мы видим внутри PanDev Metrics у клиентов с внутренними API на 20-200 потребителей.

PropTech-команда, с которой я работал в прошлом году, отгружает 4,2 деплоя в неделю по флагманскому продукту. Их CEO сравнивает это с бенчмарком по SaaS-портфелю и делает вывод: "средненько". Неправда. Финтех с похожим штатом даёт 7,1; чистый B2B SaaS — 9,4. PropTech живёт на пересечении регулируемых данных, геопространственной сложности и MLS-интеграций из 90-х — и сырое число деплоев скрывает, с чем реально борется инженерная команда.

Stack Overflow Developer Survey 2024 помещает real-estate software в нижнюю треть по отчётной скорости сборки и интеграционных тестов. DevEx-бенчмарки Microsoft Research 2024 показывают, что регулируемые отрасли теряют в среднем 23% инженерного throughput только на compliance friction. PropTech накладывает сверху геопространственную сложность.

Обычный JavaScript-сервис импортирует 47 прямых зависимостей и в итоге резолвит 2500+ транзитивных пакетов. Тот же сервис, переписанный на Go, импортирует 12 модулей и резолвит 42. pip-эквивалент — около 180. Это не вкусовщина, это форма каждой экосистемы. Ваша стратегия зависимостей обязана стартовать именно с этой реальности.

Уровень supply-chain-риска, дисциплина lockfile и каденция апгрейдов должны быть разными в каждой экосистеме. Это playbook, как это сделать в npm, pip и Go modules — трёх экосистемах, которые по данным Stack Overflow Developer Survey 2025 покрывают примерно 84% production-кода на бэкенде.

Команда, которая делает батарейный сельхоз-сенсор, гоняет CI-пайплайн 38 минут: собрать firmware, прошить HIL-стенд, прогнать 12-минутный on-device smoke, опубликовать артефакты. Их коллеги из веб-команды пушат в main и видят зелёные галки за 7 минут. Когда обе команды меряют по deployment frequency, firmware-команда выглядит отстающей в 5 раз. Они не отстают. Они делают более сложную работу с более длинным циклом обратной связи, а метрика этого не видит.

Большинство инженерных метрик построены под веб: быстрые билды, обратимые деплои, observability с первого дня. IoT- и embedded-команды наследуют эти метрики и выглядят на их фоне плохо. Фреймворк DORA это явно признаёт — отчёт Accelerate State of DevOps 2023 отмечал, что "команды, шипящие embedded или регулируемый софт, имеют другое распределение и не должны сравниваться с веб-командами по deployment frequency". Эта статья — о том, что трекать вместо этого.

Production-релиз в 60-инженерной SaaS-команде, с которой я работал в 2025, выкатили в пятницу в 16:48. Пейджер on-call сработал в 17:22 — 34 минуты скрытого фейла в фиче, которую release manager одобрил «потому что CI зелёный». Rollback занял 71 минуту, потому что автоматизацию никогда не прогоняли на реальном трафике. Итог: один возврат клиенту, две потерянные на выходных команды и политика, которую надо было ввести с первого дня.

Release management — это неглянцевая половина delivery. Отчёт DORA State of DevOps 2024 напрямую связывает change failure rate и MTTR с дисциплиной релизов, а не с талантом инженеров или test coverage. Этот playbook — конкретный набор правил и ритуалов, который перевёл две команды, с которыми я работал, с ежемесячных болезненных релизов на ежедневные уверенные.

В инженерной культуре Google есть правило: до первой строчки кода для любой нетривиальной задачи пишется design doc. Не 40-страничный монумент, а обычно 5-12 страниц, с двумя ревьюерами и комментариями на полях. Команда Engineering Practices из Google публично называла это одним из самых дешёвых рычагов качества в компании.

Большинство команд вне Google либо пропускают этот шаг, либо прикручивают шаблон в Confluence к существующему процессу и смотрят, как он атрофируется. Шаблон ниже — тот, который реально выживает при встрече с уставшим ревьюером в 16:45 в четверг. Это тот момент, когда спека живёт или умирает.

Команда из 40 инженеров за 8 месяцев приняла одно и то же архитектурное решение дважды — в июне и в феврале, оба раза откатила. После второго отката наконец внедрили RFC-процесс. Разбирая историю коммитов, они обнаружили: оригинальный контекст остался в Slack-треде, который автоматически архивировался через 90 дней, а инженер, который владел решением, уже уволился. RFC-документ стоил бы 4 часа на написание и сэкономил бы примерно 3 инженеро-недели переделок.

RFC-процессы существуют потому, что технические решения переживают людей, которые их приняли. Stripe, Cloudflare, Oxide Computer и проект Rust публично описывают свои RFC-форматы — и общая структура уже, чем кажется большинству команд. Эта статья — тот самый шаблон, к которому они сходятся, плюс реалистичный ревью-цикл для команд 10-80 человек, плюс честные цифры о том, когда RFC просто тратят время.

Команда из 60 инженеров, с которой я работал в прошлом году, имела 1400+ страниц Confluence, Notion-воркспейс на 380 страниц, GitHub wiki в каждом из 22 репозиториев и Google Drive с «командными знаниями». Задачей новой сотрудницы на второй неделе было найти runbook стейджинга. Ушло четыре часа. Он существовал во всех четырёх системах, с тремя разными URL, двумя противоречивыми версиями и одной корректной, но устаревшей на три года инструкцией в wiki.

Это сравнение четырёх подходов к knowledge management — Confluence, Notion, GitHub Wiki, Git-native docs (Obsidian/MkDocs/Docusaurus поверх репозитория) — и фреймворк выбора. Microsoft Research в отчёте по productivity 2024 назвал «не могу найти документацию» фактором трения №3 после медленных билдов и сломанных тестов, выше задержек code review. Выбор инструмента не нейтрален: он определяет, будет ли документация написана, найдена и доверяема.