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

Осторожнее. Тут часто встречается мнение, что перед праздниками ни-ни. Вы сейчас коллегам всю карму измажете, не простят ;)

Исо 9001?

Сколько по вашим оценкам?

Звучит немного странно ибо не учитывает:
1) отказы в железе
2) отказы в стороннем софте
(под "отказом" понимается и любое нарушение SLA тоже).

Ну, это же тоже часть изменений.

Перегревшийся switch? Тормозящий дольше обещанного AWS?

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

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

Речь о том, что они в большей степени определяют вероятность отказа, чем сами изменения в коде и частота этих изменений, если код достаточно хорош для работы в стабильной среде, но не недостаточно - для нестабильной.

Хм, да вроде нет (или я никогда не видел настолько плохого кода или инфраструктуры)

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

Ну, это как раз про качество кода )
Ну и ошибка в конфигурации - это про архитектуру (ненавижу циски...)

Ошибку могут допустить и тестировщики тоже. Вон даже ракеты после старта взрываются, а там то процессы тестирования уж выстроены. Вопрос, зачем пусть даже маленький риск допускать в праздники, чтобы доказать самим себе что-то? Просто если есть бизнес-необходимость выкатываться, то все выкатываются, даже те, кто не любит или не хочет. А если ее нет, то нафига?

Тогда мне не понятна вот эта фраза " Вероятность отказа зависит не от факта выкладки, а от факта изменения кода".

Вариант 1: код плох, тестов мало, обработки ошибок тоже. Этот код на проде будет ломаться и из без изменений в нем. От кривого ввода, от упавшего невовремя контейнера или кончившегося места под логи.
Вариант 2: код и процесс хорошие. Тогда шанс, что измененеия в нем что-то сломает намного ниже, чем то, что прод сломается из-за внешних причин, обработать которые не было повода.

Мы смотрим риски в зависимости от выкладки. И там важна не частота выкладки, а объем изменений, в эту выкладку вошедших.
Вообще, модель более сложная, конечно (там еще есть "тестирование выкладки", которые чуть уменьшает последствие всех изменений в выкладке, но как это прикинуть в модели - не понятно, нет статистик)

А между вариант1 и вариант2 есть много промежуточных вариантов, когда код скорее ломается от "что-то в нем", чем от "внешних причин"
(ошибка при переключении на standby  - это внутренняя причина )

Что такое "риски в зависимости от выкладки"?
Для бизнеса прод или сломался или нет.

А какая разница, когда допускать риск? И с чего бы это риск падает, почему основной риск от выкладки.
Как правильно говорит @IgorShekalev, скорее уж оно упадет не от выкладки, а от иных причин )

Какая разница для пользователя, почему упало?