Что делать при поломке ключевой части пайплайна без известной причины

Что проверяют

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

Как отвечать

Разложите ответ на два такта.

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

Второй такт, сужение. Вопрос один: что изменилось между зелёным и красным прогоном.

• код: дифф между двумя коммитами, git bisect, если прогонов накопилось много;
• зависимости: установка через npm install вместо npm ci подтягивает новые версии, и красным становится прогон, в котором ваш код не менялся вовсе;
• окружение: версия Node на раннере, кэш, забитый диск, протухший токен реестра, лимит внешнего сервиса.

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

Где спотыкаются

Начинают с «посмотрю логи и поправлю». Пока сборка красная, деплой стоит у всей команды, и первым действием должен быть откат, а не расследование.

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

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