▲

GitHub의 과거 가동 시간

 (damrnelson.github.io)
1P by GN⁺ 18시간전 | ★ favorite | 댓글 1개
  • 2016년부터 2026년까지의 GitHub 월별 가동 시간을 시각화한 페이지
    • 모든 데이터는 공식 상태 페이지에서 수집된 기록 기반
  • 평균 가동률(Average) 과 세부 중단 내역(Breakdown) 을 구분해 볼 수 있는 구조
  • 페이지 내에서 원본 데이터 소스(View source) 로 직접 접근 가능
  • 장기적인 서비스 안정성 추이를 한눈에 확인할 수 있는 시각화 자료
  • 별도의 분석이나 해설 없이 데이터 시각화 중심으로 구성된 형태
▲
GN⁺ 18시간전  [-]
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이 가져가야 할 듯함

답변달기