Quiz: Evidence for denominators and error budgets

성공 2건·503 실패 2건을 보냈는데 성공률이 100%입니다. 가장 먼저 대조할 증거는?

• 알림 임계값을 더 높은 수치로 바꾼 결과
• 요청 응답 기록과 실패가 포함된 분모 카운터
• 노드 개수를 두 배 늘린 뒤의 CPU 평균
• 기록 규칙 이름에 ratio가 포함되어 있는지

201 응답이 1100ms 걸렸습니다. 이번 과제의 available과 fast는?

• 둘 다 참: 성공 상태이므로 지연은 무관
• 둘 다 거짓: 느리면 가용성에서도 실패
• available은 참, fast는 거짓
• available은 거짓, fast는 참

같은 attempt_id와 같은 내용이 두 번 수집됐고, 다른 ID의 재시도도 있습니다. 올바른 집계는?

• 세 기록을 모두 성공 한 건으로 합친다
• 동일 ID도 실제 재시도처럼 각각 센다
• 재시도는 마지막 결과만 분모에 남긴다
• 같은 사건은 한 번, 다른 ID의 시도는 별도로 센다

유효 시도 100회, 목표 99.9%, 실패 1회입니다. 허용 실패량과 소비 비율은?

• 0.1건과 10배
• 0건과 계산 불가
• 1건과 1배
• 10건과 0.1배

수집된 요청은 모두 성공했지만 covered=False입니다. 이번 정책에서 해야 할 일은?

• 성공률 1로 채워 ship을 반환한다
• 숫자를 null로 두고 investigate를 반환한다
• 실패 0건이므로 잔여 예산을 최대로 표시한다
• 분모를 1로 보정한 뒤 freeze 여부를 계산한다

가용성 예산은 남았지만 지연 예산이 고갈됐습니다. 이번 과제의 일반 기능 변경 판단은?

• 가용성만 사용하므로 ship
• 두 성공률 평균을 낸 뒤 ship
• 한 목표가 고갈됐으므로 freeze
• 항상 investigate로 바꿔 숫자를 버림

요청 ID를 지표 레이블로 넣으면 어떤 문제가 생길 수 있나요?

• 모든 요청이 같은 시계열로 합쳐져 실패가 사라진다
• 카운터가 자동으로 게이지로 변환된다
• 상태 코드가 더 이상 수집되지 않는다
• 요청마다 고유 시계열이 늘어 저장·조회 부담이 커진다

자신의 반례가 올바른 구현과 다섯 오류 구현을 모두 실패시킵니다. 좋은 시험인가요?

• 아니요. 올바른 구현은 통과하고 잘못된 구현을 구별해야 한다
• 예. 실패 수가 많을수록 결함 검출력이 높다
• 예. 정상 입력은 별도 테스트할 필요가 없다
• 아니요. 반례는 실패 결과를 만들면 안 된다