800 운영/850 실행/recovery_collector_deployment_validation.md

recovery_collector 배포 검증 — 최소 검증명령과 재현 절차

목적 - recovery_collector 서비스가 정상 기동·동작하며 복구 시나리오에서 예상대로 동작하는지 검증하기 위함.

저장 위치 - Vault: knowledge/800 운영/850 실행/recovery_collector_deployment_validation.md - Ops TODO: ops_todos 항목(아래 DB 레코드로 연동)

요약(3줄) - 서비스 상태 확인, 로그 필터링, 간단한 복구 시나리오 실행 순서로 구성. - 각 단계에 최소 명령·예상 출력 예시 포함. - 문서는 자동 검증 체크리스트로 사용 가능하며, 실패 시 ops_todos에 결과 링크/스크린샷 첨부.

검증 전제 - 대상 호스트에 접근 가능하고 systemctl(또는 launchd)로 서비스 관리 가능. - 로그는 journalctl 또는 지정 로그 파일로 수집됨. - 테스트 복구 시나리오는 비파괴(데이터 손실 없음)로 설계됨.

A. 서비스 상태 확인 1) 서비스 유무 및 활성 상태 - systemd 환경: - 명령: sudo systemctl status recovery_collector - 성공 예시(요약): "Active: active (running)" 와 함께 Main PID, 시작 시간 표기 - macOS(launchd) 환경: - 명령: launchctl list | grep recovery_collector - 성공 예시: plist 항목이 존재하고 PID 필드가 0이 아닌 값

2) 프로세스 확인 - 명령: pgrep -fl recovery_collector - 성공 예시: 복수 노드일 경우 각 노드에서 PID와 실행 경로가 표시

3) 포트·리스너 확인(해당 시) - 명령: sudo ss -lptn | grep <포트> 또는 sudo lsof -i :<포트> - 성공 예시: recovery_collector(또는 실행 바이너리) 소유의 프로세스가 포트 바인딩

B. 로그 필터링·핵심 메시지 확인 1) 최근 로그(실시간 tail) - journalctl 사용: - 명령: sudo journalctl -u recovery_collector -n 200 --no-pager - 목적: 최근 200줄로 빠르게 이상징후(에러, 예외) 확인 - 파일 로그 사용: - 명령: sudo tail -n 200 /var/log/recovery_collector/recovery_collector.log

3) 복구 관련 이벤트(예: snapshot, restore) 필터링 - 명령: sudo journalctl -u recovery_collector | grep -Ei "restore|snapshot|recovery|rollback" | tail -n 200 - 예상 출력 예시: - "INFO recovery_collector: started restore from snapshot id=..." - "INFO recovery_collector: restore completed, duration=12.3s"

C. 간단한 헬스·메트릭 검사 1) 헬스 엔드포인트(있을 경우) - 명령: curl -fsS http://localhost:9090/health || echo "unreachable" - 성공 예시: {"status":"ok","uptime":"12345s"}

2) 메트릭 엔드포인트(있을 경우) - 명령: curl -fsS http://localhost:9090/metrics | grep recovery_collector - 체크 포인트: 에러 카운터, restore_success_total, restore_failure_total - 예상 출력 예시: "restore_success_total 42"

D. 테스트 복구 시나리오(비파괴) - 목표: 실제 데이터를 손상시키지 않고 복구 로직 경로(시작→진행→완료)를 실행하여 로그·메트릭 변화를 확인. - 전제: 서비스는 테스트 모드 또는 스테이징 환경에서 실행 권장.

시나리오 1: 모의 스냅샷 복구(권장: 스테이징) 1) 준비 - 명령: curl -X POST http://localhost:9090/api/snapshot -d '{"type":"test","note":"smoke"}' -H 'Content-Type: application/json' - 예상 출력: {"snapshot_id":"snap-2026-...","status":"created"} 2) 복구 시작 - 명령: curl -X POST http://localhost:9090/api/restore -d '{"snapshot_id":"snap-2026-...","dry_run":true}' -H 'Content-Type: application/json' - 목적: dry_run=true로 실제 적용 없이 플로우 검사 - 예상 출력: {"restore_id":"rst-...","status":"dry_run_complete","errors":0} 3) 로그 및 메트릭 검증 - 명령: sudo journalctl -u recovery_collector -n 200 | grep rst-... -A 10 -B 3 - 예상 로그: 시작/진행/완료 이벤트와 duration 필드

시나리오 2: 의도적 임시 장애 후 복구 플로우(로컬 스테이징) 1) 장애 유발(비영구적) - 명령: sudo systemctl stop dependency_service_or_network_simulator - 목적: 복구 트리거 조건 유발 2) recovery_collector 동작 관찰 - 명령: sudo journalctl -u recovery_collector -f - 예상 동작: 장애 인식 로그, 재시도, 큐잉 메시지 3) 복구 조치 및 재기동 - 명령: sudo systemctl start dependency_service_or_network_simulator - 이후: recovery_collector가 정상 복구 루틴 실행(로그에 restore completed)

E. 재현 절차(검증 순서 요약) 1) 서비스 상태 확인(systemctl/pgrep) 2) 최근 로그 수집(journalctl/tail) 3) 에러·복구 이벤트 필터링(grep) 4) 헬스·메트릭 엔드포인트 확인(curl) 5) 스모크 복구 시나리오 실행(dry-run 우선) 6) 로그·메트릭으로 완료 확인 7) 실패 시 ops_todos에 문제 등록(아래 예시)

F. 최소 출력 샘플(예시) - 서비스 상태: - Active: active (running) since Mon 2026-03-XX 10:12:34 KST; Main PID: 12345 (recovery_collector) - 에러 로그: - Mar 19 10:15:02 host recovery_collector[12345]: ERROR failed to connect to storage: timeout - 복구 완료 로그: - Mar 19 10:20:10 host recovery_collector[12345]: INFO restore completed restore_id=rst-20260319-0001 duration=12.3s - 헬스 응답: - {"status":"ok","uptime":"12345s"}

G. ops_todos로의 연동(예시 레코드) - title: "recovery_collector 배포 검증 실행" - detail: "배포 검증 문서 기반 명령 실행 및 결과(로그 스냅샷, 헬스 응답) 업로드" - priority: high - assigned_to: ron

H. 검증시 주의사항 - 운영 서비스에 직접적인 파괴적 조치 금지(백업·승인 없는 restore 금지) - 권한이 필요한 명령은 sudo로 실행; 기록과 스크린샷을 남길 것 - 스테이징에서 먼저 실행하고 운영에서 재현 필요 시 ops_todos로 승인 요청

문서 작성자: Ron 자동생성 최종 업데이트: 2026-03-19