상태 페이지를 많이 보게 된 건 서비스 불안정성이 이전보다 눈에 띄게 커졌기 때문이지, 그 반대가 아님. Bear Blog나 Proton Mail은 문제가 없었거나 알아차리지 못해서 상태 페이지를 볼 필요가 없었음.
이제는 빌드 실패, 저장소 접근 불가, 업무 중단의 원인을 알아내려고 GitHub, CircleCI, Microsoft 서비스의 상태 페이지를 반드시 확인해야 함. 가동률은 중요하며, GitHub처럼 인터넷의 핵심 기반일수록 그 이유가 명확해짐. Microsoft가 한동안 GitHub 성능 문제를 축소해 온 만큼, 지난달 장애가 12시간뿐이었다는 수치도 믿기 어려움.
올해 GitHub의 가동률이 90%대까지 내려온 상황에서 ‘100%에 가까운 수치의 비선형적 의미’를 강조하는 데는 신중해야 함. 연간 1%는 약 3.5일임. 담당자들의 어려움에는 공감하지만, GitHub는 동정으로 넘어갈 스타트업이나 약자가 아니며 이런 인프라 운영에는 책임이 따름.

대기업 서비스의 상태 페이지 전용 북마크 폴더까지 만들어 놓고 꽤 자주 확인하는 지경임. 예전에는 이런 필요를 느끼지 못했음.

99% 가동률도 3일 넘는 장애로 생각하면 좋게 들리지 않으니, 오히려 글쓴이의 요지를 잘 보여주는 예시임. Facebook이나 TikTok이 3일 동안 멈춘다고 상상해 보면 됨.
보통은 한 번의 긴 장애가 아니라 여러 짧은 장애의 합이지만, 전달하려는 요지에 따라서는 시간으로 표현하는 쪽이 영향을 더 잘 드러냄.

불과 2주 전에 Proton Mail도 데이터센터 냉각 장애로 대규모 서비스 중단을 겪었음.

지난 1년가량 Microsoft의 품질은 정말 엉망이 됐음. GitHub, Teams, Windows, Azure, Exchange 모두 마찬가지임. GitHub는 몇 달 동안 가동률이 80% 수준이었는데, 지금 98%라고 한다면 수치를 조작하는 것으로 봄. 그 정도로 안정적이지도 않음.
Microsoft 내부에서 무슨 일이 벌어지는 건지 궁금함. GitHub 이슈를 Copilot에 붙여 넣고 코드 검토도 없이 그대로 배포하는 건가?

회사가 방금 클라우드 Outlook으로 전환했는데, Microsoft가 어디에나 AI를 집어넣는 기조를 이어가는 만큼 여러 번 장애가 날 것 같음.

수년간 최악의 가동률도 99.9%인 시스템에서 일해 봤고, 99.999%조차 실패로 보는 시스템에서도 일해 봤음. 현대 기술 업계가 98%면 괜찮다고 여기는 태도는 기존 기술 분야의 기준으로는 통하지 않음.
개별 부품은 늘 고장 났지만, 지난주 정전과 잘못 구성된 전력 분배가 겹쳐 지사에서 발생한 230ms 중단도 아직 조사 중임. 요즘 소프트웨어 개발자들은 이 정도를 장애로 보지 않는데, 전력 분야에서 일하지 않아 다행임.
이번 장애는 가장 낮은 SLA인 99.1%를 보장하는 서비스에만 발생했고, 그 위로 99.95%와 99.999% 등급이 있음. 실제로는 가장 낮은 등급도 해마다 99.999%를 달성하지만, 데이터센터에서 대형 폭탄이 터지는 상황이라면 덜 중요한 설비는 연간 5분을 훨씬 넘게 멈출 수 있어 대비가 필요함.

이건 구식 기술과 신기술의 차이는 아님. 수도 회사도 230ms 중단을 장애로 보지는 않을 것임.
모든 HTTP 요청을 성공시키는 건 대단히 어려워서 재시도를 넣는 것이고, 그러면 230ms 중단은 실질적인 지장을 주지 않게 됨. 그렇다고 형편없는 98%를 옹호하는 건 아님.

어떤 전력 분배 분야에서 일하는지 궁금함. 교외, 농촌, 도심에 모두 살아 봤지만 전력망 가동률 99.999% 는 한 번도 경험하지 못했음. 전력망이나 산업용 전력 분야에서 일하는 건가?

분산 시스템에서는 구성 요소마다, 사용자마다 가용성이 다르므로 가동률을 단일 수치로 나타낸다는 개념 자체가 모호함.
매달 45분 연속 중단되는 것과 짧은 순간마다 요청의 0.1%가 실패하는 것은 크게 다름. 흔히 쓰는 ‘오류율 증가’라는 장애 표현도 의미를 파악하기 어려울 만큼 모호함.
Google의 시간 구간별 사용자 가동률(windowed user-uptime) 은 하나의 숫자로 압축하는 대신 여러 관점의 데이터를 보여줘 이를 개선하려는 접근임. https://www.usenix.org/system/files/nsdi20-paper-hauer.pdf.

빌드와 테스트에 몇 시간 걸리는 CI가 중단되면 중단 시간 자체는 별 의미가 없음. 멈춘 것을 알아차리고 원인을 조사·확인한 뒤 재실행하고 계속 지켜보는 시간까지 전부 손해로 이어짐.

Datadog 같은 대시보드의 수많은 지표와 그래프를 한눈에 읽히는 숫자 하나로 줄이려는 흐름이 있었음. 세부 정보는 사라지지만 비전문가도 이상 여부를 알 수 있게 하는 절충이며, 여기에도 굿하트의 법칙이 적용됨.
복잡한 시스템을 단순한 숫자 하나로 의미 있게 요약할 수는 없음. 결국 전문성이 필요하며, 세부 구현을 완전히 숨기지 못하는 다른 추상화와 마찬가지로 제대로 일하려면 내부를 직접 파고들어 이해해야 함.

‘GitHub Actions: 지난 30일간 12시간 영향, 가동률 98.31%’라는 표현은 악화하는 상황을 최대한 좋게 포장하려는 것임. 장애 중에는 고객이 다른 곳에서 구매하고, 광고가 노출되지 않으며, 잠재 고객의 관심도 식어 실제 매출 손실이 발생함. GitHub의 12시간 중단은 수백만 달러의 개발자 생산성 손실이며, Microsoft가 다른 회사에 떠넘긴 비용임. ‘한 달에 고작 몇 시간’으로 포장해서는 안 됨. 그 시간에는 실제 돈이 걸려 있음.

‘지난 30일간 12시간 영향, 가동률 98.31%’가 왜 포장인지 모르겠음. 지난 30일의 영향을 더 쉽게 파악하게 해주는 표현이라 글의 취지에 동의함.

좋게 포장한다는 해석은 납득하기 어려움. 글의 요지는 월 12시간이라는 표현이 비용을 명확하게 드러낸다는 것이고, 그 취지에 동의함.

GitHub Enterprise에 의존하는 기업이라면 SLA 위반에 대한 보상을 요구할 수 있고 실제로 요구할 것임. 보통 지불한 금액과 연동된 명확한 보상액이 있으며, 그 규모도 작지 않음.
특히 놀라운 건 일반 API와 GitHub EE API가 같다는 점인데, 이는 피해야 할 설계임. 유료 고객이 수와 코드 변경량 모두에서 소수라는 점을 고려하면 더욱 의외임. EE는 살려 두고 무료·Pro 사용자가 장애를 감수하게 할 줄 알았는데, 그조차 아니라면 기업들이 더 안정적인 경쟁사로 떠나는 건 시간문제임.

장애의 길이가 손실 규모와 무관할 수도 있음. 정해진 시각에 반드시 실행해야 하는 1초짜리 작업 하나만 의존하고 있었다면, 그때 발생한 5분 장애와 30일 장애의 손실은 같을 수 있음.
서비스에 따라서는 현실적으로 불가능하더라도 어떤 중단도 용납할 수 없음.

개인적으로는 백분율에 별 관심이 없지만, 어떤 산업에서는 99%와 99.999%의 차이가 수백만 달러에 달하므로 고객에게 그런 형식으로 공개하는 것임.

다만 고객이 높은 가동률을 너무 믿은 나머지 서비스가 멈추면 아무 일도 할 수 없는 업무 절차를 만들게 됨. 적어도 어느 정도 수준을 갖춘 기업이라면 덜 안정적인 제품이 애초에 병목이 되도록 두지 않음.

자체 운영 시스템과 가동률을 비교할 때 놓치기 쉬운 건 장애가 발생하는 시점임. 업무 시간이나 쇼핑 성수기의 중단은 일요일 밤이나 월요일 새벽 3시의 중단보다 훨씬 큰 피해를 줌. 블랙 프라이데이나 크리스마스 직전이라면 더욱 심각함.
AWS, Azure 등의 장애가 한창 업무 중일 때 발생해 수백만 명에게 영향을 주는 모습을 자주 보게 됨. GitHub도 업무를 가로막는다는 점에서 같음. 반면 자체 장비로 운영할 때는 주로 핵심 업무 시간 밖에 중단됐음. 모든 한 시간이 사업에 미치는 영향은 같지 않으므로, 가동률만으로는 제대로 측정하기 어려움.

장애는 대체로 부하가 높은 때 발생하므로, 가장 나쁜 시점에 터진다고 가정해도 크게 틀리지 않음.

상태 페이지에는 다른 문제가 너무 많아서 이 글의 요지에는 별로 관심이 가지 않음. 가동률을 0.09% 더 높이는 일이 0.9% 높이는 것보다 얼마나 어려운지는 사용자로서 중요하지 않음. 필요한 건 현재 서비스 상태와 장기적으로 내게 미치는 영향뿐임. 30일치로는 부족함.
전력 업계에는 IEEE 표준 신뢰성 지표가 있으며, 상태 페이지에서도 이런 지표를 보고 싶음. SAIDI는 고객 한 명이 연간 평균 몇 분간 서비스 중단을 겪었는지를 나타내며 가장 보고 싶은 지표임. 전력망에서는 5분을 넘는 중단을 이 지표의 정전으로 취급함. SAIFI는 고객별 연평균 중단 횟수이고, CAIDI는 중단 발생 시 평균 복구 소요 시간임.
규제 기관이 강제하지 않는 한 이런 분석 결과를 공개하려는 곳은 드물겠지만, 고객 기준의 중단 시간·빈도·복구 시간이 훨씬 유용함. 미국 수치는 https://www.eia.gov/electricity/annual/html/epa_11_03.html에서 볼 수 있음. 미국 밖에 산다면 자국 수치와 비교해 우리를 실컷 비웃어도 됨.
반면 현재 상태 안내는 기술 업계가 대부분의 전력 회사보다 잘하는 편임. 조사와 해결 과정을 더 상세히 알리고, 진행 중인 장애의 복구 시간을 섣불리 구체적으로 예측하지 않는 편임. 전력 업계도 이 부분은 개선되고 있음.

위안을 얻고 싶다면 남아프리카공화국을 보면 됨. ‘순환 정전’이 일상적인 단어가 됐다는 것부터 심각함.
다만 최근에는 개선돼서, 5월 16일 기준으로 순환 정전 없이 1년을 보낸 것이 큰 이정표가 됐음.

가동률은 내 통제 밖의 이유로 업무가 중단될 가능성을 보여주는 유용한 대리지표임. 가동률 99.99% 서비스에서 하루 100번 작업한다면 모두 성공하리라 기대할 만하지만, 99% 서비스에서 하루 1만 번 작업한다면 상당한 오류나 장시간 업무 중단을 예상해야 함.
GitHub에 불만인 건 특정 가동률 수치 때문이 아니라 반복적으로 일을 방해하기 때문임. 98%라는 숫자는 그 사실을 간결하게 표현할 뿐임.

하지만 그 수치 자체가 잘못된 인상을 주는 경우도 많음. 높은 가동률을 강조하기 전에는 업무 시간 밖의 계획된 중단을 전제로 시스템을 만들었음.
거래가 다음 영업일에 완료되곤 한 것도 전체 업무가 야간 일괄 처리에 의존했기 때문임. 업그레이드를 위해 멈출 수는 있어도 다음 날 업무 시작 전에는 처리를 끝내야 했음.
아버지가 그런 일을 하셨는데, 새벽 2시에 부엌 식탁에서 긴급 대응 통화를 하던 모습이 특히 강하게 남아 있음. 업그레이드 때문에 망가진 작업을 5시간 안에 끝내야 하는 상황이었음. 내가 본 건 아마 세 번 정도이고 전체의 절반 이상은 알았을 텐데도, 체감상 매년 두 번씩 있었던 것 같음.

보통은 생각만큼 높은 신뢰성이 필요하지 않다고 조언함. 99.9%, 연간 약 8시간 중단이면 대부분의 용도에 훌륭함.
시스템이 일정한 속도로 돈을 번다면 가능한 수익의 99.9%를 얻는 셈임. 신뢰성을 높이는 데 비용이 2배나 10배 든다면 99%나 90%도 괜찮을 수 있음. 그 돈으로 별개의 시장 기회를 노리는 다른 시스템을 만드는 편이 나을 수 있음.
여러 시스템을 연결해야 하거나, 한 번의 실패 비용이 성공의 가치보다 훨씬 크거나, 블랙 프라이데이·거래량 급증 시점처럼 기회가 가장 큰 때 장애가 몰린다면 낮은 신뢰성이 문제가 됨. 그런 경우가 아니라면 신뢰성 투자에 실제로 가치가 있는지 따져봐야 함.
GitHub는 99%도 괜찮아야 하는 사례라고 봄. 반론은 소프트웨어 엔지니어를 대상으로 하는 불안정한 서비스가 마케팅에 좋지 않다는 것임. GitHub가 Microsoft의 마케팅 수단에 가깝다면 신뢰성도 마케팅 관점에서 결정해야 함. 기업용 구독으로 운영비를 실제로 회수하는지도 궁금함.

현실에서는 수익이 일정한 속도로 발생하는 경우가 드묾. 짧은 장애도 막대한 시간 손실로 번질 수 있으며, 기업이 무엇보다 신뢰성을 중시하는 데는 이유가 있음.
가벼운 장애조차 여러 관리 계층의 문서 작업과 큰 회의를 유발할 수 있음. 사업에 위협인지 평가해야 하기 때문임. 심하면 여기에 중요한 납기까지 놓치게 됨. 잠깐 멈춘 시스템에 작업이 쌓이면 교통 체증처럼 모두가 느려졌다가 동시에 재가속하며 영향이 연쇄적으로 퍼짐.
복원력을 높일 수도 있지만 규정 준수처럼 추가 비용이 듦. 대체 계획은 계속 훈련하지 않으면 쓸모가 없고, 훈련에는 시간과 돈이 필요함. 규모가 커지면 모든 실패에 대비하기는 불가능함. 기업이 정교한 시스템보다 안정적인 시스템을 선호하는 건 직원마다 부담을 더하는 대신 공급업체에 위험 관리를 맡기기 위해서임. 그렇지 않으면 직원이 일 대신 훈련만 하게 됨.

비싼 소프트웨어 엔지니어들이 연간 2.4일을 일하지 못하는 것을 쉽게 받아들일 수 있을지 모르겠음.

가동률 p에 -log10(1-p) 를 적용하면 9의 개수를 수치로 표현할 수 있음. 부동소수점 오차를 제외하면 0.9는 1, 0.99는 2, 0.999는 3이 됨.
중간값도 연속적으로 표현할 수 있어서 0.9321은 약 1.16813, 0.2는 약 0.09691이 됨. 다만 이걸 표준으로 만드는 건 쉽지 않을 것임.

4.5 나인, 약 99.997% 를 목표로 하는 곳에서 일했고, 적어도 0.5 나인 단위로 말하는 건 꽤 일반적이었음. 다만 모두가 그 의미를 이해했는지는 모르겠고, 99.995%를 4.5 나인으로 생각한 사람도 있었을 것임.
2015년 99.9%에서 2025년 4.5 나인까지 높였고, 2026년에는 조금 후퇴할 수도 있음. 재미있는 일이었지만 경영진의 장기적이고 지속적인 관심이 필요한 작업임.