9.1 Глоссарий

Определения терминов и аббревиатур, используемых по всей книге. Каждый пункт называет тему, где термин вводится подробно.

Бюджет ошибок. Допустимое отклонение между целью уровня сервиса и 100% надёжностью, рассматриваемое как расходуемый ресурс. См. тему 6.1.

Время выполнения для изменений. Время от первого коммита изменения кода до его успешного развёртывания в продакшене. Одна из четырёх метрик DORA. См. тему 2.10.

Время потока. Общее истёкшее время от входа элемента потока в поток создания ценности до его доставки. См. тему 2.4.

Время процесса (PT). Фактическое время, потраченное непосредственно на работу над единственной единицей, из классического картирования потока создания ценности Lean. См. тему 2.8.

Время такта (такт-тайм). Максимальное приемлемое время для завершения единицы работы, чтобы чисто соответствовать спросу клиента, из классического картирования потока создания ценности Lean. См. тему 2.8.

Время цикла. Внутренняя разбивка времени потока на составляющие этапы: кодирование, ревью, тестирование и развёртывание. См. тему 2.6.

Горячая точка. Файл или модуль, одновременно часто изменяемый (высокий объём изменений) и высокосложный, определённый через анализ горячих точек. См. тему 4.3.

Дерево метрик. Структура, связывающая метрику результата верхнего уровня через её движущие факторы с операционными метриками, которыми владеют отдельные команды. См. тему 1.3.

Доля неудачных изменений. Процент развёртываний, вызывающих отказ в продакшене, требующий устранения. Одна из четырёх метрик DORA. См. тему 2.10.

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

Закон Литтла. Доказательство: среднее число элементов в стабильной очереди равно среднему темпу поступления элементов, умноженному на среднее время, которое элемент проводит в системе. Применённый к доставке: незавершённая работа равна темпу поступления, умноженному на время цикла. См. тему 2.7.

Контрольная карта. Диаграмма, показывающая нормальный диапазон вариации метрики со временем, используемая для отличения подлинного сдвига от обычного шума. См. тему 1.6.

Метрика активности. Счёт инженерного движения (коммиты, запросы на слияние, строки кода), измеряющий объём, а не ценность. См. тему 3.4.

Метрика-путеводная звезда. Единственная мера, лучше всего отражающая основную ценность, которую доставляет организация, находящаяся на вершине дерева метрик. См. тему 1.3.

Мутационное тестирование. Техника, намеренно вводящая небольшие, искусственные дефекты в код, чтобы проверить, действительно ли набор тестов их ловит, как дополнение к покрытию. См. тему 4.2.

Нагрузка потока. Общее число элементов потока, в данный момент активных или ожидающих в потоке создания ценности. См. тему 2.4.

Незавершённая работа (WIP). Счёт пунктов, над которыми активно работают в любой данный момент по команде или системе. См. тему 2.5.

Поток создания ценности. Сквозная последовательность действий, превращающих идею в ценность, получаемую клиентом, единица измерения Flow Framework. См. тему 2.1.

Процент полноты и точности (%C/A). Процент единиц, которые команда ниже по течению может обработать без необходимости переделки, из классического картирования потока создания ценности Lean. См. тему 2.8.

Распределение потока. Доля завершённых элементов потока, принадлежащих каждому типу элемента потока, за данный период. См. тему 2.3.

Совокупный выход (rolled throughput yield). Перемноженные показатели процента полноты и точности каждого этапа потока создания ценности, раскрывающие, как переделка усугубляется по многоэтапному конвейеру. См. тему 2.8.

Страховочная метрика. Сочетанная контр-метрика, не должная деградировать, пока улучшается стимулируемая метрика, спроектированная ловить манипулирование. См. тему 1.2.

Телеметрия результата. Непрерывное, инструментированное измерение реальных результатов, а не активности или выработки. См. тему 7.4.

Теория очередей. Математическое изучение линий ожидания, применённое к конвейерам доставки, чтобы объяснить, как незавершённая работа, темп поступления и утилизация движут временем ожидания. См. тему 2.7.

Технический долг. Накопленная стоимость прошлых сокращений пути в кодовой базе, метафора для управляемого компромисса, а не постыдный секрет. См. тему 4.5.

Тщеславная метрика. Метрика, надёжно растущая, выглядящая впечатляюще и не меняющая никакого решения. См. тему 1.1.

Утёкший дефект. Дефект, достигающий продакшена и затрагивающий реального пользователя, в отличие от пойманного при обзоре или тестировании. См. тему 5.1.

Утилизация. Доля доступной мощности ресурса, которая занята, вычисленная как темп поступления, делённый на темп обслуживания. Время ожидания растёт резко, а не постепенно, по мере приближения утилизации к полной мощности. См. тему 2.7.

Фактор автобуса. Число людей, которые должны стать недоступными, прежде чем система или часть знания станет неподдерживаемой. Фактор автобуса один серьёзный риск. См. тему 3.5.

Фреймворк SPACE. Пятимерный фреймворк продуктивности разработчика: удовлетворённость и благополучие, результативность, активность, коммуникация и сотрудничество, и эффективность и поток. См. тему 3.1.

Цикломатическая сложность. Счёт независимых путей через поток управления части кода, введённый Томасом Дж. МакКейбом в 1976 году. См. тему 4.1.

Частота развёртывания. Как часто команда успешно выпускает в продакшен. Одна из четырёх метрик DORA. См. тему 2.10.

Элемент потока. Единица работы Flow Framework: пункт функции, дефекта, риска или долга, классифицированный при приёме. См. тему 2.2.

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

CVSS (Общая система оценки уязвимостей). Стандартизированная шкала для оценки серьёзности уязвимости безопасности. См. тему 6.4.

DevEx (опыт разработчика). Более широкая, родственная SPACE формулировка, организованная вокруг циклов обратной связи, когнитивной нагрузки и состояния потока. См. тему 3.7.

DORA-метрики. Четыре метрики из программы DevOps Research and Assessment: частота развёртывания, время выполнения для изменений, доля неудачных изменений и время восстановления после неудачного развёртывания. См. тему 2.10.

FinOps. Дисциплина привнесения финансовой подотчётности к переменным расходам на облачную инфраструктуру. См. тему 5.4.

Flow Framework. Управленческая модель, созданная Миком Керстеном, рассматривающая разработку программного обеспечения как поток создания ценности и измеряющая его четырьмя типами элементов потока и пятью метриками потока. См. тему 2.1.

MTTA (среднее время до подтверждения). Время от уведомления об инциденте до того, как кто-то берёт на себя ответственность за реагирование. См. тему 6.2.

MTTD (среднее время до обнаружения). Время от фактического начала инцидента до того, как кто-то замечает, что он произошёл. См. тему 6.2.

MTTR (среднее время восстановления / среднее время до решения). Время до полного восстановления сервиса после отказа. Используется и для отказов, вызванных развёртыванием (тема 2.10), и для общих инцидентов (тема 6.2).

ROI (возврат инвестиций). Финансовая отдача инициативы относительно её стоимости, построенная здесь из задокументированной стоимости и доказательства результата, а не предположения. См. тему 5.5.

SLI (индикатор уровня сервиса). Напрямую измеренный сигнал здоровья сервиса, такой как задержка или доля ошибок. См. тему 6.1.

SLO (цель уровня сервиса). Целевой диапазон для индикатора уровня сервиса. См. тему 6.1.

SRE (инженерия надёжности сайта). Дисциплина, впервые разработанная в Google, применения подходов программной инженерии к эксплуатации и надёжности. См. тему 6.1.

TCO (полная стоимость владения). Полная стоимость инициативы или системы за её жизненный цикл, включая постоянное обслуживание и инфраструктуру, а не только первоначальную стоимость. См. тему 5.5.

Юнит-экономика. Стоимость, выраженная на значимую единицу доставленной ценности (на клиента, на транзакцию), а не как непрозрачная сумма. См. тему 5.4.