passv는 현재 prod 정본이 EC2(docker-compose) + S3/CloudFront이고 중앙 gitops(K8s)로 이전 중이라, 환경에 따라 보는 곳이 다르다. 먼저 서비스 공통 1차 대응 절차를 적용한다.
passv-server, /api/health), .env.production, EC2 호스트, CloudFront(프론트 S3).passv, workload api·mysql, ingress api-ingress, host app/api.passv.co.kr/api.api 와 mysql 관계를 본다sudo kubectl get deploy,sts,pods,svc,ing -n passv
sudo kubectl logs deploy/api -n passv --tail=100
/apps/passv-*) 누락, migration·startup 실패.sudo kubectl describe ingress -n passv api-ingress
app.passv.co.kr/api.passv.co.kr 기준, /api 연결. 화면은 뜨는데 API만 죽으면 CloudFront /api* origin이 ingress를 가리키는지 확인.ssh <EC2_HOST_PROD>
docker compose -f infra/compose/prod.yml ps
docker logs passv-server --tail=100
curl -f http://localhost:8000/api/health
rollback.yml 또는 직전 .env.production/이미지로 재기동.챗봇 발화 실패는 인프라 지표로 안 잡혀, passv 백엔드가 Alerta로 직접 알림을 보낸다. 개요는 2. 모니터링·알람·SRE, 켜기·키 발급·검증은 Manual/06 Alerta 사용법.
api 재시작 루프 없이 수렴, mysql 정상, /api/health 200, 대표 로그인/대화 흐름 동작.api·mysql 동시 비정상 / DB 연결 실패 반복 / 직전 배포 원인 명확 / 결제·인증 등 핵심 도메인 장애.온보딩 트랙 2부. 서비스 운영
이전: passv 모니터링·알람·SRE · 다음: palcar 서비스 가이드 · 전체 경로: 시작하기: 신입 온보딩