Стас из Microsoft показал сообществу график стабильности билдов и попросил оценить: ситуация улучшается или ухудшается?
Красное – упавшие тесты (возможно баг, возможно случайность). Зелёное – успешные сборки. Жёлтое – flaky-тесты: упал, перезапустили, прошёл. Линия – общее количество билдов.
Ответы разделились мгновенно. Артур: «Явно хуже становится, раньше соотношение удачных 1:1,15 – сейчас каждый второй неудачный». Василий: «Улучшается – flaky становится меньше, стабильность растёт». Денис выдал развёрнутый анализ и завершил его фразой, ради которой стоит читать дальше.
График – гавно. Чтобы разобраться, нужна бутылка. Столбцы не сопоставимы, легенда однородна – не понятно, что линия, а что столбец.
А потом Стас показал те же самые данные, но сгруппированные по кварталам.
И вот тут всё стало очевидно.
Один датасет – три истории
Стас поставил эксперимент на живых людях. Одни и те же данные о стабильности билдов он показал трижды, каждый раз меняя только масштаб группировки:
По неделям. Хаос. Шум. Мозг не может построить линию тренда визуально. Artурр увидел стагнацию, Василий – улучшение, Жоха заявил, что «график бесполезен». Все правы и все ошибаются одновременно.
По месяцам. Чуть яснее, но сортировка по алфавиту (Apr, Feb, Jan, Mar, May) запутала ещё больше. Азат отреагировал: «Я знал, что люди манипулируют визуализацией статистики, но до такого даже самые выдающиеся гении не догадались».
По кварталам. Наконец видно: жёлтого (flaky) стало вдвое меньше – с 17% до 8%. Зелёного больше. Тренд однозначный – улучшение.
Для метрик важна перспектива. На квартальном графике явно видны улучшения. На еженедельном – ситуация абсолютно не однозначная, потому что мозг не может построить линию тренда визуально. Это какой-то шум. И чтобы сделать выводы – нужно сменить перспективу, масштаб. – Стас
Масштаб, который ломает интуицию
За графиками скрывается контекст, который меняет всё. Это не стартап на трёх микросервисах:
- 2 000 тестов в одном компоненте
- 300 разработчиков в 10 командах
- 1 000–1 500 билд-машин плюс столько же для тестов, плюс около тысячи физических мобильных устройств
- 60–70 релизов в сутки (каждый PR – это релиз)
- Один PR может запустить от 17 до 3 000 параллельных билдов, в зависимости от глубины изменений
Стас привёл математику, которая пробивает интуицию:
Даже если каждый тест из 10 000 имеет 99% SLA – надёжность всей системы составит 36%. Каждый тест в отдельности работает почти идеально. Все вместе – падают чаще, чем проходят.
Один процент ненадёжности, помноженный на масштаб, превращается в системную проблему. И на еженедельном графике эта системная проблема выглядит как случайный шум.
Пять реакций – пять ролей
Самое ценное в этой дискуссии – не ответ, а спектр реакций. Каждый участник подошёл к одному и тому же графику со своей управленческой парадигмой.
Охотник за виновниками
Артур сразу предложил декомпозировать: «По командам и по сотрудникам – найти тех, кто аномально часто крашит билды и нагревает планету сильнее». Он видел инструмент для поиска проблемных зон. «300 человек – прекрасный датасет. Я бы потрогал эту базу».
Подход рабочий для небольших команд, но Стас остудил: одна команда владеет 70% компонента, кодовая база общая, твоё изменение может сломать чужой код. Виновник – не всегда тот, чей билд упал.
Критик визуализации
Денис не стал отвечать на вопрос «лучше или хуже» – вместо этого разобрал, почему сам вопрос некорректен:
Столбцы не сопоставимы. Легенда однородна. Я бы перестроил: столбцы – количество билдов, спагетти-линии – процент по типам тестов. Тогда сразу будет понятно.
Важное наблюдение: плохой график – это не косметическая проблема, а управленческая. Если руководитель не может прочитать дашборд за 30 секунд, он либо проигнорирует данные, либо сделает неверный вывод. Оба варианта дороже, чем переделать визуализацию.
Прагматик
Андрей не стал копаться в деталях: «Управленец должен принимать решение, даже если информация не полная. И не всегда попытки собрать дополнительную информацию реальны». Для него вопрос не в том, что показывает график, а в том, какое решение принять прямо сейчас.
Скептик
Жоха усомнился в самих данных: «А вдруг раннеры или билд-машины сломались? Сеть упала? Весь этот график ничего не показывает». Его позиция – без отделения инфраструктурных проблем от проблем кода график бесполезен.
Стас признал: «Тесты могут быть красными, потому что на билд-агентах нет какой-либо библиотеки и они все стали падать разом». Грязные данные – реальность, с которой приходится работать.
Системный аналитик
Денис подвёл итог тремя тезисами, каждый из которых заслуживает отдельной дискуссии:
Разная гранулярность даёт разные тренды – да, но для разного уровня решений тебе и нужна разная гранулярность. Разная перспектива даёт разные инсайты – да, но у тебя разный уровень полномочий влиять на разные аспекты. Тренд говорит о текущей ситуации – нет, тренд говорит о поведении конкретной метрики.
Последний пункт – ключевой. Метрика – это не реальность. Это модель реальности. И как любая модель, она отражает то, что вы решили измерить, а не то, что происходит на самом деле.
Проблема разработчика, а не менеджера
Есть ещё один аспект, который обычно упускают. Стас описал его изнутри:
Разработчику без разницы, что ему мешает смерджить PR – flaky-тест или инфра-проблема. Если количество инфра-падений или flaky значительное – разработчик не доверяет сигналам. Билд красный? Первая мысль – «это инфра, не я». Он не смотрит свой код, просто перезапускает билд.
Вот она – эрозия доверия к метрикам. Когда система падает часто и по случайным причинам, люди перестают обращать внимание на сигналы. Красный билд становится нормой. А настоящий баг проскакивает незамеченным, потому что все привыкли нажимать «перезапустить».
Исследователь Джон Расмуссен описал похожий механизм в теории управления рисками: системы с высоким уровнем «ложных тревог» приучают операторов игнорировать предупреждения. Чернобыль, Three Mile Island, Boeing 737 MAX – в каждом случае операторы научились не обращать внимания на сигналы, потому что сигналы слишком часто были ложными.
В масштабах билд-системы это не катастрофа. Но принцип тот же: ненадёжная метрика хуже, чем отсутствие метрики.
Чек-лист: как не обмануть себя метриками
- Смотрите на данные в нескольких масштабах: недели, месяцы, кварталы
- Если на одном масштабе – хаос, попробуйте укрупнить
- Проверьте сортировку – алфавитная вместо хронологической ломает восприятие
- Отделите сигнал от шума: инфра-падения, flaky-тесты, реальные баги – это разные категории
- Спросите себя: «Доверяют ли разработчики этой метрике?» Если нет – сигнал бесполезен
- Не ищите виновников по метрикам на общей кодовой базе – изменение одного разработчика может сломать код другого
- Посчитайте «системную надёжность»: 99% на каждый тест ≠ 99% на систему из 10 000 тестов
- Визуализация – это интерфейс к данным. Если руководитель не может прочитать график за 30 секунд – переделайте график, а не руководителя
Какой масштаб правильный?
Никакой. И все одновременно.
Еженедельный масштаб показывает операционный шум – полезен, если вы ищете конкретный инцидент. Месячный – тактические изменения, ретроспективу спринтов. Квартальный – стратегические тренды, обоснование инвестиций.
Проблема начинается, когда менеджер показывает руководству еженедельный график и ожидает стратегических решений. Или когда директор смотрит на квартальный тренд и делает вывод, что «всё хорошо» – не видя, что за благополучной средней скрываются недели полного хаоса.
Артур подытожил просто: «Аналитику нужно смотреть и в хвост, и в гриву, и со всех сторон, и несколько раз». Денис возразил точнее: у глубины анализа есть своя стоимость. «Иногда проще забить на цифры и принять любое решение – это будет лучше, чем не принятие никакого решения».
Какой подход к метрикам ближе вашей команде – копать глубоко или действовать быстро? Обсудить можно в Telegram.
Эта статья основана на обсуждении в чате сообщества «Тимлид не кодит» 19 мая 2026 года, где Стас из Microsoft разобрал реальный кейс с метриками на масштабе 300 разработчиков. Контекст – из инсайтов за 19–24 мая. Присоединяйтесь к обсуждению в Telegram.