요약

  • GitHub는 8월 11일 인시던트qcvjkzcs7j74를 대폭 확대 발표했습니다. 근본적인 Actions 장애는 8월 6일 15:05 UTC부터 8월 7일 00:14 UTC까지 이어졌습니다.
  • GitHub에 따르면 최고점 시점에 워크플로우 실행의 71%가 인프라 장애를 겪었고, 나머지의 75%는 5분 이상 대기했습니다.
  • 루틴 배포가 pod를 교체하면서 기존의 용량 및 동시성 취약점이 드러났고, 잔존 서비스가 포화되어 장애가 여러 클러스터와 의존 시스템으로 전파되었습니다.
  • 엔지니어들은 용량을 추가하고 웹훅 트리거 작업을 스로틀링하며 백로그 처리량을 늘렸으나, 이미 무효가 된 작업을 러너들이 반복적으로 획득하는 현상을 멈춰야 했습니다.
  • 일부 Actions Runner Controller 러너는 수동 복구가 필요했고, 일부 push 및 pull-request 이벤트는 자동 재생(replay)이 불가능했습니다.
  • GitHub는 배포 안전장치 강화, 모니터링, 큐 복원력 및 자동 복구를 발표했지만, 사후 분석(postmortem)만으로는 이러한 통제가 이미 배치되었거나 효과적임을 증명하지 못합니다.

배포가 스스로의 안전 여유분을 소진했습니다

촉발 요인은 특이한 트래픽 급증이 아니었습니다. GitHub에 따르면 루틴 배포가 이벤트를 작업(job)으로 변환하는 내부 Actions 서비스의 pod를 교체했습니다. 용량이 로테이션에서 빠져나가자 잔존 용량이 포화되고, 서비스가 충돌했으며, 영향이 여러 클러스터와 다운스트림 시스템으로 파급되었습니다.

이 과정은 여유 용량이 단순한 효율 버퍼가 아니라 배포 안전성의 일부임을 보여줍니다. 롤링 변경은 잔존 인프라가 실시간 수요와 교체로 생긴 일시적 불균형을 모두 감당할 수 있을 때만 안전합니다.

두 백분율은 서로 다른 모집단을 설명합니다

최고점 수치를 합산하거나 하나의 비율로 뭉뚱그려서는 안 됩니다. GitHub는 실행의 71%에서 인프라 장애가 발생했다고 보고했습니다. 나머지 29% 중 4분의 3은 5분 이상 지연되었습니다. 두 번째 백분율은 전체 워크플로우가 아니라 부분 집합을 설명하며, 나머지가 정상적으로 제때 완료되었다는 뜻이 아닙니다.

그럼에도 이 공개는 이례적으로 유용합니다. 고객이 체감한 표면에 하드 장애와 장기 대기 큐잉이 함께 존재했음을 보여주며, 이 둘은 서로 다른 복구 점검이 필요합니다.

용량 복구만으로 작업 의미가 해소되지 않았습니다

복구의 첫 단계는 용량 추가, 웹훅 수신 축소, 백로그 처리 처리량 확대로 이루어졌습니다. 이후 두 번째 결함이 드러났습니다. 잠재적인 할당 버그가 러너에게 더 이상 유효하지 않은 작업을 제공했고, 러너들은 해당 획득을 반복 재시도하며 정상 작업으로 넘어가지 못했습니다.

이는 큐를 비우는 것과 모든 큐 항목이 여전히 실행 가능한 작업임을 증명하는 것의 차이입니다. GitHub는 누적된 큐가 비워지기 전에 반복적인 무효 획득을 멈추도록 변경 사항을 배포했습니다.

복구가 플랫폼의 자동 범위 밖에 작업을 남겼습니다

완화 조치가 의도치 않게 일부 Actions Runner Controller 러너에 영향을 주면서 해당 러너들은 오프라인 상태로 남았습니다. GitHub는 이 변경을 롤백했으나 일부 러너는 수동 복구가 필요했습니다. 별도로, 일부 push 및 pull-request 트리거는 처리되지 않았고 자동 재생이 불가능했습니다.

따라서 고객 입장에서 이 인시던트는 두 곳에서 끝났습니다. 공급자의 서비스 상태와, 각 리포지토리의 누락되거나 정체된 작업입니다. 팀은 워크플로우를 재실행할지, 트리거 행위를 반복할지, 러너를 복구할지 판단해야 했습니다.

해결이 상세 설명보다 먼저 이루어졌습니다

GitHub는 8월 7일 인시던트를 해결했고, 실질적인 사후 분석은 8월 11일 업데이트를 통해 공개되었습니다. 이 브리핑의 뉴스 이벤트는 후자의 공개이며, 새로운 장애도 영향 구간의 연장도 아닙니다.

이 구분은 인시던트 통계에서 중요합니다. 가용성은 8월 6–7일에, 근본 원인과 통제 공개는 8월 11일에 귀속됩니다. 두 시계를 합치면 서비스 중단 기간은 과대평가되고 공개 지연은 감춰집니다.

약속된 안전장치는 결과가 아니라 테스트 계획입니다

GitHub는 배포·용량 안전장치, 전조 모니터링, 큐잉 작업 복원력, 러너 할당, 파급 억제, 자동 복구를 개선하고 있다고 밝혔습니다. 이러한 약속은 공개된 장애 경로와 밀접하게 대응합니다.

그러나 릴리스, 배포 증거 또는 후속 인시던트가 입증하기 전까지는 미래의 통제에 불과합니다. 가장 강력한 검증은 배포가 유지해야 하는 여유 용량의 기준, 무효 작업의 퇴역 방식, 고립된 러너의 수동 개입 없는 복구 방식을 보여주는 것입니다.

고객에게는 독립적인 대조 기록이 필요합니다

워크플로우 플랫폼이 정상 운영으로 돌아와도 일부 비즈니스 작업은 누락되었거나, 수동 재생으로 중복되었거나, 러너에서 막혀 있을 수 있습니다. 따라서 리포지토리 운영자는 예상 트리거, 워크플로우 실행 식별자, 최종 상태, 배포된 아티팩트에 대한 자체 대장을 관리해야 합니다.

이 대장은 공급자의 사후 분석을 한정된 복구 작업으로 전환합니다. 또한 “GitHub Actions가 지금은 건강하다”와 “인시던트 기간에 실행되었어야 할 모든 변경이 대조를 마쳤다”를 구분해 줍니다.

출처