▲

GitHub 장애 없이 지난 일수

 (dayswithoutgithubincident.com)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • Days Without GitHub Incidents는 GitHub incident 없이 지난 일수를 표시하는 페이지임
  • 현재 일수 영역은 ... days 로만 표시되어 구체적인 일수는 확인되지 않음
  • High Score는 2026년으로 표시됨
  • 페이지에서 확인 가능한 핵심 수치는 현재 일수와 High Score임
  • 현재 일수는 숫자가 아니라 자리표시자 형태로 나타남

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 최근 모든 프로젝트를 자체 호스팅 Forgejo 인스턴스로 옮겼고, 지금까지 꽤 만족스럽다. 속도도 빠름
    GitHub 대안을 찾고 있다면 한번 살펴볼 만하고, 선택지는 있음

    • 이제 유행은 아니지만, 자체 호스팅 가능한 GitHub 대안으로 Phabricator도 명예롭게 언급할 만함
      오히려 “낡은” UI가 요즘 다른 것들이 워낙 나빠진 상황에서는 장점처럼 느껴짐
    • GitHub에는 늘 거부감이 있었지만, git은 처음 접한 직후부터 인상적이었음
      개인 프로젝트를 오래된 Gitea 인스턴스에서 Forgejo로 옮겼고 매우 만족하고 있음
    • Gitea는 어떤가?

  • 플랫폼 전체를 숫자 하나로 합치는 건 공정하지 않다고 봄. AWS 전체를 숫자 하나로 더하는 것과 비슷함

    • 반대로 어느 정도 복잡한 배포를 운영하면 CPU, 메모리, 입출력, 애플리케이션 지표, 가입자, 활성 사용자/세션 같은 대시보드에 쉽게 파묻힘
      그래서 전체 시스템 상태를 단일 숫자로 표현하는 방법을 생각해보는 건 유용함. 예를 들어 활성 사용자 세션을 데이터베이스 연결 수로 나누고 메모리 용량으로 보정할 수 있음
      한 자리 숫자라면 정상 범위에 익숙해지고 눈에 잘 띄는 곳에 항상 둘 수 있음. 세부 사항은 못 보여주지만, 값이 변하면 구체 지표를 보러 가면 되니 기본적인 “정상인가?” 확인용 축약으로는 잘 작동할 수 있음
    • 상태 페이지를 지금처럼 쪼개서, git push와 git pull 장애를 따로 추적한다고 해도 과장이 조금 섞인 농담에 그칠 정도라면, 그건 눈속임이자 SLA 부풀리기에 가깝고 봐줘서는 안 됨
      거의 모두가 쓰는 Git, 이슈, 풀 리퀘스트, Actions 같은 핵심 영역이 있고, 그중 하나라도 깨지면 사이트가 깨진 것임. 상태 페이지는 이런 일이 얼마나 자주 생기는지 보여줘야 함
    • 이건 명백히 밈 사이트고, 숫자가 높지 않을수록 밈이 더 웃김
      실제로 정확한 정보를 찾는 사람은 공식 상태 페이지로 갈 것임
    • S3, EC2, EKS, RDB만 놓고도 지금 GitHub 전체와 비슷한 가동률이었다면 모두가 알았을 것임
      저장소 위키, 커밋 통계, gist에 이런 문제가 생기는 건 그다지 중요하지 않음. 중요한 건 PR, Actions, Discussions처럼 함께 쓰이고 서로 의존하는 서비스들의 조합임
      두 시스템의 각 구성요소마다 단일 백분율을 만들어도 GitHub가 여전히 밀릴 것임. 장애 없는 날이 며칠 더 있을 수는 있어도, 이건 단순 비교가 아님
    • 사용자 관점에서는 이런 계산이 말이 됨. 하지만 MSFT나 GitHub 입장에서는 이 숫자가 꽤 민망한 지표임
      플랫폼의 모든 기능을 사용하게 만들고 강한 종속성을 만들고 싶을 텐데, 일부가 계속 고장 난다면 사용자가 더 많은 기능을 채택할 자신감을 얻기 어렵다
      쓰는 것이 많아질수록 그중 하나가 문제를 일으킬 확률은 커지지만, 이런 회사들에게는 이제 안정성이 목표가 아닌 것처럼 보임

  • 우리에게는 실제 사업 연속성 문제임. GitHub Enterprise에 어느 정도 묶여 있지만, 이런 상태가 계속되면 클라우드에서 온프레미스로 옮겨야 할 수도 있음

    • 그 방향으로 간다면 필요한 Actions를 모두 로컬에 캐시해두는 게 좋음. 그렇지 않으면 크게 나아지지 않음

  • 지금 tangled.org에서 쓰려고 자체 호스팅 Knot을 설정 중임
    주된 이유는 AtProto가 멋지고 자체 호스팅이 재미있어서지만, 내 프로젝트를 호스팅하는 인프라를 직접 소유하는 방향으로 가고 싶기 때문이기도 함
    Tangled의 Knot 시스템은 이 점에서 강한 추상화처럼 느껴짐. 데이터는 AtProto Repository에 호스팅하되, 이를 세상에 보여주는 AtProto Application의 호스팅과 관리는 제3자에게 맡길 수 있음
    Tangled가 사라져도 AtProto 로그인을 다른 플랫폼으로 가져가 내 Knot을 가리키면 되고, 호스팅 설정은 그대로 유지 가능함. 인터넷 한구석에 고립된 웹앱 전체를 직접 호스팅하는 것보다 훨씬 편리함

  • 여기에는 GitHub를 변호하는 말이 많음. 수십억 달러짜리 회사를 변호하는 것도 좀 이상한데, 특히 오픈소스 소프트웨어의 압도적 다수를 맡고 있는 회사라면 더 그렇다
    호의가 작동하는 걸 수도 있음. 하지만 사랑하는 프로젝트에 참여하려면 큰 회사의 내부 정치와 관행을 받아들여야 한다는 점은 늘 삼키기 어려운 알약이었음. GitHub에 빚졌다는 느낌은 없음
    특히 그들이 거래의 자기 몫을 지키지 못한다면 더 그렇다. Azure 크레딧 한가득이라는 거액을 대가로 전 세계 소프트웨어 저장소에 자유롭게 접근하는 셈임

    • 질문을 반대로 해보면, 운영을 유지하려 애쓰는 동료 인간들이 최소한의 친절과 존중조차 받을 자격이 없다고 볼 만큼 GitHub에 반대하는 이유가 무엇인가?
      사업체와 그 뒤에서 열심히 일하는 사람들을 분리해서 볼 수 없는가?
      그들도 우리 같은 사람들이 자신들에게 의존한다는 걸 모르는 게 아님. 자신들의 서비스가 전 세계 소프트웨어 개발 역량의 “발신음”이라는 걸 알고 있고, 영향도 예민하게 인식하고 있음
      #hugops는 어디로 갔나? 그 사람들이 마음에 안 드는 회사에서 일한다는 이유로 바로 사라지는 건가?
    • 정확히는 Microsoft라는 수조 달러짜리 회사를 변호하는 것임
    • 돈을 내고 쓰는지에 달렸다고 봄. 돈을 낸다면 강한 기대를 갖고 책임을 물어야 함
      무료 서비스를 받는다면 화가 나는 것도 합리적이지만, 동시에 지불한 만큼 받는 셈이기도 함
    • 인수 이후에도 GitHub에 대한 인식이 별로 바뀌지 않은 것이 놀라움
      WSL과 맞물리면서 많은 사람들에게 균형이 맞춰졌고, Microsoft를 다시 “일단 믿어보자” 쪽에 올려놓은 듯했음
      이번 일은 운영 비용뿐 아니라 그동안의 호의를 많이 되돌리고 있음. 갑자기 나쁜 보도가 더 잘 보이고 무시하기 어려워짐
    • 수십억 달러짜리 회사를 목숨 걸고 변호하는 두 집단은 HN 사용자와 Nintendo 팬임

  • GitHub의 커밋이 전년 대비 14배 늘었다고 함

    • AI 에이전트들이 스팸처럼 밀어 넣는 건가?
    • 커밋인가, 푸시인가? 부하 측정 관점에서 커밋 수는 그다지 의미 있는 기준이 아님
    • 14배는 미친 수준임. 특히 현실 세계 소프트웨어의 품질과 양은 거의 움직이지 않았는데 더 그렇다
      새로 얻은 에이전트식 코딩 능력으로 실제 가치를 만들고 품질을 개선하길 바랄 수도 있었음. 하지만 보이는 건 엔시티피케이션과 정체임. 이 모든 토큰으로 대체 뭘 하고 있는 건가?
    • GitHub의 커밋이 전년 대비 14배 늘었다고 해서, 그래서 뭐?
      Microsoft가 확장하지 못하면 누가 할 수 있나? 서비스를 제공할 수 없다면 가능해질 때까지 판매를 멈춰야 함
      이건 90년대 중반 AOL 전화접속 통화중 신호 fiasco의 반복임. 다만 이번에는 사람들이 화를 내는 대신, 불쌍하고 시달리는 조 단위 회사에 변명을 해주고 있음
    • 이게 AI 커밋 때문이고 전부 트래픽 양 탓이라는 말을 정말 이해하기 어렵다
      한 자릿수 규모의 증가, 즉 14배 정도의 부하 증가가 이런 수준의 장애로 이어져서는 안 됨
      GitHub가 하는 일과 그 처리량을 소셜 미디어 회사, 결제 회사, 동영상 플랫폼 등과 비교하면 단순한 부하 문제라는 설명은 맞지 않아 보임
      이미 기본적인 문제가 있던 플랫폼에 증가한 부하가 겹쳐 증폭된 것에 훨씬 가까워 보임

  • 이 농담이 먹히는 이유는 모두가 편의성을 위해 상당한 집중 리스크를 조용히 받아들였기 때문임

  • https://repo.autonoma.ca/treetrek
    내가 만든 무료 오픈소스, 최소 기능, 캐시 없음, 의존성 없음, 인증·인가 없음의 순수 PHP 원시 Git 뷰어임
    GitList가 캐시 버그 때문에 공유 호스팅의 디스크 공간과 메모리를 터뜨렸고, GitHub·BitBucket·GitLab 저장소를 통합하려고 만들었음
    자체 호스팅을 하고 제3자의 변덕에 휘둘리지 않는 데는 보람이 있음

  • 대부분 바이브 코딩 앱일 이 앱도 GitHub를 내려가게 만드는 바이브 코딩 앱 공세에 기여했을 가능성이 큼
    침몰하는 배를 어떻게든 띄우려는 GitHub 직원들이 안쓰럽고, Microsoft는 자기 배를 가라앉히기 위해 할 수 있는 모든 일을 하는 것처럼 보임

답변달기