Quiz: Measuring and Operating a Platform

DORA 네 지표를 속도와 안정성으로 나눌 때 안정성 쪽에 속하는 것은?

• 배포 빈도와 변경 리드 타임
• 변경 실패율과 서비스 복구 시간
• 배포 빈도와 변경 실패율
• 변경 리드 타임과 서비스 복구 시간

DORA 지표를 플랫폼의 성공 지표로 그대로 쓰면 안 되는 이유로 가장 적절한 것은?

• 배포를 잘게 쪼개거나 실패 정의를 좁히면 조작이 가능하고, 플랫폼의 기여를 분리해 보여 주지 못하기 때문에
• DORA 는 쿠버네티스 환경에서 측정할 수 없기 때문에
• DORA 는 이미 폐기된 프레임워크이기 때문에
• 지표가 네 개뿐이라 통계적으로 유효하지 않기 때문에

플랫폼의 핵심 약속을 가장 직접적으로 재는 지표는?

• 새 팀·새 서비스가 아무것도 없는 상태에서 프로덕션 배포에 도달하기까지 걸린 시간
• 플랫폼 팀이 만들어 둔 템플릿과 차트의 개수
• 클러스터 노드 수
• 플랫폼 팀의 배포 빈도

인지 부하 설문을 활용하는 방식으로 옳은 것은?

• 같은 문항으로 분기마다 반복해 추세를 본다
• 한 번 측정한 절대 점수로 플랫폼의 성숙도를 판정한다
• 정성 지표이므로 참고만 하고 기록하지 않는다
• 점수가 낮은 팀에 개선 조치를 통보한다

플랫폼 팀이 자기 플랫폼에 SLO 를 두어야 하는 이유는?

• SLO 가 없으면 쿠버네티스가 워크로드를 스케줄하지 않기 때문에
• SLO 는 규제 요건이기 때문에
• 플랫폼의 가용성이 곧 그것을 쓰는 모든 팀의 가용성이며, 에러 버짓이 있어야 기능 개발과 안정화 사이 결정을 숫자로 할 수 있기 때문에
• SLO 를 두면 자동으로 비용이 줄기 때문에

서로 신뢰하지 않는 테넌트(예: 외부 고객이 임의 코드를 실행)를 수용해야 할 때 가장 부적절한 격리 수준은?

• 클러스터 분리
• 네임스페이스 + RBAC + 쿼터만으로 논리 분리
• 테넌트별 노드 풀 분리
• 클라우드 계정·구독 분리

쿠버네티스 환경 FinOps 에서 비용 절감 효과가 가장 큰 지점으로 흔히 지목되는 것은?

• 실제 사용량보다 과도하게 잡힌 리소스 requests
• 컨테이너 이미지 크기를 줄이는 것
• 로그 보존 기간 단축
• 네임스페이스 개수 축소