Мы научились писать код быстрее. Почему программное обеспечение не стало надёжнее?

Допустим, команда стала быстрее реализовывать изменения. Код раньше попадает в запрос на проверку (pull request), но до пользователей доходит не сразу: ждёт проверки, исправления конфликтов, свободного окна для развёртывания. После выпуска ещё нужно убедиться, что функция работает с реальными данными и не нарушает соседние сценарии.

Почему такое ускорение само по себе не гарантирует более надёжный продукт? Для ответа нужно определить, какую скорость мы увеличили и какую надёжность собираемся оценивать.

Вопрос в заголовке не утверждает, что надёжность программного обеспечения во всей отрасли снизилась. Для такого вывода нужны сопоставимые данные за разные периоды. Здесь рассматриваем более узкое условие: если создание изменений ускорилось, что должно произойти дальше, чтобы улучшение почувствовал пользователь?

Разделим наблюдения на три уровня:

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

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

Куда уходит время между готовым кодом и работающим изменением

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

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

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

Пример с сервисом заказов

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

Сценарий условный: он не основан на измерениях или зарегистрированном инциденте. Он показывает, какие свойства нужно проверить до выпуска и какие наблюдать после него. Ответ API с кодом 200 подтверждает лишь успешный HTTP-ответ, но не корректность всех денежных инвариантов.

Как увидеть, где находится ограничение

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

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

Что подтверждают тесты и проверка кода

Автоматическая проверка сообщает результат конкретного набора условий в конкретном окружении. Если тест проверяет итоговую сумму одного заказа, он не доказывает правильность округления всех валют, прав доступа или повторных операций. Успешная сборка подтверждает прохождение её проверок; она не гарантирует отсутствие дефекта в production.

В главе Google SRE о тестировании надёжности объясняется, что пройденные тесты уменьшают неопределённость для проверяемых свойств системы. Это помогает прогнозировать поведение после изменения, но само по себе не доказывает надёжность всего сервиса.

Для изменения расчёта стоимости заказа полезно разделить обратную связь по рискам:

Риск	Где получать сигнал	Что останется за границей
Ошибка формулы или округления	Модульные проверки граничных сумм и валют	Состояние заказа и взаимодействие с внешними сервисами
Повторное списание или неправильное состояние заказа	Интеграционный сценарий с повтором запроса и контролем состояния	Сбои сети, конкуренция и внешние зависимости, не смоделированные в стенде
Регрессия контракта для клиента	Контрактные проверки известных клиентов и статусов ошибок	Клиенты и версии, отсутствующие в выборке
Нарушение после развёртывания	Наблюдение за реальными операциями и управляемое расширение выпуска	Редкие ветви, которые ещё не встретились на трафике

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

Как проверять изменение при ограниченном выпуске

Даже хорошая тестовая среда отличается от рабочей. Для подходящих сервисов можно выпустить изменение на ограниченную долю нагрузки и сравнить результаты с контрольной частью. Canary-выпуск проверяет новую версию на части нагрузки перед расширением развёртывания. Google SRE описывает такой выпуск как ограниченное по времени частичное развёртывание с оценкой результата.

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

Ускорение подготовки изменений полезнее, когда проверки дают ранний и предметный сигнал, а выпуск позволяет ограничить последствия пропущенного дефекта. Размер набора тестов сам по себе не служит показателем этой способности.

Пять метрик DORA и предел их объясняющей силы

В руководстве DORA показатели поставки разделены на пропускную способность и нестабильность выпусков. Текущая модель DORA содержит пять показателей.

Группа	Показатель	Что измеряется
Пропускная способность	Change lead time	Время от фиксации изменения в системе контроля версий до развёртывания в production
Пропускная способность	Deployment frequency	Частота развёртываний за период
Пропускная способность	Failed deployment recovery time	Время восстановления после развёртывания, потребовавшего немедленного вмешательства
Нестабильность	Change fail rate	Доля развёртываний, после которых потребовалось немедленное вмешательство
Нестабильность	Deployment rework rate	Доля внеплановых развёртываний, вызванных инцидентом в production

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

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

Что показывает опубликованное исследование об AI

В обзоре DORA 2025 сообщается о положительной связи использования AI с пропускной способностью поставки и отрицательной — со стабильностью. В анонсе исследования DORA 2025 года также отмечена положительная связь с результативностью продукта. Авторы сообщают о почти пяти тысячах участников опроса и качественных данных; исследование касается практик и результатов обследованных специалистов и организаций.

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

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

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

Надёжность продукта нужно видеть со стороны пользователя

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

SLI — измеряемый показатель уровня обслуживания, например доля запросов, завершившихся корректно за выбранный период. SLO — заранее согласованная цель для этого показателя. Если ошибка возвращает 200 и проходит в статистику успешных HTTP-запросов, выбранный SLI может пропустить важное нарушение бизнес-инварианта. Поэтому сначала определите событие, которое действительно означает успех для пользователя, и способ его наблюдать.

Google SRE выделяет задержку, трафик, ошибки и насыщение ресурсов как основные сигналы мониторинга. Сами по себе эти сигналы не заменяют продуктовые проверки: корректность цены, права доступа или сохранность данных могут требовать дополнительного наблюдения.

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

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

Так можно принимать решения о темпе выпуска на основе последствий для пользователей. Если значимая операция не выполняет SLO, важно выяснить, какие изменения или условия привели к ухудшению и можно ли безопасно продолжать выпуск. Если SLO соблюдается, это основание обсуждать дополнительный риск, но не разрешение игнорировать критические нарушения, не попавшие в SLI.

Во сколько обходится пропущенный дефект

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

Для решения о проверках полезно разделить последствия на несколько частей:

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

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

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

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

Как проверить гипотезу в собственной команде

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

1. Зафиксируйте словарь событий

Сначала договоритесь, что считается изменением, развёртыванием, внеплановым исправлением и неудачным выпуском. Для DORA фиксируйте именно развёртывания и их последствия. Для очереди ревью используйте отдельные события: создание запроса на проверку, готовность к проверке, её фактическое начало, завершение CI, слияние изменений.

Избегайте смешения временных меток. Дата создания задачи не равна моменту коммита, а слияние изменений не всегда означает развёртывание. Укажите часовой пояс и отношение события к конкретному сервису.

2. Соберите три группы наблюдений

Область	Источник	Что можно увидеть
Проверка изменений	Git, pull request, CI	Время ожидания проверки кода, повторные проверки, длительность проверок, незавершённая очередь
Поставка	Журнал развёртываний и инцидентов	Пять метрик DORA при единых определениях
Работа продукта	Мониторинг, бизнес-события, разборы инцидентов	Пользовательские SLI, длительность и охват сбоев, затраты на восстановление

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

3. Сформулируйте различимые объяснения

Допустим, команда замечает, что задач стало больше, а поставка не ускорилась. Проверяемые объяснения могут быть такими:

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

Эти объяснения могут действовать одновременно. Нужны данные о составе команды, сложности изменений, размере партий, пользовательской нагрузке и изменениях окружения. Иначе последовательность событий легко принять за причинность.

4. Проверьте эффект выбранного улучшения

Определите заранее, чего ожидаете от действия. Например, уменьшение размера изменений может облегчить их проверку, но результат нужно оценить по времени ожидания и количеству возвратов на исправление. Ускорение CI должно уменьшить время получения обратной связи без потери значимых проверок. Изменение стратегии выпуска следует оценивать одновременно по времени поставки, ошибкам после развёртывания и пользовательским SLI.

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

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

Где заканчивается ускорение кодирования

Создание кода — только одна часть поставки программного обеспечения. Улучшение этого этапа ценно, когда изменение быстрее проходит содержательные проверки, добирается до пользователей и сохраняет требуемое поведение сервиса.

Опубликованные материалы DORA и Google SRE позволяют обосновать устройство этого процесса и выбрать показатели для анализа. Эти источники не устанавливают общий исторический тренд надёжности и не доказывают причинную связь между применением AI и неудачными выпусками.

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

Если код стал появляться быстрее, а время поставки или пользовательский SLI не улучшились, результаты диагностики помогут найти следующий этап для изменения.