Разработчики с первых дней усваивают: нет ничего срочнее, чем починить продакшен-аварию. Бросай всё, вся команда поднимается по тревоге. Но когда ломаются инструменты разработки, сборочные системы, QA-окружение и другие части пайплайна, такой же срочности часто не придают. А зря — для команды разработки пайплайн и есть продакшен.
Когда код не собирается, разработчики не могут делать свою работу, софт не выходит. Это и есть продакшен-авария. Упал QA-сервер — тестировщики не могут проверять фичи, работающий софт не поставляется. Для QA-команды это такой же инцидент на проде. Чинить его надо немедленно.
В промышленности существуют выверенные процедуры, как предотвращать и минимизировать простои сборочной линии. Похожие процессы есть и для ИТ-аварий, но обычно они заточены на сбои, которые видят внешние клиенты, а не те, кто создаёт и поддерживает сервисы.
Разумнее смотреть на всю цепочку от «клиент хочет что-то» до «это что-то доставлено клиенту». В неё входят: системы тикетов и запросов на изменения вроде GitHub Issues и Jira; инструменты, которыми разработчики непосредственно пишут софт, — IDE, сборочные утилиты (Gradle, Maven), репозитории пакетов (npm, Maven Central, внутренние репозитории), локальные базы данных, контейнеры; CI/CD-инструменты (Jenkins, GitHub Actions). Если падает набор тестов, вы ведь не покатите изменения на прод? Если лёг QA-сервер, вы ведь не отдадите фичу без проверки? Любой шаг, который мешает вносить правки и деплоить их на прод, — это сломанный пайплайн. Команда с неработающим пайплайном не может выпускать софт и обязана реагировать на поломку как на пожар в продакшене.