46 записей с тегом "guide"

Крупный автопоставщик, с которым я консультировал в 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 потребителей.

Платформенная команда из 6 инженеров стоит $156K в квартал. Они держат auth, observability, внутренний API gateway, общий кэш и деплой-пайплайн. Восемь продуктовых команд используют эти сервисы каждый день. Спросите CFO, кто за это платит — ответ «центральный R&D». Спросите тимлида платформы, кто это потребляет — ответ «все одинаково». Оба не правы, и зазор между ними — это место, где инжиниринг-финансы каждый год теряют шестизначные суммы на искажённых решениях.

Adrian Cockcroft изначально сформулировал этот аргумент, когда Netflix дробился на микросервисы: общая инфраструктура имеет unit cost, и unit cost должен следовать за запросом. CNCF FinOps Working Group в отчёте 2024 State of FinOps for Engineering нашли, что меньше 24% микросервисных организаций аллоцируют время платформенной команды обратно на команды-потребителей. Остальные 76% считают платформу overhead — то есть команда, потребляющая 41% запросов, получает тот же счёт, что и команда с 1%.

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". Эта статья — о том, что трекать вместо этого.

CTO смотрит на квоту SaaS-биллинга: $52K в год. В переговорной четверо инженеров, каждый стоит примерно $7K/мес. с учётом нагрузки. Математика моментальная: «4 инженера × 4 месяца = 16 человеко-месяцев. Соберём своё за $112K. Дальше бесплатно навсегда». Совет директоров кивает. Закупкам говорят отменить SaaS-evaluation. Через восемнадцать месяцев команда всё ещё владеет своим биллингом, двое инженеров поддерживают его в полставки, а первоначальные четверо в тот квартал не отгрузили ни одной revenue-фичи. Реальная 5-летняя стоимость «build» оказывается $546K, почти вдвое больше SaaS-пути. Forrester в анализе Total Economic Impact of Buy-vs-Build (2023) фиксирует медианное занижение стоимости in-house на 2,3×. Gartner повторяет это в своих TCO-фреймворках уже пятнадцать лет. Большинство команд всё равно не дочитывает математику до конца.

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 — конкретный набор правил и ритуалов, который перевёл две команды, с которыми я работал, с ежемесячных болезненных релизов на ежедневные уверенные.

VP инжиниринга защищает на совете директоров миграцию на микросервисы за $1.2M. Прогноз ROI: «экономим 30% на инфре, релизим в 2 раза быстрее». CFO задаёт один вопрос: «Покажите математику». В ответ — единственное число 240% и никакого метода за ним. Совет говорит нет. Через два квартала конкурент закрывает ту же миграцию за восемь месяцев и начинает выигрывать enterprise-сделки на латентности. Проект был хороший. Проблема — в математике.

Никакой единой «формулы Engineering ROI» не существует. Есть пять разных методов расчёта, каждый собран под свой вопрос. Исследование McKinsey Developer Velocity Index показало, что команды верхнего квартиля генерируют в 4–5 раз больше выручки на разработчика, чем команды нижнего. Но это соотношение ничего не значит без указания, как вы это измерили. Возьмёте не тот метод под вопрос, потеряете защитимый проект. В статье разобраны все пять, с реальными цифрами.

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

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