1.5 Источники данных и инструментирование

Обзор и мотивация

Метрика заслуживает доверия ровно настолько, насколько заслуживают доверия данные под ней, и большинство программ метрик тратят гораздо больше усилий на проектирование дашбордов, чем на проверку конвейера, который их питает. Это неправильный порядок. Красиво спроектированная диаграмма, построенная на непоследовательном, самоотчётном или тихо сломанном инструментировании, хуже, чем отсутствие диаграммы вообще, потому что она выглядит авторитетной, оставаясь неверной. Эта тема о неброском фундаменте, который предполагает остальная часть этой книги: откуда на самом деле берутся инженерные данные, когда доверять автоматизированному инструментированию больше, чем самоотчёту, и о сбоях качества данных, которые тихо обесценивают метрику прежде, чем кто-либо это заметит.

Данные программной инженерии происходят из горстки типов источников, у каждого свои характеристики надёжности. Системы контроля версий и конвейеры CI/CD генерируют объективные, снабжённые временной меткой, трудно подделываемые записи о том, что на самом деле произошло. Трекеры задач и инструменты управления проектами генерируют записи, зависящие от того, обновляют ли люди состояние корректно и своевременно, что они часто делают непоследовательно. Опросы генерируют самоотчётные данные, бесценные для вещей, которые никакая система не может наблюдать, вроде удовлетворённости, но подверженные предвзятости воспоминания и эффектам социальной желательности. Платформы наблюдаемости генерируют телеметрию уровня системы, объективную, но покрывающую только то, что было инструментировано. Знание того, из какой категории происходят данные конкретной метрики, говорит вам, насколько ей доверять и какие режимы сбоя отслеживать.

В масштабе корпорации и государства проблемы качества данных усугубляются, потому что расстояние между происхождением данных и их конечным использованием на дашборде растёт через множество систем, интеграций и преобразований. Поле, означающее одно в исходной системе, может означать нечто тонко иное к тому моменту, когда достигает уровня отчётности, и никто ниже по цепочке этого не замечает, потому что число по-прежнему выглядит правдоподобным. Правильное выстраивание инструментирования менее увлекательно, чем правильный выбор фреймворков, но это фундамент, на котором стоит всё остальное в этой книге.

Ключевые принципы

• Предпочитайте инструментирование самоотчёту везде, где система может наблюдать событие напрямую. Временная метка развёртывания из конвейера заслуживает больше доверия, чем самостоятельно заявленный командой подсчёт развёртываний.
• Используйте самоотчёт только для того, что нельзя наблюдать напрямую. У удовлетворённости, воспринимаемого трения и благополучия нет заменителя в системе учёта; спрашивайте напрямую и хорошо проектируйте опрос (тема 3.7). Резервируйте самоотчёт именно для этой категории.
• У данных каждой метрики есть исходная система, метод сбора и известный режим сбоя. Документируйте все три, а не только определение.
• Качество данных тихо разрушается. Конвейер, год назад работавший корректно, сегодня может быть тихо сломан, а дашборд будет продолжать отображать неверное число без жалоб.
• Инструментируйте в точке истины, а не ниже по цепочке после перевода. Каждый переход между событием и дашбордом это шанс для смысла дрейфовать.

Рекомендации

Привяжите каждую метрику к её фактической исходной системе, прежде чем ей доверять

Для каждой метрики на дашборде назовите конкретную систему, генерирующую лежащее в основе событие: конвейер CI/CD для событий развёртывания, хост контроля версий для событий коммита и слияния, трекер инцидентов для записей о сбоях, платформу опросов для самоотчётной удовлетворённости. Если вы не можете назвать точную систему, вы на самом деле не знаете, откуда берётся число, и не можете оценить его надёжность. Это сопоставление предпосылка для хартии управления из темы 1.4, а не отдельное упражнение.

Инструментируйте на событии, а не на отчёте

Самые надёжные данные захватывают событие автоматически в момент его происшествия: конвейер записывает развёртывание в момент его завершения, система контроля версий записывает слияние в момент его приземления. Данные, зависящие от того, что человек вспомнит обновить поле статуса впоследствии, пометить заявку «сделано», вручную записать развёртывание в электронную таблицу, деградируют в точности тем больше, чем дальше они отстоят от фактического события и чем занятее становится ответственный человек. Везде, где существует автоматизированное событие, предпочитайте его заявленному человеком представителю того же факта.

Резервируйте опросы для того, что может сказать только человек

Некоторые вещи по-настоящему нельзя наблюдать из системной телеметрии: чувствует ли инженер, что его работа значима, ощущается ли процесс раздражающим, растёт ли риск выгорания. Это требует спрашивать напрямую, и хорошо спроектированный опрос (тема 3.7 рассматривает механику) правильный инструмент. Ошибка это использование самоотчёта для того, что система могла бы наблюдать напрямую вместо этого, например, просьба к инженерам оценить собственную частоту развёртывания вместо того, чтобы взять её из конвейера, что вносит ненужный шум и предвзятость в данные, которые могли бы быть объективными.

Встройте проверки качества данных в сам конвейер

Относитесь к конвейерам метрик с той же строгостью, что и к продуктивному коду: добавьте автоматизированные проверки, отмечающие, когда источник перестаёт присылать данные, когда распределение поля неожиданно сдвигается, или когда подсчёт неожиданно падает до нуля. Дашборд, тихо отображающий устаревшие или сломанные данные, как будто они текущие, хуже, чем дашборд, видимо показывающий «данные недоступны», потому что первый невидимо подрывает доверие, а второй хотя бы честен о собственных ограничениях.

Документируйте метод сбора наряду с определением

Определение метрики («время выполнения для изменений») неполно без её метода сбора (измеряется от временной метки первого коммита в контроле версий до временной метки продуктивного развёртывания в конвейере, исключая ветки горячих исправлений). Две команды с одним определением, но разными методами сбора всё равно произведут несравнимые числа. Записывайте оба в хартию метрик из темы 1.4 и относитесь к изменению любого из них как к изменению, требующему того же документированного ревью.

Компромиссы: плюсы и минусы

Тип источника	Плюсы	Минусы
Автоматизированное инструментирование конвейера (CI/CD, контроль версий)	Объективно, снабжено временной меткой, трудно подделать, низкие текущие усилия	Требует предварительных инженерных инвестиций для построения и обслуживания
Данные трекера задач и управления проектами	Широко доступны, знакомы командам	Зависит от человеческой добросовестности; часто непоследовательны между командами
Опросы и самоотчёт	Единственный источник для субъективного опыта (удовлетворённость, благополучие)	Предвзятость воспоминания, предвзятость социальной желательности, усталость от опросов
Платформы наблюдаемости и телеметрии	Богатый сигнал реального времени на уровне системы	Покрывает только то, что было явно инструментировано; может быть дорого в масштабе

Центральное напряжение: объективность против охвата. Автоматизированное инструментирование самый заслуживающий доверия источник, но оно вообще не может наблюдать субъективный опыт, в то время как опросы могут достичь именно того, чего не может автоматизация, но несут реальный риск предвзятости. Разрешайте это напряжение, используя автоматизированное инструментирование везде, где событие можно наблюдать напрямую, и резервируя самоотчёт конкретно и только для того, что по-настоящему требует спросить человека, никогда как ленивую замену данным, которые могла бы предоставить система.

Вопросы для обсуждения в команде

1. Для наших пяти важнейших метрик: можем ли мы назвать точную исходную систему и метод сбора для каждой, или мы предполагаем определение, не зная, откуда на самом деле берутся данные? Это удивительно распространённый пробел: метрика принимается из фреймворка или дашборда поставщика по умолчанию, и никто в текущей команде на самом деле не знает, какая система генерирует лежащие в основе данные и как. Проследите каждую до её происхождения как групповое упражнение.

2. Какие из наших метрик полагаются на самоотчёт для чего-то, что система могла бы наблюдать напрямую, и что потребовалось бы, чтобы заменить этот самоотчёт настоящим инструментированием? Самостоятельно заявленные подсчёты развёртываний, самостоятельно заявленные отработанные часы и самостоятельно оценённое время цикла все это распространённые примеры использования неверного источника данных для того, что автоматизация могла бы захватывать более надёжно. Выявите их и приоритизируйте замену самых высокоставочных.

3. Как бы мы узнали, если бы один из наших конвейеров данных тихо сломался? Большинство организаций обнаруживают сломанный конвейер метрик только тогда, когда кто-то замечает, что число выглядит неправдоподобным, что может занять месяцы. Обсудите, есть ли у каких-либо ваших конвейеров автоматизированные проверки здоровья сегодня, и если нет, каким они нужны первыми в первую очередь.

4. Где перевод между системами изменил значение метрики без того, чтобы кто-то принял это решение намеренно? Поле, означающее одно в исходной системе, может означать нечто тонко иное после интеграции или миграции, и получившееся число может выглядеть правдоподобным, оставаясь неверным. Пройдите полный путь данных вашей самой значимой метрики и поищите точки перевода.

5. Документируем ли мы методы сбора, а не только определения, в нашей хартии метрик? Две команды могут разделять имя и определение метрики, вычисляя её по разным методам сбора, производя числа, которые на самом деле не сравнимы. Проверьте выборку ваших хартий на этот конкретный пробел.

6. Как мы отличаем настоящий тренд от артефакта качества данных, когда число неожиданно двигается? Внезапный сдвиг в метрике часто является первым признаком либо реального изменения, либо сломанного конвейера, и чтобы отличить одно от другого, нужно знать источник данных достаточно хорошо для быстрого расследования. Обсудите фактический процесс вашей команды для последнего необъяснённого сдвига метрики, с которым вы столкнулись.

Отраслевой взгляд

Стартап. С небольшим стеком большинство ваших метрик может приходить напрямую от вашего провайдера CI/CD, хоста контроля версий и лёгкого инструмента опросов, без построения кастомных конвейеров. Риск: пропустить даже базовые проверки здоровья, потому что команда движется быстро; пятиминутная автоматизированная проверка того, что источник данных всё ещё присылает события, дешёвая страховка от того, чтобы тихо лететь вслепую.

Малый бизнес. Опирайтесь на встроенную отчётность ваших существующих инструментов, а не стройте кастомные конвейеры данных, которые у вас нет возможности обслуживать. Будьте явны относительно того, какие числа приходят от автоматизированных систем, а какие это оценки, которые кто-то вводит в электронную таблицу, потому что они несут очень разную надёжность, даже если оказываются на одной странице.

Корпорация. Проблемы качества данных усугубляются через интеграции, миграции и границы бизнес-подразделений. Инвестируйте в централизованные, хорошо отслеживаемые конвейеры данных для ваших самых значимых метрик, стройте автоматизированные проверки качества данных как стандартную практику и проверяйте методы сбора, а не только определения, всякий раз при сравнении метрик между бизнес-подразделениями.

Государство. Происхождение данных может нести юридический вес и вес аудита: опубликованный показатель эффективности может нуждаться в том, чтобы пережить внешний аудит не только своего значения, но и всей цепочки сбора. Документируйте родословную данных явно, сохраняйте исторические записи о методах сбора даже после изменения методологии и будьте готовы продемонстрировать именно то, как число было произведено, а не только то, что оно сейчас показывает.

Примеры

Корпорация. Руководство инженерной службы компании финансовых услуг два года отслеживало «время выполнения для изменений», прежде чем обнаружило, что миграция конвейера данных восемнадцатью месяцами ранее тихо переключила источник временной метки с первого коммита на создание пулл-реквеста, сократив видимое время выполнения в среднем на несколько часов по каждой команде без того, чтобы кто-то заметил или одобрил это изменение. Исправление ввело проверку качества данных, сравнивающую распределение каждой метрики неделя за неделей и отмечающую статистически необычные сдвиги для человеческого ревью, поймав ещё два тихих сбоя конвейера в течение следующего года.

Государство. Публичный дашборд надёжности услуг транспортного агентства полагался на смесь автоматизированной телеметрии датчиков и вручную введённых отчётов об инцидентах из региональных офисов. Аудит обнаружил, что регионы с меньшей штатной мощностью систематически недоотчитывались о мелких инцидентах, не из-за нечестности, а просто потому что ручной ввод конкурировал за время с более срочной работой, что означало, что опубликованный показатель надёжности был лучше реальности именно в тех регионах, которые меньше всего могли позволить себе, чтобы недоресурсное обслуживание осталось незамеченным. Исправление агентства заменило ручной ввод инцидентов автоматизированным логированием, запускаемым датчиками, везде, где это было осуществимо, и добавило документированную оценку покрытия ручной отчётности рядом с опубликованным показателем.

Бизнес-кейс: мотивация, ROI и TCO

Отдача от надёжного инструментирования: уверенность. Команда руководства, доверяющая своим данным, может действовать на их основе решительно, в то время как команда, обжёгшаяся на тихо сломанном конвейере, начинает подвергать сомнению каждое число, что замедляет каждое решение, зависящее от метрик. Эта потеря уверенности дорогостоящая и трудно исправимая, часто требующая гораздо больше времени на восстановление, чем стоила бы исходная инвестиция в инструментирование.

Полная стоимость владения хорошим инструментированием включает предварительную инженерную работу по построению надёжных конвейеров и текущую стоимость мониторинга качества данных, в оба из которых легко недоинвестировать, потому что ни один из них не производит собственной видимой плитки дашборда. Это недоинвестирование ложная экономия: стоимость обнаружения тихо сломанного конвейера после месяцев решений, принятых на плохих данных, гораздо выше стоимости построения проверок здоровья, которые поймали бы это в первый же день.

Антипаттерны и ловушки

• Доверие числу без знания его исходной системы: метрика, принятая из фреймворка или настройки поставщика по умолчанию, без того, чтобы кто-либо отслеживал, откуда на самом деле берутся данные.
• Самоотчёт о том, что система могла бы наблюдать напрямую: вносит ненужный шум и предвзятость в данные, которые могли бы быть объективными.
• Отсутствие автоматизированных проверок качества данных в конвейере метрики: тихо сломанный конвейер может месяцами незамеченно выдавать неверные числа.
• Документирование только определения, а не метода сбора: две команды с одним и тем же именем метрики всё равно могут вычислять несравнимые числа.
• Дашборд, отображающий «0» или устаревшие данные как будто текущие, без указания на сбой источника: хуже, чем видимое сообщение «данные недоступны».
• Недоресурсные регионы или команды систематически недоотчитываются из-за бремени ручного ввода: пробел качества данных, коррелирующий именно с теми областями, которые нуждаются в наибольшем внимании.

Модель зрелости

• Уровень 1, Инициация: Никто не может надёжно проследить метрику до её исходной системы; у конвейеров нет проверок здоровья, и сбои остаются незамеченными.
• Уровень 2, Развитие: У некоторых метрик есть документированные источники, но методы сбора непоследовательны, а проверки качества данных в лучшем случае случайны.
• Уровень 3, Стандартизация: Каждая управляемая метрика документирует свою исходную систему и метод сбора; автоматизированные конвейеры предпочитаются самоотчёту везде, где событие можно наблюдать напрямую.
• Уровень 4, Управление: Автоматизированные проверки качества данных отслеживают каждый значимый конвейер, отмечают аномалии для ревью, а родословная данных документирована и подлежит аудиту.
• Уровень 5, Оркестрация: Организация относится к качеству данных как к инженерной дисциплине первого класса с собственным мониторингом и реагированием на инциденты и может по требованию продемонстрировать полное происхождение любой публикуемой метрики.

Идеи для обсуждения

1. Смогли бы мы прямо сейчас, живьём, на этом совещании, проследить наши три важнейшие метрики до их точной исходной системы?
2. Какие из наших текущих метрик полагаются на самоотчёт для того, что система могла бы измерить напрямую?
3. Есть ли сегодня у каких-либо наших конвейеров метрик автоматизированные проверки здоровья?
4. Когда мы в последний раз обнаружили тихо сломанный конвейер данных, и как долго он был неверен?
5. Где ручной ввод данных создаёт разрыв между отчётной и фактической реальностью?

Основные выводы

• Предпочитайте автоматизированное инструментирование самоотчёту везде, где система может наблюдать событие напрямую; резервируйте самоотчёт для по-настоящему субъективного опыта.
• Каждая метрика нуждается в документированной исходной системе и методе сбора, а не только определении.
• Качество данных тихо разрушается; встраивайте автоматизированные проверки в сам конвейер, а не обнаруживайте поломку случайно.
• Инструментируйте на событии, а не ниже по цепочке после перевода, чтобы минимизировать дрейф между тем, что произошло, и тем, что показывает дашборд.
• Стоимость тихо сломанного конвейера, месяцы решений, принятых на плохих данных, намного превышает стоимость проверок здоровья, которые поймали бы это.

Источники и дальнейшее чтение

• Observability Engineering, Чарити Мэйджорс, Лиз Фонг-Джонс и Джордж Миранда.
• Accelerate: The Science of Lean Software and DevOps, Николь Форсгрен, Джез Хамбл и Джин Ким.
• Data Quality: The Accuracy Dimension, Джек Э. Олсон.
• How to Measure Anything, Дуглас У. Хаббард.