관측 가능성에서 SRE까지

OpenTelemetry·SLI·오류 예산·온콜·포스트모템을 하나의 운영 시스템으로

telemetry를 SLO와 장애 대응으로 연결한다.

상태: 출간 후보 웹교정쇄 · 자동 QA 통과 · SRE 감수 대기 · 25개 장

OpenTelemetry·SLI·오류 예산·온콜·포스트모템을 하나의 운영 시스템으로

기준일: 2026-08-14 · 상태: 출간 후보 웹교정쇄 · 자동 QA 후 사람 현장 감수 대기

FieldPass의 사용자 결과를 signal과 SLO로 측정하고 배포·장애·개선 결정을 반복 가능하게 만든다. 대상 독자는 로그와 dashboard는 있지만 경보가 시끄럽고 장애 종료 기준과 배포 판단이 사람마다 다른 팀다. 기능을 따라 입력하는 데서 끝내지 않고 결정의 전제, 실패, 증거와 rollback을 한 세트로 남긴다. 숫자·한도·가격·UI는 영구 사실이 아니며 실습 직전 공식 문서를 다시 확인한다.

FieldPass는 방문 예약, 기사 배정, 사진, 결제와 정산을 가진 합성 B2B 서비스다. 여섯 권이 같은 tenant-demo, res-demo-101, run-demo-001을 사용한다. 따라서 도메인 결정이 API, telemetry, infrastructure, event와 edge에서 같은 의미인지 비교할 수 있다.

npm run test로 여섯 위험 fixture를 실행한다.
npm run build로 원고와 SVG를 재생성한다.
lab/public/index.html을 열어 입력·판정·증거·원복을 같은 화면에 기록한다.
실제 cloud·domain 적용은 소유자 승인, 비용 상한과 별도 staging에서만 한다.


cd fieldpass-platform
npm run qa
npm start

먼저 version 9로 의도한 실패와 Problem Details를 확인하고 새 process에서 version 1로 성공·Outbox 대사를 실행한다. 실제 cloud·domain 변경은 소유자 승인과 비용 상한이 있는 staging에서만 한다.


resource:
  service.name: fieldpass-api
  service.version: demo-sha
  deployment.environment.name: staging


sum(rate(reservation_confirmed_total[5m]))
/
sum(rate(reservation_attempt_total[5m]))


releaseByErrorBudget({
  budgetMinutes: 43.2, consumedMinutes: 38, projectedMinutes: 8
}); // HOLD


node --test test/platform-lab.test.mjs

fieldpass-platform을 실행하고 x-request-id: run-demo-001로 예약 확정과 의도한 version conflict를 만든다. browser, edge, API, domain, Outbox가 같은 ID를 보존해야 한다. 현재 예제에는 완전한 OTel Collector가 없으므로 log 한 줄을 trace라고 부르지 않는다. 다음 단계에서 Collector와 backend를 추가할 때 service.name, version, environment와 route template을 먼저 고정한다.

reliability.test.mjs의 99.9% fixture에서 전체 사건, 실패, 허용 실패와 예상 canary 실패를 다시 계산한다. HOLD를 RELEASE로 바꾸기 위해 target을 낮추지 말고 실패를 줄이거나 canary 범위를 낮춘다. dashboard에는 사용자 SLI, version, 최근 deploy와 Outbox backlog를 같은 시간축에 둔다.

game day는 dependency timeout, telemetry export 실패와 Outbox 지연을 별개로 주입한다. 완화 뒤 process health뿐 아니라 예약 결과, 중복 0과 backlog 대사를 확인한다. postmortem action에는 owner·기한·검증 test가 있어야 한다.

1장. 관측 가능성은 dashboard 수가 아니다
2장. 신뢰성을 사용자 언어로 정의한다
3장. Telemetry 계약을 먼저 만든다
4장. Trace로 경계와 시간을 본다
5장. Metric은 질문과 aggregation을 가진다
6장. Log는 사건 증거다
7장. Profile은 코드 자원 소비를 설명한다
8장. Collector를 신뢰 경계로 본다
9장. Sampling은 비용과 탐지율의 거래다
10장. SLI의 분모를 정확히 정한다
11장. SLO는 목표이자 의사결정 계약이다
12장. 오류 예산으로 배포를 제어한다
13장. Alert는 행동을 호출해야 한다
14장. Dashboard는 질문 순서로 배치한다
15장. Release 관측을 설계한다
16장. On-call을 지속 가능하게 만든다
17장. Incident command로 역할을 분리한다
18장. 완화가 진단보다 먼저일 때를 안다
19장. 복구는 업무 대사로 끝낸다
20장. Postmortem은 학습 시스템이다
21장. Toil을 측정하고 제거한다
22장. Telemetry 비용과 보존을 운영한다
23장. Game day로 runbook을 시험한다
24장. SRE 성숙도를 숫자 하나로 만들지 않는다
25장. 최종 캡스톤과 출간 게이트

관측 가능성에서 SRE까지

목차