GitHub Actions 러너 버전 집행 전: brownout을 운영 점검으로 쓰는 법 | Hướng dẫn thực hành
Tech
Lượt xem 2
GitHub는 GitHub Enterprise Cloud의 self-hosted runner 최소 버전 집행에 앞서 8월 24일부터 brownout을 운영한다고 안내했습니다. 일시적인 등록·실행 실패를 단순 장애로 넘기기보다, 자동 업데이트와 복구 경로를 실제로 점검하는 신호로 쓰는 편이 안전합니다.
집행 일정을 체크리스트로 바꿉니다
영향 받는 러너를 먼저 목록화합니다
자동 업데이트가 꺼진 러너와 장기간 고정된 버전을 우선 확인합니다. 등록 가능 여부와 실제 workflow 실행 가능 여부는 같은 조건이 아닐 수 있습니다.
brownout 관찰을 배포와 분리합니다
brownout 시간에 중요한 배포를 겹치지 않게 하고, 대표 workflow를 읽기 전용으로 실행해 로그와 runner 버전을 기록합니다. 실패 원인을 애플리케이션 변경과 섞지 않는 것이 핵심입니다.
복구 기준을 미리 정합니다
업데이트 담당자, 허용할 중단 시간, 재등록이 필요한 경우의 절차를 문서화합니다. 수동 업데이트만으로 끝내지 말고 다음 업데이트가 적용되는지도 확인합니다.
9월 집행일 전에 재검토합니다
GitHub가 안내한 GitHub Enterprise Cloud의 전면 집행일은 9월 25일입니다. 실제 운영 환경의 버전·라벨·네트워크 조건을 다시 확인한 뒤 전환 결정을 내립니다.