Платформенная команда, управляющая 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-инженерных организаций.

В одной 80-человечной инжиниринг-команде, с которой мы работали в марте 2026, ежемесячный обзор затрат шёл 90 минут. Шесть дашбордов. Четыре руководителя отделов, каждый защищает свои цифры. Итог: сообщение в Slack «давайте копнём глубже в следующем месяце». То же сообщение в феврале. И в январе. Дашборды были отличные. Решений не было ни одного.

Проблема не в нехватке данных. Отчёт Asana Anatomy of Work 2024 показал, что knowledge workers тратят 58% дня на «работу о работе»: митинги, статусы, обзоры дашбордов, и что типичный review-митинг не приводит ни к одному конкретному действию. Инженерные cost-обзоры — учебниковый случай. Слишком много чисел, нет forcing function для решения.

Открываем страницу Finances в организации с 38 активными проектами. По умолчанию — сортируемая таблица: имя проекта, расход за 30 дней, расход за всё время, owner, статус. Ежемесячный cost-review CFO начинается отсюда. 38 строк, 8 минут скролла, и в 60% случаев самый дорогой проект сидит на 17-й строке, куда никто реально не доходит. Эдвард Тафти ещё в The Visual Display of Quantitative Information (1983, 2-е издание 2001) показал: человек обрабатывает цвет и размер раньше, чем числа. Heatmap тех же 38 проектов выводит тёмно-красный квадрат меньше чем за секунду. Стивен Фью в Information Dashboard Design (2006, 2-е издание 2013) приходит к тому же выводу через индустриальные исследования: когда задача — «найди выброс», табличный вид это неправильное primary view. В виджете Projects Heatmap у PanDev Metrics обе модели идут бок о бок. Эта статья о том, почему mosaic должен быть дефолтом, а list — проверкой.

Когда 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.