GitHub의 과거 가동 시간

Hacker News 의견들

• 2018년 이전의 데이터가 실제로 정확한지 궁금했음
  예전에도 여러 번 장애가 있었던 걸로 기억함
  아마도 그 시점부터 현재의 uptime 추적 시스템을 사용하기 시작한 것일 수도 있음

  • 데이터는 공식 status 페이지에서 가져온 것임
    다만 이 페이지는 관측용이라기보다는 마케팅/커뮤니케이션용에 가까웠던 것 같음

• 개인적으로는 이 대체 상태 페이지가 더 낫다고 생각함
  “The Missing GitHub Status Page”라는 이름으로, 최근 90일간의 가용성 비율을 종합적으로 보여줌
  현재는 90.84%로, 며칠 전의 90.00%보다 약간 나아졌음

  • 최근 상황이 꽤 거칠었음
    GitHub Actions의 2026년 2월 가용률이 98%로, 단일 ‘9’ 수준임
    체감상 50번 중 1~2번(약 2%) 정도 실패한 것 같음
  • 이런 종합 수치는 그리 합리적인 지표가 아닌 듯함
    예를 들어 OpenAI가 다운돼서 CoPilot이 작동하지 않을 때, 그걸 GitHub의 다운타임으로 볼 수 있을까 하는 의문이 있음
  • 사실 두 페이지는 같은 통계를 다르게 보여주는 것뿐임
    OP가 Microsoft 인수 이후의 결과를 강조하려는 방식으로 제시한 것 같음
  • “90%면 거의 5주간의 다운타임”이라는 계산이 나옴
    농담이지만, GitHub도 이제 그 정도의 ‘유급 휴가’를 누릴 자격이 생긴 셈임

• 기능이 도입된 시점을 표시하지 않은 채 데이터를 보여주는 건 편향적임
  예를 들어 GitHub Actions는 2019년 8월에 출시됐으니, 그 이전에 다운타임이 없던 건 당연함

  • “Breakdown”에서 “Actions”을 클릭하면 해당 항목을 숨길 수 있음
  • 세부 페이지를 보면 개별 서비스의 규모는 줄어들지만, 전체적인 추세는 동일하게 나타남
  • 더 나쁜 건, 존재하지도 않았던 시기에도 “100% uptime”으로 표시된다는 점임

• 나도 몇 주 전에 Claude로 같은 그래프를 만들어봤음
  Microsoft 인수 전후로 급격한 하락이 있을 거라 예상했지만, 실제로는 오래전부터 불규칙한 장애 패턴이 이어지고 있었음
  인수 전이 더 안정적이었다는 서사는 흥미롭지만, 당시엔 Actions 같은 제품이 없었음
  존재하던 서비스(API, Git ops, Pages 등)는 오히려 관측성 개선으로 설명할 수 있을 듯함

  • Actions 출시 이후 운영과 가용성 측면에서 악몽 같은 상황이 시작된 느낌임
    이후 문제들이 Issues나 PR 같은 안정적이던 영역으로 번졌음
  • 개인적으로는 GitHub Actions 자체가 사라져야 한다고 생각함
    Git은 원래 한 가지 일을 잘하도록 설계된 도구인데, 여기에 불필요한 기능을 덕지덕지 붙인 것이 큰 실수였음

• 사람들이 이유를 찾고 있다면, 이 The New Stack 기사가 설명이 될 수 있음

  • 완전히 동의함. 우리 팀의 Azure 장애와 GitHub 장애는 거의 동시에 발생함
    이제는 일종의 밈처럼 되어버림
  • 다만 6년 넘게 이어진 낮은 가용성을 이 이유 하나로 설명하기는 어렵다고 생각함
    테스트를 별도 환경에서 충분히 하고, 짧은 기간에 Azure로 이전했어야 했음

• 현재 PR 병합 기능이 작동하지 않음
  관련 상태는 GitHub Status Incident 페이지에서 확인 가능함

• 예전에는 유니콘 에러 페이지를 자주 봤던 기억이 있음
  아마 그때는 상태 페이지가 자주 갱신되지 않았던 것 같음

  • 유니콘은 웹 페이지 전용 오류였던 듯함
    Git API 같은 서비스는 별도로 고장 나기도 하고, 상태 페이지에는 시간차를 두고 반영되곤 했음

• 지금은 GitHub의 다운타임 기록이 내 개인 서버보다 더 나쁜 것 같음
  나는 실험하느라 자주 재부팅하거나 서비스를 멈추는데도 말임

  • 그래도 우리는 여전히 돈을 내고 있음
    품질 저하가 있어도 QoS 수준이 유지된다고 믿는 듯함
  • 내 작은 VPS조차 GitHub보다 측정 가능한 수준으로 안정적임

• 나는 GitHub을 옹호하는 사람은 아니지만, 그 그래프는 축이 왜곡되어 있음
  99.5% 이하 구간만 확대되어 있어서 실제보다 훨씬 나쁘게 보임

  • 하지만 0부터 그리면 좋은 서비스와 나쁜 서비스의 차이가 안 보임
    기업용 SLA가 99.9%인데, 그래프의 하단은 그보다 5배 많은 다운타임을 보여줌
    즉, 나쁘게 보이는 게 아니라 실제로 나쁜 것임
  • 그래프에는 부하(load) 요소가 반영되지 않음
    Microsoft 인수 전에는 개인 저장소가 하나로 제한되어 있었던 것도 고려해야 함
  • uptime 차트를 0부터 그릴 필요는 없음
    99%대 범위만 보여주는 게 합리적임
    로그 스케일은 오히려 과하다고 생각함

• GitHub Pages로 웹사이트를 배포하고 있어서, 정적 호스팅 가용성을 따로 조사해봤음
  이 블로그 분석에 따르면 GH Pages는 이 부문에서 꽤 좋은 성적을 보임
  다만 그 공은 Fastly CDN이 가져가야 할 듯함