20 rps를 성공이라고만 쓰지 않은 이유
TravelPlanner의 기준선 후보는 20 rps에서 세 번 반복했습니다. 세 후보 모두 후보 SLO를 통과했고 Core API p95는 다음과 같았습니다.
baseline-1 133.9766593 ms
baseline-2 134.5727219 ms
baseline-3 142.9879898 ms
세 실행 모두 core unexpected error와 contract failure가 0이었습니다. 여기까지만 보면 20 rps × 3 성공이라고 쓰기 쉽습니다.
하지만 enclosing B-01 gate의 최종 passed 값은 false입니다. ramp stage marker가 없어 해당 단계의 fixture 검증을 통과하지 못했기 때문입니다.
따라서 정확한 문장은 두 개로 나뉩니다.
- 20 rps 기준선 후보 3회는 각각 후보 SLO를 통과했다
- B-01 전체 gate는 ramp marker 누락으로 실패했다
후보 결과와 파이프라인 전체 결과를 분리해야 자동화가 놓친 구멍을 숨기지 않을 수 있습니다.
B02의 복구 시간을 한 숫자로 축약하지 않았다
B02 판정에는 여러 시간 구간이 기록되어 있습니다.
- 기록 T1→T6: 299.352초
- 복구 실행 T4→T6: 265.586초
- 보수적 보정 T1→T6: 318.004초
- 기록된 예산: 600초
보수적 보정값은 기록 T1이 실제 mutation보다 늦게 남은 약 22초를 반영합니다. 기록값과 보정값 모두 600초 이내였습니다.
이 수치를 일반적인 MTTR이라고 부르지 않았습니다. 한 시나리오의 정의된 이벤트 경계에서 측정한 시간이기 때문입니다.
다섯 판정은 60% 신뢰도 점수가 아니다
최종 판정은 다음과 같습니다.
- B02: 통과
- R01: 통과
- R03: 통과
- R05: 기준 미달
- R07: 기준 미달
R05와 R07은 연속 120초 T6 SLO 구간을 만들지 못했습니다. 실패를 제거하거나 평균에 섞지 않고 판정 파일 자체를 공개했습니다.
R01도 주의해서 읽어야 합니다. 계획된 staged rollout이므로 장애 복구 600초 예산을 적용한 것이 아니라, frozen contract의 zero-error 비교자로 판정했습니다. 반면 R03은 수동 복구 시나리오여서 T4→T6 476.453초를 600초 예산과 비교했습니다.
그래서 3/5는 작은 시나리오 집합의 판정 요약일 뿐, 일반화된 가용성이나 신뢰도 백분율이 아닙니다.
실패한 판정이 다음 구현을 만든다
기준 미달은 포트폴리오에서 빼야 할 흠이 아니라 다음 설계 입력입니다. R05와 R07은 안정 구간을 만족하지 못했다는 구체적인 실패 조건을 남겼습니다. B-01은 시스템 응답이 아니라 ramp marker 계약이 비어 있었다는 자동화 실패를 남겼습니다.
이 차이를 구분하면 수정 순서도 달라집니다.
- 서비스 응답과 복구 상태가 문제면 런타임과 용량 경계를 점검
- fixture와 marker가 문제면 검증 파이프라인을 fail-closed로 보완
- 이벤트 시각이 늦게 기록되면 보수적 시간 계산과 lineage를 추가
운영 검증의 목적은 모든 칸을 초록색으로 만드는 것이 아니라, 초록색과 빨간색이 같은 계약에서 설명되게 하는 것입니다.
다음 글
3부에서는 OIDC repository identity와 Launch Template 버전 고정을 하나의 장애 원인처럼 엮지 않습니다. 서로 다른 단계에서 발견한 두 배포 가드레일로 나누고, 계획 검증과 런타임 검증의 경계를 정리합니다.