HoginHogin
Назад

DORA-2026: ИИ усиливает то, что у вас есть — нестабильный пайплайн он ухудшает, а не чинит

9 мин чтения

Бюджет на ИИ-ассистентов согласован, пилот запущен — а через квартал деплои срываются чаще, чем до него. DORA в исследованиях 2026 года объясняет, почему это не «плохой ИИ», а арифметика: ИИ — усилитель, а не лекарство. Он умножает объём изменений, который выдаёт команда, — и если система доставки захлёбывалась и раньше, теперь она захлёбывается быстрее.

Почему сейчас: в State of AI-assisted Software Development эффект амплификации назван главным выводом по ИИ — отдача модулируется качеством платформы, а platform engineering переведён из «желательно» в «обязательное условие» (dora.dev). Ниже — что это значит для команды из пяти человек, без энтерпрайз-пафоса, и как за вечер посчитать собственный бейзлайн до покупки любых подписок.

Содержание

Открыть содержание

Four keys — язык, на котором DORA говорит о платформе

DORA (DevOps Research and Assessment) — исследовательская программа, которая с начала 2010-х сопоставляет практики доставки софта с бизнес-результатами. Её словарь — четыре метрики, four keys:

Первые две метрики измеряют throughput — сколько система пропускает; вторые две — stability — сколько при этом ломается. Здравый смысл подсказывает, что это весы: ускоряешься — теряешь надёжность. Данные DORA много лет показывают обратное: команды верхних эшелонов выигрывают по обеим шкалам сразу — не потому, что «работают быстрее», а потому, что их платформа делает маленькие частые изменения дешёвыми и безопасными. Four keys — термометр платформы: они показывают не «хорошо или плохо», а где именно узкое место.

Главный вывод: платформа — модерирующий фактор

DORA меряла, как внедрение ИИ меняет four keys, и получила картину, которая на первый взгляд противоречива: один и тот же класс инструментов у одних команд ускорил доставку, у других — увеличил lead time и change failure rate.

Противоречие снимается одним тезисом: эффект от ИИ модулируется качеством платформы. ИИ резко поднимает объём производимых изменений — кода, PR, миграций, конфигов. Вопрос один: переваривает ли их ваша система доставки. Зрелая платформа пропускает возросший поток — и выигрыш материализуется. Слабая захлёбывается — и тот же поток превращается в очередь, ложные красные и откаты.

Один и тот же ИИ на двух платформах даёт два результата

Отсюда практическая формула: эффект ИИ ≈ качество платформы × прирост объёма изменений. Если множитель меньше единицы, «умный ассистент» ускоряет не вас, а вашу деградацию. Именно поэтому вывод DORA адресован не энтузиастам ИИ, а инженерам платформы: сначала сигнал, потом усилитель.

Почему нестабильный пайплайн от ИИ становится хуже

Механика деградации — не магия, а четыре наблюдаемых механизма:

Один и тот же CI под двумя нагрузками

ИИ не создаёт проблемы слабой платформы — он их подсвечивает. Всё, что терпело десять изменений в неделю, ломается на сорока: тесты, которых не хватает; ручные шаги, которые некому делать вдвое чаще; ревью как единственный контроль качества.

Слабая платформа + ИИЗрелая платформа + ИИ
Объём измененийрастётрастёт — тот же самый
Lead timeрастёт: очередь CI, ожидание ревьюпадает: проверки успевают за генерацией
Deployment frequencyпадает: деплои сливаются в большиерастёт: изменения едут по одному
Change failure rateрастёт: шум глушит сигнална месте: красный CI читают, а не перезапускают
MTTRрастёт: откат большого деплоя дологкороткий: откат одного маленького изменения
Ревьюузкое место, конфликты, очередьвыборочная проверка против golden path
Итог«ИИ нам не помог»«ИИ окупился»

Один инструмент — две газетные цитаты. Разница не в инструменте.

Что усилить до подписки на ИИ

Чек-лист «сначала почини то, что будет умножаться», по убыванию отдачи:

Делать всё сразу не обязательно. Правило одно: найдите самое медленное звено проверки — обычно это e2e-тесты или ревью — и ускорьте его первым. Где узкое место, подскажут те же four keys из следующего раздела.

Мини-DORA за вечер: four keys из логов GitHub Actions

Прежде чем соглашаться с отчётом или спорить с ним, снимите собственный бейзлайн: он считается из логов уже работающего CI — без агентов, дашбордов и покупок. Нужны только gh и Python.

1. Выгрузите историю деплой-воркфлоу:

gh run list --workflow deploy.yml --limit 300 \
  --json createdAt,conclusion,headSha,displayTitle > runs.json

2. Посчитайте четыре метрики:

#!/usr/bin/env python3
# mini-dora.py — four keys из runs.json; запускать в клоне репозитория
import json, subprocess, sys, statistics as st
from datetime import datetime

runs = sorted(json.load(open(sys.argv[1])), key=lambda r: r["createdAt"])
ok   = [r for r in runs if r["conclusion"] == "success"]
iso  = lambda s: datetime.fromisoformat(s.rstrip("Z"))
git  = lambda *a: subprocess.check_output(["git", *a], text=True).strip()
if not ok:
    sys.exit("успешных деплоев нет — проверьте имя workflow")

# deployment frequency — успешных деплоев в день за период
days = max((iso(ok[-1]["createdAt"]) - iso(ok[0]["createdAt"])).days, 1)
print(f"deployment frequency: {len(ok)/days:.2f} деплоев/день")

# lead time — медиана от коммита до успешного деплоя, часы
lt = []
for r in ok:
    c = iso(git("show", "-s", "--format=%cI", r["headSha"]))
    d = (iso(r["createdAt"]) - c).total_seconds() / 3600
    if 0 <= d < 24 * 30:          # отсекаем заброшенные ветки
        lt.append(d)
print(f"lead time (медиана): {st.median(lt):.1f} ч")

# change failure rate — деплои, оказавшиеся фиксами или откатами
fix = sum(1 for r in ok if r["displayTitle"].lower()
          .startswith(("fix", "revert", "hotfix")))
print(f"change failure rate: {fix * 100 // len(ok)}%")

# MTTR — медиана от упавшего деплоя до следующего успешного, часы
gaps = [(iso(n["createdAt"]) - iso(p["createdAt"])).total_seconds() / 3600
        for p, n in zip(runs, runs[1:]) if p["conclusion"] == "failure"]
if gaps:
    print(f"MTTR (медиана): {st.median(gaps):.1f} ч")

3. Запустите в клоне репозитория — нужна история коммитов, lead time считается от времени коммита:

python3 mini-dora.py runs.json

Мини-DORA: от логов пайплайна до четырёх чисел и решения

Оговорки, чтобы не обмануть себя. Lead time здесь — от коммита до деплой-воркфлоу, а не до бизнес-готовности. Change failure rate по префиксам сообщений — прокси: он занижает, если прод чинят без тега fix, и завышает, если fix: пишут в обычных задачах. Для первого бейзлайна и тренда этого достаточно. Повесьте скрипт на еженедельный cron и дописывайте строку в CSV: через два месяца у вас будет не «число», а разброс, с которым можно сравнивать что угодно — хоть эффект от ИИ, хоть эффект от починки flaky-тестов. Дашборд в Grafana — потом, когда метрик станет больше четырёх: пустой дашборд не спасает слабую метрику.

Как проверить, что метрики не врут

Итог

DORA-2026 произнесла вслух то, что каждая команда с больным CI знает и без отчёта: ИИ усиливает то, что уже есть. Зрелая платформа превращает его в ускоритель, слабая — в мультипликатор хаоса, оплаченный подпиской. Порядок поэтому такой: вечер на мини-DORA из логов CI, пара недель на flaky-тесты, бюджет длительности и golden path — и только потом ИИ-подписка, эффект которой вы проверите теми же четырьмя числами. Обратный порядок — сначала усилитель, потом система — сжигает бюджет и заканчивается выводом «ИИ нам не подошёл», хотя не подошёл пайплайн.

Поделиться:
Поделиться в TelegramПоделиться по почте
Следующая статья
Velero: бэкап кластера в S3 и репетиция восстановления — DR, который вы хотя бы раз прогнали