Платформенная команда, управляющая 11 production K8s-кластерами, собирает 94 000 метрик каждые 15 секунд, 2.4 ТБ логов в день в Loki и держит Grafana с 340 дашбордами. Когда VP of Engineering спросил "шипим ли мы на K8s надёжно?", никто не смог ответить быстрее чем за час. У них есть cluster observability. Нет engineering observability.

Это две разные задачи. Cluster observability отвечает, здоровы ли поды. Engineering observability отвечает, здорова ли инженерка поверх этих кластеров — быстро ли идут деплои, редки ли откаты, ждут ли разработчики инфры или воюют с ней. Большинство K8s-шопов решили первую задачу и забыли про вторую. Ежегодный отчёт CNCF 2024 сообщил: 68% корпоративных пользователей K8s борются с тем, чтобы "сделать observability actionable" — вежливая формулировка для "метрики есть, решения из них не выходят".

В отчёте LinkedIn Workforce Report 2024 «несогласованность HR и инженерии» отмечена как причина №2, по которой масштабирующиеся tech-команды теряют сеньоров — сразу после компенсации. Типичный failure mode: HR рисует уровни по generic-шаблону, инженерия ведёт калибровку как недокументированный бэк-канал, и через два месяца лучший сеньор ушёл, потому что его тайтл не обновился вместе с зоной ответственности.

Это не HR-проблема и не инженерная проблема. Это проблема партнёрства, которая всплывает каждые 6–12 месяцев во время промо- и комп-циклов. Вот playbook, как сделать так, чтобы партнёрство реально работало — кто чем владеет, когда и какие данные шарятся.

Инженер с 3,5-летним стажем в 120-человеческом скейлапе, с которым я работал в прошлом году, был «очевидно сеньор» — по интуиции всех. Её данные Git и IDE говорили другое: она шипила больше фич, чем любой сеньор команды, но не ревьюила PR за пределами своего сквада, никогда не вела system-design-proposal от начала до конца, а её коммиты кучковались в узкой области из 2 компонентов. Гут её менеджера говорил «сеньор». Поведенческие данные говорили: готова через 6-9 месяцев, не сегодня. Ревизит через 6 месяцев подтвердил: она дошла, и промоушен зашёл сильнее, чем зашёл бы интуитивный.

Решения о промоушене ошибаются в двух направлениях. Promote-too-early производит недоподдержанных сеньоров, тихо недорабатывающих и иногда уходящих. Promote-too-late теряет ваших лучших инженеров в пользу конкурентов, первыми увидевших готовность. Исследование First Round Review 2023 по инженерным карьерам обнаружило: крупнейший драйвер сожаления senior-инженеров — «повысили до того, как был готов», отмечено 41% респондентов. Критерии на данных снижают обе ошибки.

Бывший инженер Expedia сказал фразу, которую стоит повесить над столом любой travel-команды: «Мы не релизим софт — мы релизим обещания о будущей доступности физических объектов». Запрос к Amadeus GDS возвращает инвентарь, который одновременно разбирают 50+ конкурирующих distribution-каналов. Ваш код должен это свести меньше чем за 400ms, иначе пользователь уходит.

Отчёт Phocuswright 2024 оценивает глобальную индустрию онлайн-тревела в $1.06 трлн gross bookings, из которых ~38% проходит через технологические платформы между путешественником и поставщиком. Аналитика travel-вертикали AWS фиксирует: пиковый трафик на букинг-движках регулярно превышает годовой baseline в 15 раз — более экстремальная асимметрия, чем у любой другой e-commerce вертикали кроме Black Friday retail. Команды, построенные на предпосылке «просто масштабируемся горизонтально», в первый декабрь обнаруживают, что промахи поискового кеша при недоступности GDS генерируют каскадные отказы на 90 секунд в глубину.

В нашем IDE-датасете из 100+ B2B-компаний инженеры AdTech-платформ деплоят на 38% меньше pull request'ов в месяц, чем инженеры в SaaS-тулинге — и при этом приносят больше выручки на человека. Параллельно The Trade Desk раскрыл, что обрабатывает более 13 миллионов ad-запросов в секунду. Масштаб такого порядка переопределяет, что значит «продуктивный». Счётчик PR'ов, который в консюмер-приложении выглядел бы тревожно, абсолютно нормален, когда одна строка конфига деплоится на 10М QPS.

Инженерия в AdTech устроена иначе, и мерить её дженерик DORA-дашбордом значит промахнуться мимо сути. В статье — что реально едят время у data-heavy команд, как выглядят цифры в 14 AdTech-компаниях нашего датасета и какие сигналы продуктивности важнее throughput для RTB, атрибуции и ad-серверов.

Опрос Уилла Ларсона 2021 года среди 14 Staff-инженеров крупных tech-компаний дал вывод, который большинство лестниц до сих пор игнорирует: только один из трёх Senior-инженеров хочет титул Staff, и из них меньше половины получают его за пять лет. Промоушен — не естественное продолжение Senior. Это смена роли — другая работа, другие сигналы, другие режимы провала. Лестницы, где Staff — это "Senior+", производят застрявшие карьеры и очередь IC-инженеров, уходящих в EM-роль в другую компанию.

Этот framework — то, что реально предсказывает готовность: синтез исследования Ларсона, книги Тани Рейли The Staff Engineer's Path и паттернов, которые мы видим в delivery-данных 100+ B2B-инженерных организаций.

Когда Super Bowl LVIII шёл на CBS в 2024, пик одновременных зрителей достиг 123 миллионов — это не KPI, это задача по физике. Финал Ahsoka на Disney+ дал 14 миллионов логинов за 15 минут. Бой Тайсона-Пола у Netflix в конце 2024 упал публично — в Twitter стек буквально сдох на ~60 миллионах одновременных стримов. Media-инженерия не оптимизирует средний throughput. Она оптимизирует тот час в квартале, когда графики уходят вертикально вверх.

Компании, которые это умеют, сходятся на конкретной форме команды, конкретной каденции релизов и конкретных привычках измерения, которые не применимы к обычному B2B SaaS. Снимать DORA с streaming-платформы и сравнивать с CRM — как сравнивать яблоки и тайфуны. Это полевой гайд для инженерных руководителей, которые ведут — или вот-вот поведут — media-платформу через пик.

Principal-инженер в финтехе на 200 человек за Q3 написала 180 строк кода. Её команда за тот же период отгрузила 340 000 строк. Когда CTO посмотрел дашборды coding-time для performance review, её едва не пометили как отстающую. Что реально произошло в Q3: она переписала спецификацию сверки платежей, разблокировав две команды, менторила трёх senior-инженеров в tech-lead, и закрыла полугодовой проект, который отгрузил бы то, что рынку не нужно. Её измеримый output был крошечный. Её impact — крупнейшим среди всех инженеров компании за квартал.

Это парадокс измерения principal-инженера. Каждый staff-plus-фреймворк (Will Larson, книга Tanya Reilly The Staff Engineer's Path, внутренняя лестница Google) это признаёт: principal-инженерам платят за суждение и умножение силы, а не за throughput. Но большинство инженерных организаций меряют их как senior-инженеров с большим титулом. Эта статья — о том, как честно измерять principal-impact, и как самому principal мерить свой impact к моменту review.

Инженерная команда delivery-платформы работает с нагрузкой принципиально другой формы, чем B2B SaaS. Мобильное приложение курьера пингует локацию каждые 3–5 секунд. Консоль диспетчера ждёт sub-200ms на назначение заказа. Route-optimization крутит комбинаторику ночью и обязан закончить до утренней смены. Отчёт McKinsey по last-mile 2024 оценил час простоя диспетчерской в $12,000–$35,000 для среднего регионального перевозчика.

Эта форма работы меняет то, какие инженерные метрики реально важны. DORA Four Keys всё ещё применимы, но картина delivery performance и team health смещается. Вот метрик-стек, который ложится на логистические команды — и места, где «скопируй SaaS-DORA-дашборд» вводит в заблуждение.

Один CTO маркетплейса сказал фразу, которую я слышу регулярно: «Supply-команда релизит быстро, demand-команда релизит быстро, а GMV стоит». Оба DORA-дашборда были зелёными. Matching-движок — нет. У двусторонних продуктов есть метрический разрыв, которого нет у односторонних SaaS: инженерный выход на одной стороне создаёт бизнес-ценность только в том случае, если ему отвечает выход на другой.

Фреймворк маркетплейсов от a16z ставит liquidity — вероятность того, что листинг реально совершит транзакцию в окне, — на первое место по прогностической силе здоровья маркетплейса. И это инженерный исход, не маркетинговый. Когда P95 поискового запроса растёт на 200ms, конверсия листингов падает измеримо. Когда онбординг продавца занимает 14 дней вместо 4 — кривая роста supply уплощается в пределах квартала.