관측 가능성과 SLO
개요
보이지 않는 것을 운영, 디버깅 또는 개선할 수 없습니다. 관측 가능성은 설계 단계에서 포함되어야 하며, 첫 번째 장애 발생 후에 덧붙이는 것이 아닙니다. 모든 인시던트에서 첫 번째 질문은 '무엇이 변경되었고 누가 영향을 받았는가'입니다. 이에 답할 수 없는 시스템은 5분이면 해결될 문제를 고고학적 발굴로 만듭니다.
원칙 (보편적)
- 세 가지 신호. 구조화된 로그(기계가 파싱 가능한, 자유 텍스트 아님), 메트릭(개수, 비율, 지속 시간), 트레이스(서비스 전반의 요청 경로)를 출력하세요. 요청은 종단 간 상관관계/트레이스 ID를 전달합니다.
- 모든 표면에 황금 신호 계측 (RED): 엔드포인트/연산당 비율, 오류, 지속 시간, 리소스 포화도 포함. 새 엔드포인트는 관측 가능해질 때까지 '완료'된 것이 아닙니다.
- 상태는 추측이 아닌 엔드포인트입니다. 활성 프로브("실행 중인가?")와 준비 프로브("트래픽을 처리할 수 있는가?")를 별도의 점검으로 노출하세요.
- 중요한 사용자 여정에 대해 SLO를 정의하고, 이를 측정하는 SLI와 신뢰성 대 기능을 명시적이고 데이터 기반으로 절충하는 에러 예산을 설정하세요.
- 증상에 대해 알리고, 원인에 대해 알리지 마세요. 사용자가 피해를 입을 때(SLO 소진, 준비 프로브 실패) 페이징하고, 모든 내부적인 작은 문제에 대해서는 페이징하지 마세요. 모든 알림은 실행 가능해야 합니다. 아무도 실행하지 않는 알림은 사람들이 알림을 무시하도록 훈련시킵니다.
메커니즘 (이 스택)
- 구조화된 JSON 로그를 stdout으로 출력, 플랫폼에서 수집 (예: AKS → Azure Monitor / Log Analytics). 서비스 내에서 자유 텍스트 로깅 금지.
- 앱 서버와 PostGraphile에 OpenTelemetry 적용; 트레이스/메트릭을 Azure Monitor / Application Insights (또는 Prometheus/Grafana)로 내보냅니다.
- 데이터 경로 전체에 상관관계 ID 전파 — 가장자리에서 생성되어 Browser → App → PostGraphile로 컨텍스트 헤더와 함께 전달되며, 모든 로그 라인과 스팬에 첨부됩니다.
- 각 HTTP 라우트 및 GraphQL 연산에 대한 RED 메트릭; Postgres 느린 쿼리 로그 +
pg_stat_statements. - 활성/준비 프로브 엔드포인트를 Kubernetes 프로브에 연결 (
cloud-delivery-aks참조). 준비 프로브는 실제 종속성 상태(데이터베이스에 연결 가능한가?)를 반영하며, 단순히 프로세스 실행 여부만 확인하지 않습니다. - 프론트엔드: web-vitals와 클라이언트 오류를 동일한 백엔드에 보고합니다.
- 여정별 SLO와 대시보드, 번-레이트 알림.
확장 시점
사전 출시/로컬 프로젝트는 지금 구조화된 로그와 상태 점검 엔드포인트만 구현하고, 보호할 실제 사용자가 생길 때까지 SLO/알림을 연기합니다. 첫 번째 결정 레코드에서 이 모드를 명시하세요.
전체 근거: 헌법 제IX조 및 제XVI조, engineering-constitution/references/engineering-constitution.md에 번들로 제공됩니다.