测验：不把「正常」写成数字，那就只是事故

카오스 엔지니어링 원칙이 정상 상태를 정의할 때 권하는 지표는 무엇인가?

• 컨테이너 런타임이 보고하는 재시작 횟수
• 노드의 CPU 사용률과 메모리 사용률
• 시스템 바깥에서 보이는 출력, 예컨대 요청 성공률과 응답 시간
• 애플리케이션 프로세스의 힙 크기와 스레드 수

요청 100건 중 5건이 2초, 95건이 20밀리초였다. 지연을 평균이 아니라 분위수로 적는 이유를 가장 잘 설명한 것은?

• 평균 120밀리초는 멀쩡해 보이지만 p95 는 2초라 느린 꼬리가 그대로 드러난다
• 평균은 표본이 100건 미만일 때 계산할 수 없기 때문이다
• 분위수는 평균보다 계산이 빨라 부하 생성기의 부담이 적다
• 쿠버네티스가 평균 지연을 지표로 내보내지 않기 때문이다

실험 계획서에 '성공률이 0.5 밑으로 내려가면 즉시 되돌린다' 를 미리 적어 두는 이유는?

• 채점 도구가 그 문장을 읽어 자동으로 복구를 실행하기 때문이다
• 실험 도중에는 판단이 흐려지므로 차분할 때 정한 멈출 기준이 필요하다
• 쿠버네티스가 그 값을 읽어 롤아웃을 자동으로 중단하기 때문이다
• 성공률이 0.5 밑으로 내려가는 실험은 설계상 금지되어 있기 때문이다

폭발 반경(blast radius)을 작게 잡는다는 것은 무엇을 뜻하는가?

• 실험을 짧은 시간 안에 끝내 측정 창을 줄인다는 뜻이다
• 고장을 주입하는 대신 시뮬레이션으로 대체한다는 뜻이다
• 가설을 여러 개 세우지 않고 하나만 검증한다는 뜻이다
• 가설을 확인할 만큼만 영향 범위를 열고 그 이상은 열지 않는다는 뜻이다

쿠버네티스에서 Pod 가 Running 이고 Ready 인데도 사용자의 요청이 실패할 수 있는 이유로 알맞은 것은?

• Running 상태의 Pod 는 준비 여부와 무관하게 트래픽을 받지 않기 때문이다
• Ready 컨디션은 kubelet 이 아니라 스케줄러가 정하기 때문이다
• Ready 라는 사실과 Service 의 엔드포인트에 실려 트래픽을 받는다는 사실이 서로 다른 층이기 때문이다
• readinessProbe 는 컨테이너가 아니라 노드의 상태만 확인하기 때문이다

정상 상태를 가용성과 지연 두 축으로 함께 적는 이유는?

• 두 축은 서로 독립이라 한 축만 보면 실험 결과의 절반을 놓치기 때문이다
• 가용성만으로는 표본 수가 모자라 통계적으로 유의하지 않기 때문이다
• 지연이 가용성의 계산에 입력값으로 들어가기 때문이다
• 쿠버네티스의 프로브가 두 값을 한 번에 보고하기 때문이다