docs: rewrite scenario to 51124 restart-loop outage incident

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)

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)
 
 ---