Метрики экономики здравоохранения

Тема 63 из 91· Разработка ПО и цифровая доставка

Метрики DORA (DORA Metrics)

Метрики DORA (DevOps Research and Assessment) — это четыре показателя производительности поставки ПО: частота развёртывания, время выполнения изменений, доля неудачных изменений и время восстановления после неудачного развёртывания — плюс надёжность как пятый показатель. Это наиболее валидированные бенчмарки поставки в отрасли, и у каждого есть прямая интерпретация в терминах экономики здравоохранения.

Почему это важно

Десятилетие исследований DORA связывает эти метрики с организационной производительностью. Кластеры отчёта 2024 года: команды элитного уровня развёртывают по требованию (несколько раз в день), проходят путь от коммита до продакшна менее чем за день, у них ~5% неудачных изменений, и восстановление занимает менее часа; команды низкого уровня развёртывают раз в месяц или реже, тратят месяцы, имеют ~40% неудачных изменений и восстанавливаются неделями. Для системы здравоохранения это не тщеславные IT-цифры: они определяют, как быстро клиническая ценность доходит до пациентов и сколько риска несёт каждое изменение.

Математика

Частота развёртывания        = развёртываний в продакшн / время
Время выполнения изменений   = t(развёртывание) − t(коммит), медиана
Доля неудачных изменений     = неудачные изменения / все изменения × 100
Время восстановления (MTTR)  = t(восстановление) − t(сбой), медиана
Надёжность                   = достижение SLO (доступность, задержка, корректность)

Переводы в термины экономики здравоохранения:

Время выполнения     → cost-of-delay.md: недели в конвейере × CoD (£ или QALY/неделю)
Доля сбоев           → частота нежелательных событий от изменения ПО: CFR × стоимость инцидента
Время восстановления → вред от простоя: MTTR × (потерянная клиническая активность + риск для безопасности)/час
Надёжность           → дисконт выгоды: сервис с доступностью 99% приносит ≈ 0.99
                       своей смоделированной выгоды — программный аналог приверженности лечению

Практический пример

Команда ПО потока пациентов треста, до/после инвестиции в инженерию поставки:

                    До           После
Развёртывания       ежемесячно   еженедельно
Время выполнения    6 недель     4 дня
CFR                 25%          8%
MTTR                2 дня        2 часа

Команда выпускает ~30 улучшений в год со средней ценностью на улучшение £4 000/неделю (CoD). Сокращение времени выполнения примерно на 5,4 недели сдвигает поток выгод каждого улучшения раньше: 30 × 5,4 × 4 000 ≈ £648 000/год ценности, доставленной раньше. Улучшение CFR: 30 × (0,25 − 0,08) = ~5 меньше неудачных изменений в год × £15 000 средней стоимости инцидента (простой клинической системы, устранение) = £76 500/год. Инвестиция в поставку оценивается в той же валюте, что и любое клиническое вмешательство.

Связь с разработкой программного обеспечения

Это и есть программная сторона — связь, которую стоит проговорить, — это обратное отображение: метрики DORA — это операционные метрики больницы в другой одежде. Время выполнения ↔ от направления до лечения; доля неудачных изменений ↔ частота повторных госпитализаций (работа, вернувшаяся обратно); MTTR ↔ экстренное реагирование; частота развёртывания ↔ пропускная способность клиники. Методы улучшения переносятся в обоих направлениях, потому что обе системы — очередные системы с ограничениями безопасности. Отметим также находку DORA 2025 об ИИ: внедрение ИИ теперь коррелирует с более высокой пропускной способностью, но худшей стабильностью — вмешательство с эффикасом и побочными эффектами, требующее именно того анализа чистой выгоды, которому учит этот репозиторий (см. продуктивность разработчиков с ИИ).

Подводные камни

  • Игра с метриками: количество деплоев завышается пустыми релизами; CFR занижается за счёт неучёта хотфиксов как сбоев. Определяйте события точно, как HTA определяет конечные точки.
  • Межкомандные турнирные таблицы: кластеры DORA сравнивают практики, а не команды с разными профилями риска; команда клинических систем на уровне «высокий» может быть оптимальной там, где «элитный» уровень был бы безрассудством.
  • Оптимизация одной метрики: скорость без CFR/надёжности — это компромисс между пропускной способностью и стабильностью — всегда отчитывайтесь по всем четырём вместе (это таблица «затраты-последствия», а не единый балл).

Источники