가동률 99.9%와 99.99%는 10배 차이인데 왜 똑같아 보일까, 상태 페이지 표기 비판

퍼센트 자체는 나도 신경 안 씀. 근데 업계에 따라 two nines랑 five nines 차이가 수백만 달러라서 고객한테 그렇게 공개하는 거임.

요점이 뭔지 모르겠음. 다들 n-nines 표기를 쓰자는 건가? 근데 회사들이 자기 더 나빠 보이는 짓을 할 이유가 없지. 그리고 이 글 AI가 쓴 것 같은 느낌 안 드나?

아님. Jim은 글 잘 쓰는 사람이고 원래 AI에 꽤 회의적이었음.

서비스가 50% 업타임이어도 내가 필요할 때만 살아 있으면 됨. 다운타임의 의미는 사용자마다 다르고, nines는 내부 인프라 평가용이지 고객 임팩트는 알려주지 않음.

맞음. 정기 점검 다운타임은 전혀 문제될 게 없음. 사용 패턴을 잘 아는 서비스에는 오히려 좋음.

업타임 통계나 올려주면 안 됨? 나는 콜로케이션 서버 두 대를 며칠 전에 정리했음. FreeBSD 6년이었고 1931일 업타임이었는데.

커널 라이브 패칭이 보편화되지 않아서 서버 한 대 업타임 극대화는 보안상 나쁜 습관을 부추김.

"12 hours affected"는 상황이 나빠지는데 가장 좋게 보이려는 시도임. 다운타임은 실제 매출 손실이고, GitHub 12시간 다운은 수백만 달러 규모의 개발자 생산성 손실을 마이크로소프트가 다른 회사에 떠넘긴 것임.

왜 그게 미화인지 모르겠음. 지난 30일 임팩트를 보기 쉽게 만든 것뿐이고 나는 글에 동의함.

GitHub Enterprise 쓰는 회사는 SLA가 있고 실제로 GitHub에 청구할 수 있음. 근데 글로벌 API랑 EE API가 같다는 게 말이 안 됨.

고객 입장에서는 5분 장애든 30일 장애든 똑같은 돈을 잃을 수 있음. 서비스에 따라 어떤 다운타임도 용납 안 되는 경우가 있음.

이런 건 로그 스케일 다운타임 그래프가 답임.

30일 중 12시간은 문제를 미화하는 것 같음. 퍼센트는 그대로 두고 GitHub는 업타임을 고쳐야 함.

서비스들이 서로 얽히면서 다운타임 측정 자체가 제대로 안 되는 것 같음. 어떤 건 상세하게 재지만 자기 플랫폼 위아래 제공자 다운타임을 다 합쳐서 요약하지는 않음.

계약서의 이런 지표는 헛소리인 경우가 많음. 6 nines 요구사항을 받았는데 3~6개월 기간에 7.5초 수준이고 계약은 $1.5M였음. 이게 상식적인 기대인가?

실시간 트레이딩에서 일했는데 전혀 터무니없지 않음. 합의한 거면 불이행 비용을 청구하는 게 맞고 나는 기꺼이 더 냄.

계약이니까 협상하면 됨. 비현실적인 걸 알면서 동의했으면 공짜로 서비스 주기로 한 거임.

비례 배분이 아니었는지 확인해봐야 함. 비례면 보통 문제 없고, 청구할 가치가 있을 만큼 큰 장애면 환불액은 우스울 정도로 작음.

애플리케이션이 뭔지 모르니 6 nines가 적절할 수도 있음. 911 라우팅용 PSIP 조회면 합리적이고 종이 우편물 발송이면 아님.

업타임 숫자의 임무는 좋아 보이는 것임. 맥락을 더한다고 더 좋아 보이지 않고, 일반인이 차이를 모르는 건 회사 입장에서는 기능임.

클라우드로 옮겨가면서 "up"의 의미도 중요해짐. 서버가 살아 있다고 플랫폼이 기능하는 건 아님. 우리가 쓰는 벤더의 특정 기능이 자주 안 되는데 나머지가 멀쩡해도 소용없음.