# 260304 51123 임시복구 서비스 연속성 조치내역

## 1. 목적
- 51124 서버 장애 상황에서 51123 단독으로 robeing 핵심 서비스 연속성을 임시 복구한다.
- 2026-03-04 기준, 내일(2026-03-05) 오전 9시~10시 일정/이메일 경로 중단을 방지한다.

## 2. 장애 징후 및 운영 영향
- `/api/message` 응답이 3초 제한 내 타임아웃(`HTTP:000`, `curl (28)`)으로 실패.
- 게이트웨이 경유 일부 경로에서 422/500이 혼재되어 호출 신뢰도가 저하.
- PostgreSQL 연결 슬롯 고갈(Idle 세션 누적)로 신규 작업 지연.
- 51124 불가 상태로 기존 이중서버 가정(23 인프라 + 24 실행)이 깨짐.

## 3. 확인된 근본 원인
1. Docker 브리지 대역(`172.21.0.0/16`)에서 호스트 포트(8001, 9024, 8512) 접근이 방화벽에 막혀 내부 연계가 단절됨.
2. PostgreSQL Idle 세션 누적으로 커넥션 풀 여유가 줄어 응답 지연이 증폭됨.
3. rb8001 런타임에서 고비용 경로(의도/검색 그래프 포함)가 활성화된 상태로 느린 경로가 잦게 호출됨.
4. gateway 환경변수 일부가 운영 실IP 기준과 어긋나 헬스/검증 경로가 불안정했음.

## 4. 실제 조치 내역(51123)
### 4.1 네트워크/방화벽
- UFW allow 규칙 추가:
  - `from 172.21.0.0/16 to any port 8001 proto tcp`
  - `from 172.21.0.0/16 to any port 9024 proto tcp`
  - `from 172.21.0.0/16 to any port 8512 proto tcp`

### 4.2 데이터베이스
- Idle 커넥션 92건 정리(`pg_terminate_backend`)로 슬롯 회복.
- 즉시 재접속 정상화 확인.

### 4.3 rb8001 성능 안전모드(임시)
- `/home/admin/rb8001/.env` 오버라이드 적용:
  - `INTENT_ENGINE=v1`
  - `INTENT_USE_LANGGRAPH=false`
  - `INTENT_USE_COT=false`
  - `WEB_SEARCH_USE_GRAPH=false`
- 적용 방식: `docker compose down && docker compose up -d --build`

### 4.4 gateway 운영값 정합화
- `/home/admin/robeing-gateway/.env` 수정:
  - `ROBEING_DEFAULT_HOST=192.168.219.45`
  - `MONITOR_URL="http://192.168.219.45:9024"`
- 적용 방식: `docker compose down && docker compose up -d --build`

## 5. 검증 결과(2026-03-04)
1. 컨테이너 상태
- `robeing-gateway(8100)`, `rb8001(8001)`, `robeing_monitor(9024)`, `skill-calendar(8512)`, `skill-email(8501)` running 확인.

2. 헬스/응답
- gateway `/healthz` 200.
- gateway `/api/message` 정상 응답 복구(측정 약 0.5~1.7초 구간).

3. 핵심 기능
- 일정성 문구 포함 메시지 요청 시 응답 정상.
- `self-improvement`, `prompt-db`는 유효 스키마 요청에서 성공, 비유효 payload는 기대대로 422/500.

4. 이메일 경로(내일 9~10시 핵심)
- `skill-email` `/health` 200.
- rb8001 컨테이너 -> skill-email 내부 호출 200.
- NaverWorks 메일 리스트 API(실 UUID `3550cef6-63e1-4ceb-8802-a25c9d1c6917`) 200, 목록 수신 확인.

5. 스케줄 DB
- `scheduled_jobs` 활성 항목 확인:
  - `naverworks_daily`: `0 9 * * mon-fri`
  - `coldmail_daily`: `5 9 * * mon-fri`
  - `daily_headlines`: `10 9 * * mon-fri`
  - `companyx_news`: `0 10 * * mon-fri`

## 6. 잔여 리스크 및 운영 주의
- `skill-embedding(8515)` 미기동 상태는 지속. rb8001 로그에 임베딩 연결 에러가 간헐적으로 남을 수 있음.
- 현재 복구는 "핵심 연속성 확보" 기준의 임시 안정화이며, 51124 복구 후 원래 분리구조로 되돌리는 재배치가 필요.
- 스케줄 실행 직전/직후(2026-03-05 08:55~10:10) 구간 모니터링을 강화해야 함.

## 7. 24 서버 인계 메모
- 51124 복구 후 우선순위:
  1. rb8001/skill/chromadb 원복 배치
  2. gateway 대상 upstream 재점검
  3. 임시 성능 플래그(`INTENT_USE_LANGGRAPH=false` 등) 단계적 해제 여부 성능 측정 후 결정
- 본 문서는 51123 임시복구 기준 운영 기록이며, 24 원복 시 별도 후속 문서로 분리 기록 권장.

## 8. 추가 복구/배포 안전화 기록 (2026-03-04 03:00~03:30 KST)
### 8.1 스킬 복구 상태(51123)
- 실행 확인:
  - `robeing-skill-news` (`8505`) healthy
  - `skill-slack` (`8502`) healthy
  - `skill-rag-file` (`8508`) healthy
  - `skill-embedding` (`8515`) healthy
- 헬스 응답 확인:
  - `GET http://192.168.219.45:8505/health` -> `{"status":"healthy"}`
  - `GET http://192.168.219.45:8502/health` -> healthy 응답
  - `GET http://192.168.219.45:8508/healthz` -> healthy 응답
  - `GET http://192.168.219.45:8515/healthz` -> `{"status":"ok"}`

### 8.2 근본 원인과 조치(embedding)
- 근본 원인:
  - `skill-embedding` 재시작 루프 원인은 `/models/onnx/ko-sroberta-multitask/model.onnx` 파일 부재.
  - 로그 근거: `FileNotFoundError: ONNX 모델 파일을 찾을 수 없습니다`.
- 조치:
  - `jhgan/ko-sroberta-multitask`를 ONNX로 변환해 `model.onnx` 생성.
  - 생성 경로: `/home/admin/robeing/onnx_models/ko-sroberta-multitask/model.onnx` (약 423MB).
  - 이후 `skill-embedding` `docker compose down && up -d --build`로 정상화.

### 8.3 배포 안전화(23/24 경로 일반화) 및 푸시
- `skill-rag-file`:
  - `DOCUMENT_MOUNT_ROOT`, `DOCUMENT_BASE_PATH` 기반으로 볼륨/경로를 서버별 `.env` 오버라이드 가능하게 일반화.
  - 반영 커밋: `ab3ac78` (`main` 푸시 완료).
- `skill-embedding`:
  - `ONNX_MODELS_HOST_PATH` 기반으로 모델 마운트 경로 일반화.
  - 24 자동배포 기본값은 `/home/admin/ivada_project/onnx_models`로 고정.
  - 23 임시복구는 `.env` 오버라이드로 유지.
  - 반영 커밋: `5a0f357`, 추가 교정 `ede5896` (`main` 푸시 완료).

### 8.4 Gitea workflow 점검 결과
- 점검 대상: `rb8001`, `skill-news`, `skill-slack`, `skill-email`, `skill-calendar`, `skill-rag-file`, `skill-embedding`, `robeing-monitor`의 `.gitea/workflows/*.yml`.
- 결론:
  - 이번 이슈 기준(서버 경로 하드코딩)으로는 workflow YAML 추가 수정 없이 `.env`/compose 일반화로 대응 가능.
  - 별도 개선 후보: `skill-calendar` workflow의 `runs-on` 위치가 비표준 구조라 안정성 점검 필요(후속 과제 분리).