행동으로 연결되는 경보

경보의 도착점을 정합니다

경보가 울렸는데 담당자가 무엇을 해야 할지 모르면 숫자를 전달한 것에 그칩니다. 안내판 조회 실패는 사용자가 목록을 읽지 못하는 문제입니다. 이번 레슨에서는 실패가 지속될 때 조사와 m07 복구 절차로 이어지는 안내를 생성합니다. 이메일이나 메신저 전송·자동 롤백은 하지 않습니다. 출력의 PAGE는 사람이 즉시 조사할 필요가 있다는 교육 상태입니다. 경보에는 대상 서비스·관측 창·조건·영향·담당·첫 행동·해제 확인을 연결해야 합니다. 밤중에 받은 사람도 어떤 증거를 열지 알 수 있어야 합니다.

교육 규칙을 명시합니다

입력은 시간순 1분 창의 minute·total·bad입니다. total이 20 이상이고 실패율이 10% 이상인 창이 마지막 세 개 연속일 때 PAGE를 반환합니다. 단발 오류 뒤 정상으로 돌아오면 OK입니다. 20건·10%·3개는 교육 정책이며 실제 서비스 권장 임계값이 아닙니다. 99%·28일 SLO 계산과도 같은 기간이 아닙니다. SLO 위험을 더 직접적으로 감지하려면 소비 속도와 여러 관측 창 등을 설계해야 합니다. 이 과제는 지속 조건·입력 품질·행동 연결을 작게 구현하는 데 범위를 둡니다.

비율 경계는 곱셈으로 검사합니다

bad를 total로 나누어 표시한 퍼센트를 비교할 필요 없이 bad 곱하기 10이 total 이상인지 검사하면 10% 경계를 정확하게 판정할 수 있습니다. total=20, bad=2이면 경계에 포함됩니다. bad=1이면 경계 아래입니다. 분모가 0일 때 나누지 않는 효과도 있지만 단순히 곱셈 조건만 검사하면 0 이상 0이라 true가 됩니다. 따라서 total이 20 이상이라는 최소 건수 조건과 함께 검사합니다. 경보 조건의 각 부분은 목적이 다르므로 하나를 삭제하여 테스트를 맞추지 않습니다.

연속 상태를 작은 변수로 만듭니다

run은 현재까지 이어진 높은 오류 창 수입니다. 높은 창이면 1을 더하고 그렇지 않으면 0으로 초기화합니다. 자료의 전체 최고 연속 길이가 아니라 마지막 구간의 지속 여부를 반환합니다. 앞에서 세 번 실패해도 마지막에 정상 창이 들어오면 이 함수는 OK입니다. 이는 현재 판정이고 실제 알림 시스템의 장애 상태 저장·중복 억제·해제 통지까지 구현한 것은 아닙니다. 사람이 복구를 선언하려면 일정한 관측 기간과 사용자 흐름 재검사 결과를 별도로 확인합니다.

시간 누락을 정상으로 채우지 않습니다

minute은 정수 창 번호이고 뒤 창은 앞 창보다 정확히 1 커야 합니다. 0 다음 2라면 1번 창이 누락된 자료입니다. 순서가 바뀌거나 같은 번호가 반복돼도 ValueError가 됩니다. 프로그램이 정렬하여 중복을 숨기거나 누락 창을 성공으로 만들어 넣지 않습니다. 실제 집계기는 수집 지연과 창 확정 정책을 정한 뒤 완성한 자료를 경보 평가기에 줘야 합니다. 오류 문구 windows must be consecutive and ordered는 서비스 실패율이 아니라 집계 시간축이 계약을 어긴 문제를 가리킵니다.

미측정은 회복을 뜻하지 않습니다

마지막 창 total=0이면 NO_DATA와 관측 원천 점검 안내를 돌려줍니다. 로그 수집이 끊긴 것인지 사용자가 없었던 것인지 확인합니다. 중간 빈 창은 연속 조건을 끊으므로 그 뒤 두 실패 창만으로 PAGE를 내지 않습니다. 빈 배열의 OK는 경보 조건을 만족한 창이 없다는 뜻일 뿐 서비스 정상 인증이 아닙니다. 자료가 없는 상태로 복구 선언을 자동 작성하면 사용자 실패를 놓칠 수 있습니다. 관측 장애에 대한 별도 경보를 추가하는 것은 이 정책의 자연스러운 후속 작업입니다.

저트래픽의 한계를 남깁니다

19건 중 2건 실패는 실패율이 10%를 넘지만 최소 요청 수 때문에 이 규칙의 PAGE 대상이 아닙니다. 그래서 OK를 피해가 없다는 표현으로 읽지 않습니다. 적은 사용자에게도 실패는 실제 영향이 될 수 있습니다. 저트래픽 서비스에는 더 긴 창이나 합성 요청·신고 등 추가 근거를 검토해야 합니다. 교육에서는 최소 요청 수 경계를 테스트하여 자신의 규칙이 놓치는 상황을 드러냅니다. 임계값을 바꿀 때는 잡음 감소뿐 아니라 탐지 지연과 놓친 영향 사례도 함께 검토합니다.

증거를 열고 소유권을 확인합니다

PAGE의 action은 m07 절차에 따라 자기 프로젝트 소유권을 확인하고 관측 증거를 읽은 뒤 이전 검증 릴리스로 되돌리고 /notices를 재검사하라고 안내합니다. 먼저 후보 버전과 이전 버전의 CI 검증 자료·이미지·설정이 맞는지 확인합니다. 경보는 롤백이 항상 최선이라고 증명하지 않습니다. 데이터 형식 변경이나 외부 의존성 문제라면 이전 버전도 실패할 수 있습니다. 담당자는 변경 시각·로그·클라이언트 요청·복구 제약을 보고 적용 여부와 결과를 사건 기록에 남깁니다.

단발 fixture와 지속 fixture를 비교합니다

starter는 run이 1 이상이면 PAGE를 내어 단발 오류에도 사람을 호출합니다. test_spike가 기대한 OK와 실제 PAGE 차이를 알려 줍니다. 지속 fixture에서만 호출하려고 단순히 항상 OK를 반환하면 test_sustained_boundary와 test_action이 실패합니다. 회복 fixture·경계 바로 아래·저트래픽·분모 0 검사도 읽습니다. 해결은 테스트를 지우는 것이 아니라 조건을 계약에 맞게 고치는 일입니다. assertion의 문자열 차이를 먼저 읽으면 환경 오류인지 경보 정책 오류인지 구별할 수 있습니다.

명령 실패를 해석합니다

bash check.sh는 실행 위치를 자신의 루트로 옮기고 Python 버전을 확인한 뒤 unittest를 실행합니다. FAIL Python 3 required는 실행 도구가 없다는 뜻이며 정책 변경으로 해결되지 않습니다. ModuleNotFoundError가 나면 압축을 온전히 풀었는지 alert.py와 test_alert.py가 같은 디렉터리에 있는지 확인합니다. window schema는 문자열·불리언·빠진 필드 또는 계약 밖 필드가 있다는 뜻입니다. window counts는 bad가 음수이거나 total보다 크다는 뜻입니다. 입력 값을 조용히 보정하지 말고 자료 생산 단계를 조사합니다.

m08 자료와 경보 창은 다릅니다

m08 windows.json의 before·healthy·error·slow는 주입 조건별 비교 구간입니다. 구간 길이와 요청 개수가 경보 입력의 1분·최소 20건 계약과 다르고 연속 시간 자료라는 보장도 없습니다. error 다음 slow가 있다는 이유로 연속 실패라고 세지 않습니다. 미션은 이 자료로 SLI 보고서를 만들고 경보 함수의 지속 동작은 별도 고정 fixture로 검사합니다. 실제 경보를 붙일 때는 사용자 요청을 동일 길이 시간 창으로 집계하는 단계부터 필요합니다. 아직 없는 관측 자료를 만들어 실행했다고 말하지 않습니다.

경보 문구를 검토합니다

통과한 테스트 외에 사람에게 전달될 안내가 이해 가능한지 읽습니다. 이전 릴리스의 범위를 찾는 법과 복구 후 사용자 요청 검사 위치가 있어야 합니다. 민감 토큰과 사용자 식별값을 경보 본문에 복사하지 않습니다. 조건이 해제되어 OK가 나와도 한 표본만으로 사건을 종료하지 않고 담당자가 관측 회복을 확인합니다. 경보 평가·통지·복구 실행·사건 종료를 각각 기록하면 재발 시 어디가 느렸는지 볼 수 있습니다. 텍스트 자료를 집계하는 awk 문법은 더 읽기로 보내고 여기서는 시간 상태와 행동 계약을 완성합니다.