IL-0273 GitHub · 2016-01-28database
주 데이터센터의 전원이 잠깐 끊긴 뒤 Redis 클러스터가 돌아오지 않아 GitHub 가 2시간 6분 동안 HTTP 503 을 냈다
2016년 1월 28일 00:23am UTC 에 GitHub 주 데이터센터의 전원 공급 시스템이 잠깐 끊겨 전체 서버의 25% 를 조금 넘는 서버와 여러 네트워크 장비가 재부팅됐다. 로드 밸런서와 프런트엔드 서버 다수는 멀쩡했지만 이들이 의존하는 시스템에 닿을 수 없어 애플리케이션이 HTTP 503 을 냈다. 여러 ChatOps 시스템이 재부팅된 서버에 있어 초반 대응이 늦어졌고, 상태 페이지는 8분 뒤에야 빨간색이 됐다. Redis 연결 예외와 연결 시도 증가 때문에 처음에는 네트워크 장애와 DDoS 를 의심했다.
조사해 보니 꺼진 서버는 모두 같은 하드웨어 종류였고, 전원이 다시 들어온 뒤 자기 드라이브를 인식하지 못해 부팅하지 못했다. 이것은 알려진 펌웨어 문제였다. 이 서버들이 여러 랙과 랙 열에 흩어져 있어 여러 Redis 클러스터가 멤버 전부를 잃었다. 애플리케이션 코드에는 부팅할 때 Redis 클러스터가 반드시 있어야 하는 의존성이 모르는 사이에 들어가 있었다. 그래서 Redis 가 꺼지자 애플리케이션 프로세스가 시작하지 못했다.
한쪽 엔지니어들은 현장 기술자와 함께 flea power 를 빼 완전히 꺼진 상태에서 서버를 다시 켜 디스크가 보이게 했다. 다른 쪽 엔지니어들은 영향받은 Redis 클러스터를 다른 하드웨어에 다시 만들었다. 중요한 내부 시스템 여럿이 꺼진 하드웨어에 있어 새 서버를 준비하기가 어려웠고, 그래서 이 작업이 더뎠다. 대기 장비에 Redis 데이터를 복원해 Redis 서버 프로세스를 다시 올리자 애플리케이션 프로세스가 회복됐고, HAProxy 로드 밸런서가 정상 응답하는 서버를 백엔드 풀에 되돌렸다. 사이트 동작을 확인한 뒤 점검 페이지를 내리고 상태를 노란색으로 바꿨다. 첫 장애에서 2시간 6분 뒤였다. 데이터 손실은 없었다.
- 심각도
- –
- 영향 범위
- GitHub was unavailable and returned HTTP 503 responses for two hours and six minutes
- 영향 사용자
- all GitHub users
- 지역
- –
- 감지까지
- –
- 복구까지
- 2h 6m
증상
2016년 1월 28일 00:23am UTC 에 여러 온콜 엔지니어에게 알림이 갔고, GitHub 가 HTTP 503 응답과 함께 유니콘 그림이 있는 오류 페이지를 내기 시작했다. 로드 밸런서와 프런트엔드 애플리케이션 서버 다수는 멀쩡했지만, 그 서버들이 요청을 처리하는 데 의존하는 시스템들에 닿을 수 없었다.
처음 온 알림은 서버에 닿을 수 없다는 것과 Redis 연결 관련 예외가 치솟는다는 것이었다. 연결 시도도 늘어 네트워크 문제처럼 보였다. 팀은 내부 네트워크 장애를 의심했고, DDoS 공격일 수 있다고 보고 DDoS 방어를 올리고 네트워크 상태를 살피는 데 초반 시간을 썼다. 나중에 DDoS 는 원인이 아닌 것으로 드러났다.
여러 ChatOps 시스템이 재부팅된 서버에 있어 대응 초반에 혼란과 지연이 있었다. status.github.com 은 사이트에 접속할 수 없게 된 지 8분 뒤인 00:32am UTC 에야 빨간색으로 바뀌었다.
여러 Redis 클러스터의 모든 멤버에 닿을 수 없어서 데이터센터 장비의 가동 시간을 살폈다. 일부 서버는 가동 시간이 몇 분이었지만 네트워크 장비는 재부팅되지 않은 상태였다. 꺼진 서버는 모두 같은 하드웨어 종류였고, 문제없이 재부팅된 서버는 다른 하드웨어 종류였다. 이 서버들은 여러 랙과 랙 열에 흩어져 있어서, 멤버를 여러 랙에 나눠 둔 클러스터도 멤버 전부가 재부팅됐다.
시간이 지나도 애플리케이션 프로세스가 예상대로 뜨지 않았다. 애플리케이션 서버의 프로세스 목록과 로그를 보니 Redis 클러스터가 꺼져 있어서 프로세스가 시작하지 못하고 있었다. 꺼진 하드웨어의 원격 콘솔 화면에는 물리 드라이브를 더 이상 인식하지 못해 부팅이 실패한 것이 보였다.
증상 서비스 중단
원인
원인 의존성 장애
- 촉발
- 2016년 1월 28일 00:23am UTC 에 주 데이터센터에서 서버와 장비에 전원을 대는 시스템이 잠깐 끊겼고, 전체 서버의 25% 를 조금 넘는 서버와 여러 네트워크 장비가 재부팅됐다.
감지
서버에 닿을 수 없다는 알림과 Redis 연결 예외 급증 알림이 여러 온콜 엔지니어에게 갔다.
조치
- 현장 기술자와 함께 flea power 를 빼 완전히 꺼진 상태에서 서버를 다시 켜, 디스크가 다시 보이게 했다.
- 영향받은 Redis 클러스터를 다른 하드웨어에 다시 만들기 시작했다.
- Redis 클러스터 데이터를 대기 장비에 복원하고 Redis 서버 프로세스를 다시 올렸다.
- 사이트 동작을 확인한 뒤 점검 페이지를 내리고 상태를 노란색으로 바꿨다.
후속 조치
- 전원이 다시 들어온 뒤 서버가 자기 드라이브를 보지 못하게 한 알려진 펌웨어 문제를 전체 서버에서 업데이트한다.
- 새 펌웨어 업데이트가 나오면 도구가 팀에 이슈를 자동으로 열어, 변경 내역을 GitHub 환경과 대조해 검토하게 한다.
- 애플리케이션 테스트에서 일부 외부 시스템이 없어도 애플리케이션 프로세스가 시작하는지 명시적으로 확인한다.
- 백엔드 서비스가 꺼졌을 때 기능을 단계적으로 줄일 수 있도록 서킷 브레이커를 개선한다.
- 새 서버 준비처럼 중요한 운영 작업을 맡는 내부 시스템의 가용성 요건을 사용자용 시스템과 같은 수준으로 다시 검토한다.
- 팀 사이의 소통을 강화한다.
- 모든 인원이 대응에 나서야 하는 상황의 에스컬레이션 방식을 미리 정해, 사고 조정자가 문서를 찾는 대신 복구를 관리하는 데 시간을 쓰게 한다.
- 장애 동안 사용자에게 보내는 안내를 개선해, 무슨 일이 일어나는지와 다음 안내가 언제 올지 알 수 있게 한다.
교훈
복잡한 시스템은 구성 요소마다 의존을 이해해도 그 의존을 엄격하게 시험하지 않으면 새로운 방식으로 실패할 수 있다. 인프라의 큰 부분이 전원을 잃는 일을 완전히 막을 수는 없지만, 복구를 빠르고 믿을 만하게 하고 사용자 피해를 줄일 수는 있다. 예상하지 못한 장애에서 복구하는 데 필요한 내부 시스템은 복구 대상 시스템만큼 믿을 만해야 한다.
출처
관련 사례
IL-0133폭풍으로 데이터센터 냉각이 멈춰 us-central1 리전 전체가 내려갔고, 디스크 핫플러그 버그로 Managed Kubernetes 컨트롤 플레인 약 140개의 복구가 길어졌다.Nebius · 2026같은 원인 · 공통 데이터센터 전력·냉각
IL-0408API 키 조회 캐시가 비워진 채 돌아와 OpenRouter API 가 두 번에 걸쳐 500 과 401 "User not found" 오류를 냈다OpenRouter · 2026같은 원인 · 공통 인메모리 캐시
IL-0134AUS01 데이터센터에 전력 문제가 생겨 GPU 노드 246대와 스파인 스위치, VAST 스토리지가 한꺼번에 재부팅됐고, 워크로드가 실패하고 NFS 마운트가 끊겼다.Lambda · 2026 · sev1같은 원인 · 공통 데이터센터 전력·냉각
IL-0135UPS 를 바이패스 모드로 둔 정기 점검 중 전원이 예비 전원으로 넘어가면서 데이터센터 한 열이 정전됐고, 그 열의 GPU VM 이 모두 꺼졌다.Crusoe Cloud · 2023같은 원인 · 공통 데이터센터 전력·냉각
같은 원인 · 공통 인메모리 캐시
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0273
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0273/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.