퀴즈: 분모와 오류 예산의 증거

문항 8개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

   1. 0.1건과 10배
   2. 0건과 계산 불가
   3. 1건과 1배
   4. 10건과 0.1배

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

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

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

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

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

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

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

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