diff --git a/journey/scenarios/260304_아침브리핑_지연_먹통_복구_사용자시나리오.md b/journey/scenarios/260304_아침브리핑_지연_먹통_복구_사용자시나리오.md index 33b7602..5b43716 100644 --- a/journey/scenarios/260304_아침브리핑_지연_먹통_복구_사용자시나리오.md +++ b/journey/scenarios/260304_아침브리핑_지연_먹통_복구_사용자시나리오.md @@ -1,70 +1,63 @@ -# 아침 브리핑 지연/먹통 복구 시나리오 +# 51124 먹통 사건 사용자 시나리오 (restart loop) -**상태**: 부분 (현재 문제/기준선 측정 완료, 구조 개선 미적용) +**상태**: 부분 (원인 확정/수동 복구 완료, 구조 개선 미적용) **작성일**: 2026-03-04 -**대상 서비스**: `rb8001`, `robeing-monitor` +**대상 서비스**: `rb8001`(또는 robeing_monitor), Docker 운영 --- ## 1) 목적 -- 사용자가 실제로 겪은 "아침 업무 시간 응답 지연/먹통" 경험을 기준으로, 복구 후 어떤 체감 변화가 있어야 하는지 명확히 정의한다. -- 기술 구현 설명이 아니라, 사용자 기준의 실패 장면과 개선 장면을 고정한다. +- 사용자가 실제로 겪은 "서버 조작 불가 먹통" 사건을 사실 기준으로 고정한다. +- 이후 개선은 "응답 속도"가 아니라 "먹통 재발 방지"를 1순위로 검증한다. -## 2) 실제 실패 장면 (현재) +## 2) 실제 실패 장면 (확정 사실) +### 사건 흐름 +1. 컨테이너 상태가 `Restarting (1)`로 반복됨. +2. `python main.py` 프로세스가 CPU `600~700%` 점유. +3. 서버 GUI/입력이 밀리며 마우스와 터미널 조작이 사실상 불가. +4. 팬 소음 증가(고부하에 따른 냉각 동작). +5. 컨테이너 중지 후 CPU와 조작성이 정상화. + +### 사용자 체감 +- "느리다"가 아니라 "아예 조작이 안 된다." +- 업무 중 요청 재시도조차 못 하고 운영자가 강제 중지 조치를 해야 한다. + +## 3) 원인 확정 근거 +| 항목 | 관측값 | 판정 | +|------|--------|------| +| 컨테이너 | `Restarting (1)` 반복 | 재시작 루프 발생 | +| 프로세스 CPU | `python main.py` 600~700% | 다코어 과점유 | +| 메모리 | 16GB 중 약 3GB 사용, swap/OOM 없음 | RAM 원인 아님 | +| 하드웨어 | CPU/RAM/SSD 이상 징후 없음 | HW 원인 아님 | + +## 4) 즉시 복구 조치 (실제 수행) +- `docker stop robeing_monitor` +- `docker stop $(docker ps -q)` +- 결과: CPU 부하 정상화, 입력 가능 상태 회복 + +## 5) 개선 후 장면 (사용자 기준) ### 장면 -- 시간: 평일 오전 9시~10시 (브리핑/일정/메일 처리 집중 시간) -- 사용자 행동: "오늘 메일 우선순위 알려줘", "일정 등록해줘"를 연속 요청 -- 체감 문제: - - 응답이 늦어짐(기다림 증가) - - 재시도 필요(같은 질문 반복 입력) - - 최악의 경우 서비스가 멈춰 업무 흐름이 끊김 - -### 현재 관측값(사실) -| 항목 | 현재 관측값 | 비고 | -|------|-------------|------| -| `/api/message` 단건 응답 | 약 2.24초 | 2026-03-04 실측 1회 | -| 피크 구간 응답 | 3초 제한 타임아웃(HTTP:000) | `TOTAL:3.000558` 기록 | -| 장애 당시 서버 체감 | GUI 멈춤/재시작 루프 관측 | 51124 장애 상황 | - -## 3) 개선 후 장면 (사용자 기준) -### 장면 -- 동일 시간대(오전 9시~10시), 동일 사용자 요청(브리핑/메일/일정)에서 -- 사용자는 질문 1회 입력 후 응답을 받고 바로 다음 행동(회신/일정 등록)을 시작한다. +- 동일 부하 상황에서도 컨테이너가 재시작 루프에 빠지지 않고, +- 운영자는 서버를 강제 중지하지 않아도 서비스를 계속 조작할 수 있다. ### 기대되는 체감 변화 -- "기다림 때문에 다시 입력"이 줄어든다. -- "지금 당장 할 1건" 응답을 끊김 없이 받는다. -- 브리핑 시간 안(9~10시)에 메일/일정 처리를 끝낼 수 있다. +- 마우스/터미널 멈춤 없음 +- "전체 컨테이너 강제중지" 대응이 사라짐 +- 장애 발생 시에도 특정 서비스만 격리/복구 가능 -## 4) 개선 검증 시나리오 -### 검증 대상 요청 -1. "오늘 메일 중 지금 답장할 1건만 말해줘" -2. "내일 9시 일정 등록해줘" -3. "오늘 브리핑 핵심 3줄만" +## 6) 재발 방지 검증 기준 +| 항목 | 현재 사건 기준 | 개선 목표 | +|------|----------------|-----------| +| Restart loop | 발생 | 0회 | +| CPU 급등 | 600~700% 관측 | 장시간 지속 300% 초과 0회 | +| 운영 조작성 | 조작 불가 구간 발생 | 조작 불가 0회 | +| 긴급 대응 | 전체 컨테이너 중지 필요 | 단일 서비스 격리로 복구 | -### 검증 방법 -- 같은 사용자로 9~10시 구간 연속 호출 -- 사용자 관점 체크: - - 1회 질문으로 응답 받았는지 - - 재시도 없이 다음 행동으로 넘어갔는지 - - 처리 중 멈춤/끊김이 없었는지 +## 7) 완료 판정 +- 운영자가 "서버 전체 멈춤" 없이 장애를 제어할 수 있어야 함. +- 동일 유형 장애에서 restart loop 재발이 없어야 함. +- 사용자 체감 기준으로 "멈춤"이 아니라 "지연 내 복구 가능" 상태여야 함. -### 목표 수치(개선 목표) -| 항목 | 목표 | -|------|------| -| `/api/message` P50 | 1.0초 이하 | -| `/api/message` P95 | 2.0초 이하 | -| 3초 초과 비율 | 1% 미만 | -| 컨테이너 재시작 | 0회 | - -## 5) 완료 판정 -- 사용자 기준: - - 오전 9~10시 연속 요청에서 "재질문/재시도 없이" 업무 진행 가능 -- 운영 기준: - - 3초 타임아웃 재발 없음 - - 재시작 루프 없음 - - 헬스체크/로그 기준 정상 상태 유지 - -## 6) 연결 문서 -- [자기개선 루프 DB/서비스 구현 실행계획](../plans/260303_자기개선루프_DB_구현_실행계획.md) +## 8) 연결 문서 - [51123 임시복구 서비스 연속성 조치내역](../troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md) +- [자기개선 루프 DB/서비스 구현 실행계획](../plans/260303_자기개선루프_DB_구현_실행계획.md) diff --git a/journey/scenarios/README.md b/journey/scenarios/README.md index 2cc41d6..c0e8a01 100644 --- a/journey/scenarios/README.md +++ b/journey/scenarios/README.md @@ -60,7 +60,7 @@ - [IR Deck 평가 시나리오](./ir_deck_evaluation_scenario.md) - [베이지안 세미나 발표 시나리오](./251223_bayesian_seminar_presentation_scenario.md) - [자기개선 루프 미팅 요약 시나리오 (260303)](./260303_자기개선루프_미팅요약_피드백_시나리오.md) -- [아침 브리핑 지연/먹통 복구 사용자 시나리오 (260304)](./260304_아침브리핑_지연_먹통_복구_사용자시나리오.md) +- [51124 먹통 사건 사용자 시나리오 (260304)](./260304_아침브리핑_지연_먹통_복구_사용자시나리오.md) ---