영향 추정

한 줄 요약

「몇 명이 영향을 받았나」 는 로그를 세는 문제가 아니라 규칙을 정하는 문제입니다. 무엇을 빼고(헬스체크·봇·내부), 무엇을 하나로 묶고(재시도·같은 사람의 여러 세션), 언제를 셀지(시간대가 붙은 구간) 정한 뒤에야 숫자가 하나로 모입니다.

왜 이게 필요했나

사고가 나면 같은 질문에 숫자가 셋 나옵니다. 상태 페이지 팀은 「요청 4천 건 실패」, 고객지원 팀은 「사용자 172명」, SRE 팀은 「80명」 이라고 합니다. 셋 다 같은 로그에서 셌고 셋 다 틀린 계산은 아닌데 규칙이 다릅니다. 공지에는 하나만 나가야 하고, 보상·규제 보고·SLO 계산이 그 숫자를 그대로 씁니다. 너무 크게 쓰면 불필요한 보상과 신뢰 손상이, 너무 작게 쓰면 은폐가 됩니다.

어떻게 동작하나

첫째, 소음을 뺍니다. 쿠버네티스의 헬스체크(/healthz, /readyz)는 장애 중에 오히려 더 많이 실패하고, 검색 엔진 봇과 사내 합성 모니터링도 사용자가 아닙니다. 경로·User-Agent·사내 대역(10.0.0.0/8 같은)으로 가릅니다.

둘째, 재시도를 하나로 묶습니다. 클라이언트는 실패하면 다시 시도합니다. 같은 요청 id 의 줄은 한 요청이고, 사용자가 겪은 결과는 마지막 시도입니다. 첫 시도가 실패하고 재시도가 성공했다면 그 요청은 실패가 아닙니다(느렸을 뿐). 줄을 세면 실패가 부풀고, 「한 번이라도 실패」 로 세면 실패한 사용자가 부풉니다.

셋째, 사람을 셉니다. 실패 요청 수는 사용자 수가 아닙니다. 한 사람이 여러 번 실패합니다. 로그인한 사람은 여러 기기·세션을 열어도 한 명이고, 로그인하지 않은 방문은 세션 하나를 한 명으로 셀 수밖에 없습니다(그래서 이 숫자는 「최소한 이만큼」 에 가깝습니다).

넷째, 구간과 분모를 정합니다. 구간은 시간대가 붙은 시각으로 주고받습니다 — 「14:10부터」 를 UTC 로 읽으면 아홉 시간 다른 구간을 셉니다. 오류율은 같은 규칙의 실패 ÷ 요청이고, 평소 오류율과 나란히 놓아야 의미가 있습니다. 영향받은 사용자도 그 구간의 활동 사용자와 함께 적어야 크기가 보입니다.

마지막으로 규칙을 코드로 남깁니다. 손으로 센 숫자는 다음 사고에 다시 손으로 세야 하고, 사람마다 또 달라집니다.

같은 로그에서 규칙을 하나씩 어기면 숫자가 이렇게 갈라집니다(실습 재료 한 벌에서 센 예).

계산	영향받은 사용자	무엇이 틀렸나
규칙대로	99	—
헬스체크·봇·사내 대역을 남김	118	사용자가 아닌 요청이 섞임
재시도 중 한 번이라도 실패면 실패	172	재시도로 성공한 사람까지 셈
실패 요청 수를 그대로	117	한 사람의 여러 실패를 여러 명으로
구간의 +09:00 을 버림	0	아홉 시간 뒤를 셈

숫자 하나만 보면 어느 것도 이상해 보이지 않는다는 것이 무섭습니다. 그래서 공지에는 숫자와 함께 그 숫자를 낸 규칙(무엇을 뺐고 무엇을 묶었는지)을 한 줄 적어 두는 팀이 많습니다 — 다음 사람이 같은 규칙으로 다시 셀 수 있게요.

현장에서 만나는 모습

세 팀의 숫자가 다를 때 할 일은 누가 맞는지 다투는 것이 아니라 규칙을 한 줄씩 맞대는 것입니다. 상태 페이지 스크립트는 헬스체크를 빼지 않았고, 고객지원 스크립트는 재시도의 첫 실패를 실패로 셌고, 다른 하나는 구간을 UTC 로 읽었습니다 — 이런 차이는 스크립트를 같은 규칙에 맞추면 사라지고, 같은 숫자 하나가 남습니다.

로그인하지 않은 방문은 한계가 있습니다. 같은 사람이 브라우저를 바꾸면 세션이 둘이 되어 두 명으로 세어지고, 반대로 공유 기기는 여러 사람을 한 명으로 셉니다. 그래서 익명 방문이 많은 서비스는 「영향받은 사용자 최소 N명(로그인 기준 M명)」 처럼 둘을 나눠 적습니다. 어느 쪽이든 규칙을 숨기지 않는 것이 핵심입니다.

숫자는 분모와 함께 읽습니다. 「99명」 은 그 구간에 활동한 372명 가운데 99명일 때와 3만 명 가운데 99명일 때 전혀 다른 사고입니다. 오류율도 평소 오류율과 나란히 놓아야 크기가 보입니다 — 평소 0.4% 이던 것이 9% 가 됐다면 스무 배이고, 평소 8% 이던 것이 9% 가 됐다면 사고가 아닐 수도 있습니다. SLO 를 쓰는 팀이라면 이 숫자들이 그대로 에러 버짓 소진량이 됩니다. 같은 규칙으로 센 요청·실패로 버짓을 빼야, 분기 말에 「이번 사고가 버짓의 몇 %를 썼나」 를 다른 사고와 견줄 수 있습니다.

마지막으로, 영향 숫자는 사고 중에 여러 번 바뀝니다. 첫 공지의 숫자는 그 시각까지의 값이고, 사고가 끝난 뒤 포스트모템의 숫자는 전체 구간의 값입니다. 둘이 다른 것은 정상이고, 두 숫자 모두 같은 규칙에서 나왔다는 것만 지키면 됩니다. 그래서 공지마다 「몇 시 기준」 을 함께 적습니다 — 기준 시각이 없는 숫자는 나중에 누가 다시 세어도 맞출 수가 없습니다.

다음 실습에서 할 것

결제 장애의 접근 로그에서 헬스체크·봇·사내 트래픽을 걸러 내고, 재시도를 묶어 요청·실패·오류율을 세고, 영향받은 사용자를 규칙대로 셉니다. 그 규칙을 스크립트로 만들어 처음 보는 로그에도 맞는지 확인받고, 마지막에는 숫자가 서로 다른 세 팀의 스크립트를 고칩니다.