이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- 실패한 pipeline을 재실행하기 전에 무엇을 분류해야 하는가?
- test 실패, artifact 실패, 권한 실패, 배포 후 검증 실패는 어떻게 다르게 대응하는가?
- pipeline 실패가 운영 장애와 연결될 때 어떤 정보를 공유해야 하는가?
개요
Pipeline 실패 대응의 핵심은 rerun 버튼을 누르는 속도가 아니다.
어느 단계가 실패했는지, 같은 입력으로 실패했는지, 운영에 반영되었는지, 증거가 남아 있는지를 먼저 확인해야 한다.
실패한 pipeline을 무작정 재실행하면 flaky test, 권한 오류, registry 장애, 배포 후 장애를 숨길 수 있다.
백엔드 개발자는 실패 로그를 보고 코드 문제와 운영 변경 문제를 분리해야 한다.
실패 분류
Pipeline 실패는 최소한 다음으로 나눈다.
- checkout 또는 dependency download 실패
- compile/build 실패
- unit/integration test 실패
- package 또는 artifact upload 실패
- image build 또는 registry push 실패
- deploy 권한 또는 environment approval 실패
- 배포 명령 실패
- 배포 후 smoke test 실패
각 실패는 담당자와 위험도가 다르다.
테스트 실패는 코드 변경자에게 돌아가지만, registry push 권한 실패는 배포 권한 설정 문제일 수 있다.
Smoke test 실패는 이미 운영 변경이 일부 반영되었을 수 있어 더 신중하게 다뤄야 한다.
재실행 전 확인
gh run list --limit 10
gh run view <run-id> --log-failed
gh run view <run-id> --json headSha,event,status,conclusion,createdAt재실행 전에는 run id, commit SHA, event, failed job, failed step을 기록한다.
이전 성공 run과 실패 run의 차이를 본다.
dependency repository 장애처럼 외부 원인이면 동일 commit 재실행이 의미 있을 수 있다.
테스트나 코드 문제라면 재실행보다 수정이 먼저다.
Test 실패 대응
Test 실패는 실패한 test 이름, stacktrace, 최근 변경 파일을 본다.
Spring context load 실패는 configuration, profile, bean condition, test property 누락을 의심한다.
DB integration test 실패는 migration, test data, transaction boundary, time zone 차이를 본다.
Flaky test는 rerun으로 숨기지 말고 quarantine이나 원인 이슈를 남긴다.
Flaky가 운영 장애를 직접 만들지 않더라도 pipeline 신뢰도를 떨어뜨린다.
Artifact와 Registry 실패
Package 실패는 build output과 artifact path를 확인한다.
Artifact upload 실패는 경로, 파일 크기, retention, permission을 본다.
Image push 실패는 registry auth, package write 권한, tag immutability, network 장애를 본다.
이 단계는 코드 테스트가 이미 성공했을 수 있으므로 코드 품질 문제와 구분해야 한다.
Deploy와 Smoke Test 실패
Deploy command 실패는 target environment에 변경이 반영되었는지부터 본다.
일부 instance만 새 버전이 되었을 수 있다.
Smoke test 실패는 배포 후 사용자 영향 가능성을 뜻한다.
새 배포를 계속 밀기 전에 traffic, health, error rate, rollback target을 확인한다.
DB migration이 포함된 배포라면 이전 버전과 호환되는지 먼저 본다.
운영 체크리스트
- 실패 run id, commit SHA, failed job, failed step을 기록했는가?
- 재실행 전에 실패 원인을 분류했는가?
- 같은 commit을 rerun하는지 새 commit으로 다시 실행하는지 구분했는가?
- 운영 환경에 일부라도 반영되었는지 확인했는가?
- 실패 로그에 Secret이 노출되지 않았는가?
- smoke test 실패 시 rollback target이 준비되어 있는가?
- 실패 원인이 문서나 pipeline 개선으로 이어졌는가?
장애 신호
- rerun하면 가끔 통과한다는 이유로 실패 원인을 남기지 않는다.
- deploy job은 실패했는데 운영 일부 instance는 새 버전이다.
- smoke test 실패 후에도 pipeline이 성공으로 표시된다.
- 실패 로그에 token 일부가 출력된다.
- registry push 실패를 해결하려고 같은 tag를 여러 번 덮어쓴다.
- DB migration 후 rollback이 실패한다.
안전한 완화 조치
운영 반영 전 실패라면 artifact와 권한 문제를 해결한 뒤 같은 commit으로 재시도한다.
운영 반영 후 실패라면 먼저 사용자 영향과 rollback 가능성을 확인한다.
Smoke test 실패는 새 배포를 계속 밀기보다 현재 상태를 고정하고 증거를 수집한다.
Secret 노출이 포함된 실패는 pipeline 재실행보다 Secret 회전이 먼저다.
Tag 충돌이 있으면 같은 tag를 덮어쓰기보다 새 tag와 digest 기준으로 정리한다.
인프라 담당자와 공유할 자료
문제: production deploy pipeline 실패
run id: 431
commit: abc1234
failed job/step: deploy-prod / smoke-test
배포 반영: image abc1234가 2/4 instance에 반영됨
증상: /actuator/health DOWN, DB migration V42 완료
rollback target: image ff9012, V42 backward compatible 확인 필요
즉시 요청: traffic 중단 또는 이전 image로 rollback 판단실패 pipeline 공유에는 운영 반영 여부와 rollback 가능성을 반드시 넣는다.
실전 팁
- rerun은 조치가 아니라 실험이다. 실험 조건을 기록한다.
- failed step을 보고 담당자를 나눈다.
- 같은 tag를 덮어쓰지 않는다.
- smoke test 실패는 운영 장애 후보로 다룬다.
- 실패 원인이 반복되면 pipeline 자체를 고친다.
위험 신호!
- 실패 원인을 보지 않고 rerun부터 누른다.
- 운영 일부 반영 여부를 확인하지 않는다.
- 실패한 deploy 위에 새 deploy를 계속 쌓는다.
- Secret이 찍힌 로그를 공유한다.
- DB migration 포함 배포를 rollback 가능성 없이 재시도한다.
확인 질문
확인 질문
- 실패한 pipeline을 재실행하기 전에 확인할 세 가지는 무엇인가?
- 실패 run의 commit SHA, failed job/step, 운영 환경 반영 여부를 먼저 확인해야 한다.
- smoke test 실패가 단순 pipeline 실패보다 위험한 이유는 무엇인가?
- 배포가 이미 일부 반영된 뒤 실제 endpoint 검증에서 실패한 것이므로 사용자 영향이 있을 수 있기 때문이다.
- flaky test를 rerun으로만 처리하면 왜 안 되는가?
- pipeline 신뢰도가 낮아지고 실제 회귀와 환경 문제를 구분하지 못해 결함이 main에 들어갈 수 있기 때문이다.