6. 운영 런북

시스템을 살아있게 유지하는 법: 배치 작업, 모니터링, 장애 대응, DB 운영.

6.1 배치 작업 (Cloud Scheduler)

이용권 관련 배치 2종이 매일 자동 실행됩니다. 전체 가이드 → docs/infra/cloud-scheduler.md.

Job	스케줄	설명
`spective-ticket-expire`	매일 00:01 KST	AVAILABLE/RESTORED 이용권 만료 처리
`spective-ticket-recover`	매일 00:01 KST	미사용 RESERVED 이용권 자동 복구 후 만료 처리

인증: 모든 CRON 엔드포인트는 CRON_SECRET Bearer 토큰 (timingSafeEqual)
엔드포인트: POST /api/tickets/expire, POST /api/tickets/recover
⚠️ recover는 recoverUnusedTickets() → processExpiredTickets() 순서가 중요(복구분이 만료 대상이 될 수 있음)
설정: ./scripts/setup-cloud-scheduler.sh dev|prod
관리: gcloud scheduler jobs {list,run,pause,resume,delete} ... --location=asia-northeast3

bash

# 수동 테스트 (dev)
curl -X POST -H "Authorization: Bearer ${CRON_SECRET}" \
  https://spective-web-xf3kugqnca-du.a.run.app/api/tickets/recover

⚠️ 별도 모니터링·알림 체계 없음 (현 담당자 확인). Cloud Monitoring 대시보드·외부 APM·Sentry·온콜 모두 미구성.
사실상 유일한 관측 수단: Cloud Run 로그 — GCP 콘솔 Cloud Run → spective-web → 로그 (또는 gcloud run services logs read spective-web --region=asia-northeast3)
@repo/logger 태그 컨벤션으로 필터링: admin:pricing, service:auth, composable:session 등
서버/프로덕션은 consola, 클라이언트 개발은 네이티브 console
💡 인수 권고: 최소한 Cloud Run 오류율·지연 알림(Cloud Monitoring) 또는 Sentry 도입을 우선 검토. 현재는 장애를 능동적으로 감지할 수단이 없음.

기록된 과거 장애 사례 없음(담당자 확인). 아래는 코드·설정에서 유추 가능한 알려진 대응만 정리.

증상	1차 확인	대응
서비스 5xx	Cloud Run 로그/리비전 상태	이전 리비전 롤백 (5.6)
배치 401(CRON_SECRET 불일치)	Cloud Run env vs Scheduler 헤더 일치 여부	`gcloud run services describe`로 env 확인 → cloud-scheduler.md 트러블슈팅
Cold start 타임아웃	min-instances 값	`gcloud run services update --min-instances=1`
배치 권한 오류	계정 IAM 역할	`roles/cloudscheduler.admin` 부여
결제/PG 오류	Cloud Run 로그(`service:` 태그), 토스 콘솔	토스페이먼츠 콘솔 확인 (알렉스앤앨리스)
이메일 미발송	Resend 대시보드, `resend` 로거	`RESEND_API_KEY`·발송 한도 확인 (§4.4)

DB: Supabase (관리형 Postgres), 리전 Seoul
접속: Prisma datasource(postgresql) — DATABASE_URL(pooled) + DIRECT_URL(direct, 마이그레이션용). 접속 문자열은 dotenvx 시크릿에 보관.
마이그레이션 배포: bun run db:migrate:deploy (prod 배포 파이프라인에 포함, 5.4)
시드: 환경별 명령 → 3.4, README.md Database
백업: Supabase 기본 정책에 의존 (플랜에 따라 자동 일일 백업 / PITR). Supabase 계정은 알렉스앤앨리스 소유이므로 플랜·백업 정책 관리도 알렉스앤앨리스 영역.
복구: 복구 수행 경험 없음. Supabase 대시보드 백업/복원 기능 사용. 인수 후 알렉스앤앨리스 측에서 복구 리허설 1회 권장.