Когда нельзя выпускать изменение в продакшн: признаки рискованного релиза

Как распознать опасный релиз до того, как он обрушит прод — и что с этим делать

Введение: «работает» — не значит «безопасно»

В июле 2024 года CrowdStrike выпустил обновление конфигурационного файла для своего агента Falcon. Файл прошёл сборку. CI не упал. Никаких красных флагов. Через 78 минут 8,5 миллиона Windows-устройств уходили в BSOD. Авиакомпании, банки, больницы, государственные сервисы — всё встало. Финансовые потери только топ-500 американских компаний составили около $5,4 млрд [4].

Причина — не хакерская атака. Причина — обновление, которое не было должным образом протестировано перед глобальным развёртыванием, без поэтапного rollout, без достаточного контроля конфигурации [5].

Этот случай — не исключение, а крайнее проявление системной проблемы. По данным DORA 2024-2025, среднестатистическая команда разработки сталкивается с тем, что значительная часть деплоев требует немедленного исправления или отката [6]. При этом 43,5% команд тратят более недели на прохождение изменения от коммита до продакшна — и это в эпоху, когда AI уже пишет код за минуты [7].

Давление на скорость выпуска растёт. Контроль за выпускаемыми изменениями — нет. Именно здесь и зарождается большинство крупных инцидентов.

Эта статья — практический навигатор для CTO, Tech Lead и AppSec-специалистов: как распознать рискованный релиз до того, как он попал в продакшн, по каким признакам ставить блокер, а когда достаточно предупреждения.

Почему понятие «низкорискового деплоя» — иллюзия

Есть соблазн думать, что небольшое изменение = маленький риск. Это не так.

Microsoft Azure Well-Architected Framework прямо фиксирует: каждый деплой в продакшн несёт риск — будь то обновление кода, инфраструктуры как кода (IaC), feature flag или конфигурации. Не существует изменений с нулевым риском [1]. Разница — в том, насколько риск управляем.

Источником крупнейших инцидентов 2024-2025 годов становились не экзотические zero-day уязвимости, а вполне предсказуемые паттерны: отсутствие дисциплины, пропущенные проверки, неверно оцененные зависимости [8]. Постмортемы снова и снова показывают одно: команды знали о рисках заранее, но не остановились.

Именно поэтому разговор о рискованном релизе — это разговор не столько об инструментах, сколько о критериях остановки.

Уровень 1: Процессные признаки — когда сам процесс сигналит об опасности

Нет плана отката — нет релиза

Если команда не может внятно ответить на вопрос «что мы делаем, если что-то пойдёт не так», релиз нужно остановить.

Rollback — это не просто git revert. Это заранее проверенная процедура, учитывающая схемы базы данных, миграции, состояние очередей, кэши. По данным анализа DevOps-инцидентов 2024-2025, значительная часть команд заявляет, что «у них есть откат» — но мало кто его реально тестировал [8]. Непротестированный откат не существует. Он лишь создаёт иллюзию безопасности.

Особую сложность представляют релизы с изменениями схемы БД. Microsoft рекомендует делать обновления схемы аддитивными — чтобы старые и новые данные могли сосуществовать, пока безопасный откат не будет подтверждён [9]. Если это правило не соблюдено, а миграция уже применена, откат превращается в полноценный incident management.

Практический критерий: перед любым релизом в продакшн должен существовать конкретный задокументированный runbook с шагами отката. Если его нет — это блокер.

Большой пакетный релиз («big-bang»)

Если в одном релизе объединено большое количество изменений — это само по себе признак повышенного риска [10]. Причины просты: тяжелее изолировать причину инцидента, сложнее откатиться к стабильному состоянию, выше вероятность неожиданных взаимодействий между компонентами.

Классический сценарий — «релиз после code freeze». Код замораживается перед праздниками или пиковым периодом, а затем, когда freeze снимается, на продакшн вываливается накопленный бэклог изменений. Это один из самых рискованных паттернов релизного цикла [11]. Команды инженеров из Getir, Pragmatic Engineer и других изданий фиксируют: именно первые дни после code freeze дают наибольшее количество инцидентов [12].

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

Ревью не завершено или формально

Code review — это не галочка. По данным исследований, разработчики принимают предложения AI-ассистентов без изменений примерно в 70% случаев [2]. Дифы AI-сгенерированного кода читают по диагонали. Конфигурационные файлы, CI/CD-скрипты, миграции — читают хуже всего.

Незаконченное ревью перед деплоем — это явный сигнал: кто-то торопится, и торопится за чужой счёт. Особенно опасны ситуации, когда reviewer подписывает изменение, не дочитав, — просто потому что «дедлайн», «CI зелёный» или «надо уже выкатить».

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

Никто не понимает, что именно едет в продакшн

Отдельного внимания заслуживает ситуация, когда состав релиза размыт или неизвестен. Кто из команды может прямо сейчас перечислить все изменения в текущем деплое? Если такого человека нет — это признак того, что релиз превратился в «чёрный ящик».

Уровень 2: Технические признаки — что искать в самом изменении

Новые или изменённые зависимости без проверки

Зависимости — один из самых недооцениваемых источников риска при релизе. В 2025 году OWASP впервые включил «Software Supply Chain Failures» в топ-3 критических рисков безопасности веб-приложений [13]. Treть всех утечек данных, зафиксированных Verizon DBIR в 2025 году, была связана с атаками на сторонних поставщиков программного обеспечения — вдвое больше, чем годом ранее [14].

Конкретные сигналы риска при работе с зависимостями:

1. Зависимость добавлена AI-ассистентом без проверки в реестре пакетов.
2. Версия зависимости не зафиксирована (плавающая), или lock-файл не обновлён согласованно с манифестом.
3. Транзитивная зависимость получила обновление, которое никто не проверял.
4. Пакет новый или малоизвестный, с минимальной историей публикаций.
5. Пакет с похожим на популярный именем (typosquatting).

В августе 2025 года атака S1ngularity скомпрометировала более 2 180 GitHub-аккаунтов через заражённые пакеты системы сборки Nx, внедрив AI-малварь в широко используемые open-source пакеты [15].

Практический критерий: любое изменение в зависимостях требует явной проверки CVE-статуса, источника и истории публикаций. Транзитивные зависимости — тоже.

Секреты, ключи, токены в коде или конфигах

В 2025 году в публичных репозиториях GitHub было обнаружено 28,65 миллиона новых захардкоженных секретов — рост на 34% к предыдущему году, крупнейший однолетний прирост за всю историю наблюдений GitGuardian [16]. AI-репозитории демонстрируют уровень утечки секретов в 6,4% — выше, чем у традиционных проектов [17].

Механика проста: AI пишет код быстро, интегрирует API, генерирует примеры с работающими ключами. Разработчик принимает PR. Никто не смотрел на строку с API_KEY =. Ключ уходит в продакшн — и в git-историю.

82% обнаруженных секретов остаются активными даже после их публичного раскрытия [17]. Отозвать ключ после того, как он попал в продакшн, технически возможно, но требует ручного труда и создаёт окно уязвимости.

Практический критерий: секреты, ключи и токены в коде или конфигурационных файлах — жёсткий блокер релиза. Без исключений.

Конфигурации без ревью

Конфиг — это тоже код. Иногда опаснее кода, потому что читают его реже.

Инцидент CrowdStrike в 2024 году начался с одного конфигурационного файла Channel File 291, содержавшего некорректные данные. Файл не прошёл через правильный QA-процесс. Последствия — 8,5 миллиона упавших систем [4].

Среди наиболее опасных конфигурационных паттернов, которые едут в продакшн незамеченными:

1. Overly permissive CORS — разрешён слишком широкий список источников.
2. Debug-режим включён в production-конфиге.
3. Чрезмерно широкие IAM-роли или ACL.
4. Переменные окружения смешаны между staging и production.
5. Временные флаги или «заглушки», которые забыли убрать.

Практический критерий: конфиги, CI/CD-файлы, IaC-шаблоны и env-переменные должны проходить ревью наравне с кодом.

AI-сгенерированный код — отдельная зона риска

Veracode протестировал более 100 LLM в 2025 году и зафиксировал: AI-сгенерированный код содержит в 2,74 раза больше уязвимостей, чем написанный человеком. Уровень отказов на secure coding benchmarks — 45% [2]. Исследование Apiiro на Fortune 50 предприятиях показало: 322% больше путей для privilege escalation, 153% больше design flaw, 40% рост в exposures секретов [2].

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

Практический критерий: наличие AI в цепочке генерации кода требует усиленного контроля — особенно для модулей аутентификации, авторизации, шифрования, обработки платёжных данных и secrets management.

Непроверенные или отсутствующие тесты для критических путей

Если ключевые пользовательские сценарии не покрыты автотестами, команда деплоит «на удачу». Постмортем реального инцидента из 2026 года фиксирует: рефакторинг endpoint корректно работал в dev-среде, но в production-условиях и при реальных объёмах трафика вызывал падение 35% транзакций — потому что поведение в боевой среде принципиально отличается от staging [19].

Особую опасность представляют:

1. Тесты, которые «зелёные», но не отражают реальный продакшн-трафик.
2. Отсутствие smoke tests после деплоя.
3. Интеграционные тесты против mock-сервисов вместо реальных зависимостей.

Уровень 3: Контекстные признаки — когда и при каких условиях деплоить нельзя

Пятница после обеда и конец рабочего дня

Это не суеверие — это практическая инженерная культура. Неформальное правило «не деплоить в пятницу вечером» зафиксировано у большинства крупных технологических компаний [20]. Причина проста: если что-то пойдёт не так, у команды нет полной ротации для реагирования, дежурство снижено, время на восстановление растёт.

Gergely Orosz в своём анализе практик code freeze фиксирует это как один из немногих действительно universal engineering heuristics: последний merge в пятницу вечером — красный флаг, особенно без уверенности в том, кто дежурит в выходные [20].

Пиковые периоды нагрузки

Новый год, Чёрная пятница, конец квартала, массовые маркетинговые кампании — это периоды, когда цена инцидента максимальна, а возможности для безопасного эксперимента минимальны. Простой во время Black Friday — это $1,25 млн потерь в час по оценкам IDC [21].

Meta применяет формализованные «жёлтые» и «красные» периоды для ограничения деплоев в ноябре-декабре [22]. Инженерные команды розничных платформ массово практикуют deployment freeze на период пиковых продаж. Это не осторожность — это рациональный расчёт соотношения risk/reward.

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

Текущий инцидент или деградация сервиса

Деплоить поверх активного инцидента — значит рисковать смешать симптомы двух разных проблем. Команда теряет «последнее известное хорошее состояние» (last known good state) и начинает работать в условиях неопределённости [9]. Для GitLab это стало формализованным правилом: активные S1/S2 инциденты автоматически блокируют деплои [23].

Практический критерий: при любом активном инциденте или ненормальном поведении системы — новые деплои заморожены до восстановления стабильности.

Oncall не укомплектован

Если команда, способная ответить на инцидент, недоступна — значит, цена ошибки удваивается. Одни из самых тяжёлых инцидентов 2024-2025 годов частично стали такими именно потому, что инциденты происходили в нерабочее время, с неполным составом дежурства или с исчерпанным когнитивным ресурсом инженеров [8].

Практический критерий: деплой без чёткого oncall-покрытия — это повышенный риск. Особенно для критических изменений.

Незавершённые зависимые изменения

Если релиз предполагает одновременное обновление нескольких взаимозависимых компонентов — API, схемы БД, UI, кэша — и хотя бы один из них не готов, деплой создаёт несовместимое промежуточное состояние. Microsoft фиксирует это как один из основных источников сложных инцидентов: когда «связанные изменения задеплоены пачкой, определить, какой компонент вызвал ошибку, становится значительно труднее» [9].

Release gate: как принимать решение быстро и не тонуть в отчётах

Release gate — это не длинный отчёт. Это короткий ответ на конкретный вопрос: «Можно ли безопасно выпустить именно это изменение прямо сейчас?»

Практический decision framework перед деплоем:

1. Известен ли полный состав изменения — код, конфиги, зависимости, миграции?
2. Завершено ли ревью с явным охватом безопасности?
3. Проверены ли новые и изменённые зависимости на CVE и провенанс?
4. Нет ли секретов, токенов или ключей в коде или конфигах?
5. Есть ли задокументированный и проверенный план отката?
6. Доступен ли oncall для реагирования в случае инцидента?
7. Это не пиковый период и не пятница вечером?
8. Нет ли активных инцидентов или аномалий в системе?
9. Прошли ли критические пользовательские пути через smoke/integration tests?
10. Если это AI-сгенерированный код — прошёл ли он усиленное ревью?

Если на три и более вопросов ответ отрицательный — деплой стоит отложить. Это не перфекционизм. Это расчёт вероятности.

Где достаточно предупреждения, а где нужен жёсткий блок

Не все риски одинаковы. Деплоить в пятницу днём с полным oncall-покрытием и зелёными тестами — управляемый риск. Деплоить в пятницу вечером, при текущем инциденте, с новой непроверенной зависимостью и секретом в конфиге — это стопроцентный блокер.

Жёсткий блок оправдан при:

1. Обнаруженных секретах или ключах в коде/конфиге.
2. Критических CVE в новых зависимостях (CVSS ≥ 9.0).
3. Активном инциденте в продакшне.
4. Отсутствии плана отката для изменений с миграцией данных.
5. Непройденных обязательных security checks в CI/CD.

Предупреждение (без жёсткого блока) достаточно при:

1. Деплое в нерабочее время при хорошем oncall-покрытии.
2. Большом PR без явных проблем с безопасностью.
3. Минорных изменениях конфигурации в некритических сервисах.
4. Незначительных изменениях зависимостей без CVE.

Кейс: почему «работает в CI» не защищает от инцидента

В феврале 2026 года команда провела рефакторинг существующего transaction endpoint. Изменение корректно проходило все тесты в dev-окружении. CI зелёный. Ревью принято. Деплой прошёл штатно.

В production при реальном трафике изменённая логика обработки запросов начала давать сбои — потому что production-конфигурация и объём трафика создавали условия, которые не воспроизводились в staging. 35% транзакционных запросов завершались ошибками. Через 12 минут команда откатилась [19].

Что не сработало: тесты не охватывали production-специфичные конфигурации, ревью не включало проверку поведения под нагрузкой, staging не был достаточно близок к реальной среде.

Что нужно было сделать: canary rollout с мониторингом ключевых метрик, smoke tests против production-подобной среды, явная проверка поведения под нагрузкой.

AI-кодинг и релизный риск: новая реальность

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

По данным DORA 2025, AI-инструменты улучшают throughput, но увеличивают delivery instability [24]. Иными словами: больше кода, быстрее — но с бо́льшим количеством проблем, которые нужно ловить перед релизом.

Конкретные зоны риска для команд, активно использующих AI:

1. Package hallucinations: AI может сгенерировать import несуществующего пакета, а злоумышленник может зарегистрировать пакет с таким именем [13].
2. Credential propagation: AI воспроизводит паттерны из обучающих данных, включая небезопасные практики работы с секретами [16].
3. Быстрые PR без глубокого понимания: разработчик принял предложение AI и отправил на ревью, не вникнув в механику изменения.
4. Cascading misconfigurations: один некорректный IaC-шаблон, сгенерированный AI, может размножиться на сотни инстансов при автодеплое [25].

Именно здесь дополнительный слой контроля до merge и релиза становится операционной необходимостью, а не опциональной best practice. Инструменты вроде HighVibe анализируют конкретное изменение — код, конфиги, зависимости, контекст релиза — и дают команде короткий, понятный сигнал: что именно в этом PR блокирует безопасный выпуск. Не длинный отчёт, а ответ на вопрос «можно ли мёрджить прямо сейчас».

Ошибки, которые совершают даже опытные команды

«Тесты зелёные — значит, всё ок»

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

«Это маленькое изменение — быстро выкатим»

Размер изменения не коррелирует линейно с его риском. Одна строка в конфиге может вывести сервис. Один новый импорт может притащить malicious dependency. Маленькое изменение в схеме данных без аддитивной миграции может сломать откат.

«У нас есть rollback»

Это утверждение требует уточнения: когда вы последний раз его тестировали? При наличии миграций данных? В условиях реального продакшн-трафика? Непроверенный план отката — это не план, а надежда [8].

«Выкатим сейчас, поправим потом»

Технический долг, попавший в продакшн, увеличивает change failure rate и MTTR [26]. По данным Daily Work, при высоком уровне технического долга исправление одной проблемы с высокой вероятностью порождает новую. Каждый «выкатим сейчас» добавляет к этому долгу.

«Никто из команды не против»

Отсутствие возражений — не то же самое, что наличие согласия. Постмортемы фиксируют: в инцидентах ML-моделей и сложных систем значительная часть команды видела слабые сигналы риска, но никто не чувствовал себя уполномоченным остановить деплой [27]. Психологическая безопасность в команде — предсказатель надёжности системы: DORA 2024 называет её одним из сильнейших предикторов performance [6].

Тренды: как release gate эволюционирует в 2025-2026

Несколько ключевых изменений в подходах к контролю релизов, которые фиксируют отраслевые данные:

1. Разделение deployment и release. Команды всё активнее разделяют технический деплой (код на сервере, но трафик не идёт) и release (включение для пользователей через feature flags). Это снижает риск: проблема обнаруживается на малом проценте трафика [28].

1. Метрика Rework Rate. DORA 2024 ввёл пятую метрику: deployment rework rate — доля незапланированных деплоев для исправления видимых пользователю проблем. Рост этой метрики — ранний сигнал деградации качества релизного процесса [6].

1. Runtime-aware security. AppSec смещается от статического анализа к runtime-aware подходу: система должна понимать, достижима ли уязвимость в реальном контексте, а не только существует ли она теоретически [29].

1. AI как усилитель, а не решение. DORA 2025 фиксирует: AI-инструменты улучшают то, что уже хорошо работает, и обнажают слабые места там, где процесс fragile [24]. AI не заменяет release gate — он повышает ставки его отсутствия.

1. Supply chain security как системный приоритет. JPMorgan Chase в апреле 2025 года выпустил открытое письмо, призывающее индустрию относиться к supply chain риску как к системному, а не нишевому AppSec-вопросу [14].

Чек-лист: 10 вопросов перед любым деплоем в продакшн

Используйте как минимально необходимый release gate:

1. Состав релиза известен полностью — код, конфиги, зависимости, миграции?
2. Ревью завершено и охватывает безопасность?
3. Новые и обновлённые зависимости проверены на CVE и провенанс?
4. В коде, конфигах и истории коммитов нет секретов и ключей?
5. Есть задокументированный и протестированный план отката?
6. Oncall доступен и знает о предстоящем деплое?
7. Нет активных инцидентов или аномалий в системе?
8. Деплой не приходится на пиковый период или конец рабочей недели?
9. Критические пользовательские пути прошли smoke/integration tests?
10. AI-сгенерированный код прошёл усиленное ревью, особенно в зонах auth, crypto, secrets?

Три и более «нет» — деплой откладывается.

Заключение: остановиться — это тоже решение

Самое контринтуитивное в культуре быстрой разработки: иногда правильное решение — не выпускать.

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

DORA, постмортемы CrowdStrike, инциденты с supply chain атаками — все они указывают на один и тот же паттерн: проблема была видна заранее. Сигналы были. Просто никто не остановился.

Что делать дальше:

1. Формализовать release gate как часть процесса — не как опциональный чек, а как обязательный шаг перед деплоем.
2. Включить проверку зависимостей, конфигов и секретов в CI/CD — автоматически, не вручную.
3. Тестировать откат — регулярно, а не только в момент инцидента.
4. Выстраивать психологическую безопасность: любой член команды должен иметь право остановить деплой при наличии обоснованного сигнала.
5. Разделять deployment и release — это даёт пространство для безопасного эксперимента без риска для всей аудитории.

AI ускоряет разработку. Контроль изменений должен расти с той же скоростью.

Источники

[1] Microsoft — "Architecture strategies for safe deployment practices" — https://learn.microsoft.com/en-us/azure/well-architected/operational-excellence/safe-deployments

[2] SoftwareSeni — "AI-Generated Code Security Risks - Why Vulnerabilities Increase 2.74x" — https://www.softwareseni.com/ai-generated-code-security-risks-why-vulnerabilities-increase-2-74x-and-how-to-prevent-them/

[3] Axify — "Complete Guide to Change Failure Rate [2026 Edition]" — https://axify.io/blog/change-failure-rate-explained

[4] Messageware — "What Caused the Crowdstrike Outage: A Detailed Breakdown" — https://www.messageware.com/what-caused-the-crowdstrike-outage-a-detailed-breakdown/

[5] Cloud Security Alliance — "What We Can Learn from the 2024 CrowdStrike Outage" — https://cloudsecurityalliance.org/blog/2025/07/03/what-we-can-learn-from-the-2024-crowdstrike-outage

[6] Octopus Deploy — "Understanding The 4 DORA Metrics And Top Findings From 2024/25 DORA Report" — https://octopus.com/devops/metrics/dora-metrics/

[7] RDEL Substack — "What are the 2025 benchmarks for the key DORA metrics?" — https://rdel.substack.com/p/rdel-115-what-are-the-2025-benchmarks

[8] Medium / Humaun Kabir — "DevOps Outages in 2024–2025 Proved One Thing: Tools Don't Fail, Discipline Does" — https://medium.com/@humaunk/devops-outages-in-2024-2025-proved-one-thing-tools-dont-fail-discipline-does-3ab0020512fc

[9] Microsoft — "Develop an Incident Management Practice to Recover from Disruptions" — https://learn.microsoft.com/en-us/azure/well-architected/design-guides/incident-management

[10] DZone — "The Risks Of Big-Bang Deployments And Techniques For Step-wise Deployment" — https://dzone.com/articles/risks-big-bang-deployments-and

[11] Medium / Melissa Davis — "Ready, Set, Deploy! Preventing Post Code Freeze Production Incidents" — https://medium.com/@melissadavis98110/ready-set-deploy-preventing-post-code-freeze-production-incidents-1adb001de751

[12] Medium / Getir — "Risk Management During Code Freeze for Mobile Release" — https://medium.com/getir/risk-management-during-code-freeze-1d464d0562c0

[13] Secure Code Warrior — "OWASP Top 10 2025: Software Supply Chain Failures" — https://www.securecodewarrior.com/article/owasp-top-10-2025-software-supply-chain-failures

[14] ReversingLabs — "Software Supply Chain Security Report 2026: A guidance timeline" — https://www.reversinglabs.com/blog/sscs-report-2026-guidance-timeline

[15] TechDemocracy — "Top 5 Software Supply Chain Attacks in 2025" — https://www.techdemocracy.com/resources/top-5-software-supply-chain-attacks-in-2025-266

[16] Docker Blog — "AI Coding Agent Horror Stories: Security Risks Explained" — https://www.docker.com/blog/ai-coding-agent-horror-stories-security-risks/

[17] SQ Magazine — "AI Coding Security Vulnerability Statistics 2026" — https://sqmagazine.co.uk/ai-coding-security-vulnerability-statistics/

[18] Help Net Security — "29 million leaked secrets in 2025: Why AI agents credentials are out of control" — https://www.helpnetsecurity.com/2026/04/14/gitguardian-ai-agents-credentials-leak/

[19] Medium / Benedict Odoh — "Post-Mortems in Software Development" — https://benedictodoh.medium.com/post-mortems-in-software-development-3717fbe96b32

[20] Pragmatic Engineer / Gergely Orosz — "Code Freezes: Part 3" — https://newsletter.pragmaticengineer.com/p/code-freezes-part-3

[21] SRE School — "Comprehensive Tutorial on Deployment Freeze in Site Reliability Engineering" — https://sreschool.com/blog/comprehensive-tutorial-on-deployment-freeze-in-site-reliability-engineering/

[22] Pragmatic Engineer / Gergely Orosz — "Code Deployment Freezes: Part 1" — https://newsletter.pragmaticengineer.com/p/code-freezes

[23] GitLab — "Create new label for blocking deployments and feature-flags" — https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/15414

[24] Future Processing — "DORA metrics in the age of AI-driven delivery" — https://www.future-processing.com/blog/dora-devops-metrics/

[25] The Hacker News — "AI's Hidden Security Debt" — https://thehackernews.com/expert-insights/2025/08/ais-hidden-security-debt.html

[26] Daily Work — "What Are the Different Types of Technical Debt? When to Tackle It" — https://www.software.com/devops-guides/technical-debt

[27] Medium — "The 12 ML Postmortem Questions Teams Dodge" — https://medium.com/@1nick1patel1/the-12-ml-postmortem-questions-teams-dodge-55091fcb394b

[28] CircleCI — "Deploying vs releasing: What you should know to prevent outages" — https://circleci.com/blog/deploying-vs-releasing/

[29] Orca Security — "2026 AppSec Trends: Development Velocity & AI Risk" — https://orca.security/resources/blog/2026-application-security-trends-report-analysis/