공급자가 다운될 때
마지막 업데이트:
공급자 상태 페이지는 클라우드, 호스팅, 코드 또는 결제 공급자가 자체 상태를 선언하기 위해 유지하는 공개 대시보드입니다: 전체 지표 하나, 구성 요소 목록, 그리고 인시덴트가 아직 진행 중인 동안 공급자 스스로가 작성하는 인시덴트 타임라인이 있습니다. 그것을 잘 읽는 것은 운영자의 기술입니다. 제목은 요약이고 진실은 그 아래에 있기 때문입니다 — 어떤 구성 요소가 영향을 받았는지, 어떤 지역에서, 선언된 영향이 어느 정도인지, 인시덴트가 공급자 자체 워크플로에서 어디까지 진행되었는지. 이 글은 그 읽는 법을 가르치고, 당신이 의존하는 공급자에게 문제가 생겼을 때 처음 10분에 해야 할 일로 마무리합니다. 공급자 상태 보드에서 시작하세요. 주요 공급자의 페이지를 하나의 스냅샷으로 모았습니다. 그리고 다운된 걸까, 아니면 나만 그런 걸까?라는 질문을 전체 내내 마음에 두세요: 두 도구는 같은 의심의 반대쪽 절반에 답합니다.
두 가지 다른 것: 지표와 인시덴트 상태
성숙한 상태 페이지는 모두 독자가 끊임없이 혼동하는 두 개의 분리된 신호를 담고 있습니다. 첫째는 전체 지표입니다: 서비스 전체에 대한 하나의 요약 상태로, 페이지 뒤의 기계 판독 가능 피드에서는 보통 none, minor, major, critical 또는 maintenance 중 하나입니다 — Statuspage 개발자 문서에 기록된 모델로, 대부분의 대규모 공급자가 직접 사용하거나 밀접하게 모방합니다. 지표는 의도적으로 거칩니다. 바쁜 독자 — 또는 저희 상태 보드와 같은 기계 — 가 “저쪽에 뭔가 문제가 있는가?”에 1초 만에 답할 수 있도록 존재하며, 가장 크게 영향을 받은 구성 요소, 공급자 자체의 판단, 또는 둘 다로부터 계산됩니다.
둘째 신호는 인시덴트 자체이며, 지표가 납작하게 만들어 버리는 자체 수명주기를 가지고 있습니다. 인시덴트는 이름, 선언된 영향, 워크플로에서 가져온 상태와 함께 열립니다: 조사 중(증상은 보이지만 원인은 아직 모름), 확인됨(원인을 알고 작업 중), 모니터링 중(수정이 나갔고 유지되는지 지켜보는 중), 해결됨(끝났다고 믿음, 사후 분석을 전제로). 이 상태들은 지표가 담을 수 없는 정보를 담습니다. 모니터링에 두 시간째 있는 심각한 인시덴트는 보통 끝나 가고 있습니다. 4분 전에 조사에 들어간 minor 인시덴트는 아직 무엇으로든 변할 수 있습니다.
둘 다를, 그 순서로 읽고, 그 사이의 업데이트를 읽으세요. 인시덴트 아래의 짧은 업데이트 타임라인이 바로 공급자가 제목으로는 결코 말하지 않을 것들을 말하는 곳입니다: 어떤 하위 시스템이 실패했는지, 어떤 우회 방법이 있는지, 영향을 받는 것이 데이터인지 가용성뿐인지, 다음 업데이트가 20분 후인지 2시간 후인지. 업데이트가 오지 않게 되는 인시덴트 자체가 하나의 신호입니다 — 팀이 압도당해 더 긴 장애와 상관관계가 있거나, 인시덴트가 조용히 더 큰 것 속으로 접혀 들어갔거나. 제목을 찍고 읽기를 멈추는 운영자는 일상적으로 페이지에서 가장 정보가 적은 문장을 근거로 행동합니다.
“모든 시스템 정상 운영”이 여전히 당신의 다운을 의미할 수 있는 이유
지표는 서비스 전체를 요약하고, 현대의 서비스는 하나의 물건이 아닙니다. 공급자는 전 세계적으로 정직하게 초록색이면서도, 당신이 배포하는 지역, 당신이 호출하는 유일한 제품 표면, 고정된 레거시 API 버전, 또는 배포에 필요한 제어 평면이 그것에 닿는 모든 고객에게 실패하고 있을 수 있습니다. 구성 요소 목록은 바로 이 때문에 존재합니다: GitHub 상태 페이지와 같은 페이지는 서비스를 Git 작업, API 요청, Actions, Pages 등으로 분해하고, 그중 어느 하나라도 전체 배너가 안심시키는 상태로 남아 있는 동안 저하될 수 있으며 — 그 반대도 마찬가지입니다. 한 번도 사용한 적 없는 구성 요소 때문에 배너가 빨간색이 될 수도 있습니다.
더 조용한 간극도 세 가지 있습니다. 첫째, 선언 지연입니다: 공급자는 인시덴트를 확인했을 때 선언하지, 첫 오류가 발생했을 때 선언하지 않으므로, 많은 장애의 처음 몇 분은 초록색 페이지와 불타는 소셜 피드를 보여 줍니다. 페이지는 거짓말을 하는 것이 아니라 그저 뒤처져 있을 뿐입니다. 둘째, 임계값입니다: 공급자는 한 등급의 2퍼센트 오류율을 정상적인 배경으로 취급하고 아무것도 선언하지 않을 수 있지만, 그 2퍼센트는 정확히 당신의 트래픽 패턴에 집중되어 있습니다. 셋째, 범위입니다: 상태 페이지는 전선의 공급자 쪽을 설명합니다. 사용자와 건강한 공급자 사이의 DNS 실패, 라우팅 문제, 차단된 경로는 초록색 지표 아래에서 당신에게 완전한 장애를 만듭니다 — 그래서 동반 질문인 “다운된 걸까, 아니면 나만 그런 걸까”는 공급자 자체 페이지가 아니라 독립적인 관측 지점에서 답해야 합니다.
실무 규칙은 초록색을 “선언된 인시덴트 없음”으로 취급하고, 결코 “건강이 증명됨”으로 취급하지 않는 것입니다. 자체 모니터링이 사용자의 실패를 말하고 공급자가 정상 운영을 말할 때, 사용자에 관해서는 자체 모니터링을 믿고, 상태 페이지는 다른 일에 쓰세요: 나중에 선언이 나타나는지 확인하는 것(그것은 원인을 소급하여 확인합니다), 그리고 당신이 의존하는 구성 요소에 지금 겪고 있는 것과 같은 모양의 인시덴트 이력이 있는지 확인하는 것입니다.
페이지가 아니라 구성 요소를 구독하세요
대부분의 운영자는 상태 페이지를 뉴스레터를 구독하듯 구독합니다: 구독 하나, 모든 인시덴트, 영원히 — 그리고 예상대로 메일을 무시하기 시작합니다. 대규모 공급자의 전역 피드는 사용하지 않는 구성 요소, 서비스하지 않는 지역의 인시덴트를 꾸준히 흘려보내기 때문입니다. 알림 피로는 성격의 결함이 아닙니다. 범위가 잘못 정해진 신호에 대한 올바른 반응입니다. 수정은 기계적이고 거의 모든 성숙한 상태 페이지에서 사용할 수 있습니다: 구성 요소 수준으로 구독하는 것입니다. 지표를 정의하는 바로 그 Statuspage 모델은 구독자가 구성 요소로 필터링할 수도 있게 하며, 자체 시스템을 운영하는 공급자, 예를 들어 Cloudflare 상태 페이지도 자체 구독 흐름을 통해 같은 선택을 제공합니다.
각 구독의 범위를 새벽 3시에 실제로 당신의 행동을 바꿀 것으로 좁히세요. 프로덕션 트래픽이 호출하는 구성 요소는 시끄러운 채널에 속합니다 — 호출하고, 메시지를 보내고, 최소한 몇 분 안에 보게 될 무언가에 배지를 다는 채널입니다. 빌드, 분석, 내부 도구에 만 사용하는 구성 요소는 근무 시간에 검토하는 조용한 채널에 속합니다. 사용하지 않는 구성 요소는 어디에도 속하지 않습니다: 올바르게 무시한 알림 하나하나는 다음 알림을, 중요한 알림을 포함해, 더 쉽게 무시하게 만듭니다. 스택이 바뀔 때마다 목록을 다시 살펴보세요. 구독은 양방향으로 썩기 때문입니다 — 아무도 구독하지 않은 새 의존성과, 아무도 보지 않는 채널을 여전히 호출하는 죽은 의존성입니다.
가능하면 기계 판독 가능 피드를 선호하세요. 이메일은 상태 페이지가 제공하는 가장 느리고 가장 무시하기 쉬운 채널입니다. 웹훅과 피드는 자체 대시보드를 구동하고, 내부 티켓을 열고, 첫 사용자 불만이 도착하기 전에 지원 팀의 준비된 보류 페이지를 뒤집을 수 있습니다. 가벼운 버전도 보상이 있습니다: 저희 공급자 상태 보드의 스냅샷은 바로 이 공개 피드로부터 구축되며, 데이터가 열어야 한다는 것을 기억해야 하는 브라우저 탭에서 감상하기 위해서가 아니라 프로그래밍 방식으로 소비하기 위해 거기에 있다는 증거입니다.
자체 의존성 목록을 구축하세요
목록이 없으면 위의 조언은 어느 것도 작동하지 않으며, 대부분의 팀은 장애 중에 자신들에게 목록이 없다는 것을 발견합니다. 의존성 목록은 사소하게 들리지만 그렇지 않은 질문에 대한 서면 답변일 뿐입니다: 어떤 외부 서비스가 오늘 밤 멈추면 우리를 멈추게 할까 — 그리고 어떤 것이 그저 우리를 부끄럽게만 할까? 날씨가 평온할 때 구축하세요. 아키텍처를 표면별로 걸어 보세요 — 호스팅, DNS, 코드 호스팅과 CI, 데이터베이스와 스토리지 공급자, 결제 처리자, 이메일과 SMS 발송자, ID 공급자, 오류 추적기, 분석 태그, 페이지가 다른 회사의 CDN에서 불러오는 글꼴과 스크립트 — 그리고 각각에 대해 공급자, 실제로 소비하는 구성 요소, 상태 페이지가 어디에 있는지, 실패했을 때 사용자가 무엇을 겪는지를 적으세요.
각 항목은 공급업체를 얼마나 좋아하는지가 아니라 실패의 모양으로 순위를 매기세요. 어떤 의존성은 단단합니다: 멈추면 당신도 멈추고, 할 수 있는 일은 소통과 대기뿐입니다. 어떤 것은 부드럽습니다: 그것들 없이도 사이트는 저하된 채로 돌아갑니다 — 분석 없음, 채팅 위젯 없음, 개인화 없음 — 그리고 그것들에 대해서는 누가 끌 수 있고 어떻게 끄는지를 목록에 적어야 합니다. 그리고 어떤 것은 숨겨져 있습니다: 당신이 선택하지 않은 전이적 의존성으로, 예를 들어 SaaS 데이터베이스 자체가 돌아가는 클라우드 지역의 상태, 또는 모든 것 아래의 인증서와 DNS 인프라입니다. 숨겨진 의존성은 “모든 것이 다운됐는데 우리가 돈을 내는 것은 하나도 목록에 없다”는 장애를 만드는 것들이며, 각 공급업체에 한 번, 그들이 무엇에 의존하는지를 물어봄으로써 찾을 수 있습니다.
목록은 인시덴트가 닿을 수 있는 곳에 보관하세요: 런북 안, 에스컬레이션 목록 옆에 두세요. ID 공급자가 바로 다운된 그 물건일 때 아무도 열 수 없는 위키 페이지가 아닙니다. 한 페이지면 충분합니다. 장애 중 그것의 일은 “뭔가 잘못됐다”를 체크리스트로 바꾸는 것입니다 — 단단한 의존성마다 30초 안에 위인지 아래인지 — 그리고 그 후의 일은 수정되는 것입니다. 실제 인시덴트는 모두 당신이 순위를 잘못 매긴 의존성에 대해 무언가를 가르치기 때문입니다. 결코 수정되지 않는 목록은 운영 문서가 아니라 역사 문서입니다.
공급자 장애의 처음 10분
0분부터 2분: 확인하고 위치를 찾으세요. 자체 모니터링을 확인해 장애가 실제이고 당신이 선언할 것인지 확실히 한 다음, 상태 보드와 의심되는 공급자의 페이지를 여세요. 답하고 있는 질문은 하나입니다: 사용하는 것 — 구성 요소, 지역, 제품 — 과 겹치는 선언된 인시덴트가 있는가? 있다면 원인과 첫 메시지를 얻은 것입니다. 없다면 확인을 넓히세요: 목록의 다른 공급자, 당신 자신의 최근 배포, 당신의 DNS. 대부분의 가짜 드라마는 이 2분 안에 죽고, 대부분의 진짜 드라마는 여기서 모양을 갖춥니다.
2분부터 5분: 솔직하게, 일찍 소통하세요. 사용자가 실제로 읽는 채널에서, 이름이 붙은 업스트림 공급자에게 인시덴트가 있고, 그것이 실질적으로 무엇을 의미하는지 — 무엇이 작동하지 않는지, 무엇이 아직 작동하는지, 데이터가 안전한지 — 그리고 다음에 언제 업데이트할 것인지를 알리세요. 4분째에 보낸 솔직한 보류 메시지는 40분째에 보낸 정확한 설명을 이깁니다. 침묵은 사용자가 최악의 추측과 경쟁사의 이름으로 채우는 것이기 때문입니다. 내부적으로는 인시덴트 스레드를 하나 열고, 발언자를 한 명 지명하고, 모든 것에 타임스탬프를 찍으세요. 사후 분석에서 스스로에게 감사할 것이고, 공급자의 지원 팀도 그들이 필요해질 때 감사할 것입니다.
5분부터 10분: 악화시키는 일을 멈추고 부드러운 착륙을 준비하세요. 배포를 동결하세요 — 진행 중인 업스트림 인시덴트 속에서 이루어진 변경은 평가할 수 없고, 롤백조차 불가능할 수 있습니다. 실패하는 공급자를 두드리는 공격적인 재시도와 필수적이지 않은 작업을 끄세요. 만 개의 클라이언트가 보조를 맞춰 재시도하면 복구는 측정 가능할 만큼 느려지고, 일부 공급자는 당신을 속도 제한으로 몰아 넣어 스스로 만든 두 번째 장애를 일으킵니다. 목록에서 버릴 수 있다고 표시한 부드러운 의존성을 끄거나 저하시키고, 보류 페이지가 있으면 게시하고, 그 다음 인시덴트가 정하는 리듬에 안착하세요: 공급자의 업데이트를 모니터링하고, 뉴스가 있든 없든 약속한 시간에 사용자에게 업데이트하고, 사실이 바뀌지 않는 한 다른 것은 아무것도 바꾸지 마세요. 장애는 공급자의 일정대로 끝나지, 당신의 일정대로 끝나지 않습니다. 당신의 10분은 사용자가 그것을 그들의 공급자의 나쁜 날로 기억할지, 당신의 나쁜 날로 기억할지를 결정합니다.