$DESKTOP-TKLFCPR\ython$ DESKTOP-TKLFCPR\ython e228faabf5 feat(itsm): G-1~G-12 확장 기능 + 하네스/봇/설치스크립트 구현

G-1: 메신저 Webhook Relay + _send_to_room 실제 httpx 호출 구현
G-2: POST /api/tasks/bulk SR 대량작업 엔드포인트 (최대 100건)
G-3: 라이선스 만료 알림 스케줄러 (매일 09:00 KST)
G-4: 체험판 upgrade_banner 필드 + license.py 배너 로직
G-5: core/auto_rca.py + incidents/problem auto-rca 엔드포인트
G-6: core/deploy_impact.py + vibe impact-analysis 엔드포인트
G-7: core/ticket_classifier.py + SR 생성 시 AI 분류 + ai-suggestion API
G-8: VulnPatchRecord 모델 + vuln_scan 패치추적 4개 엔드포인트
G-9: core/jira_sync.py + gateway Jira/Confluence 연동 엔드포인트
G-10: core/push_notify.py + routers/push.py + PushSubscription 모델
G-11: approvals 다중승인 (위임/서명/기한초과/마감연장)
G-12: alembic.ini + migrations/ + cicd/migrate_to_postgres.sh

하네스: guardia-orchestrator 확장기능 Phase 반영
봇명령어: /sr /status /license /bulk 슬래시 명령어 추가
설치스크립트: setup/ (Ubuntu, CentOS, RHEL, Windows) --test 옵션 포함

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-05-29 18:18:52 +09:00

26 KiB

Raw Blame History

테스트케이스 — 분기별 정기 PM (서버 OS 재기동 및 사후 헬스체크)

고객: 한국문화원연합회
대상 시스템: 5개 전체 (문화품앗이, 누리집, 누리집 관리자, 지역N문화, 통합자료관리시스템)
PM 주기: 분기 1회 (3개월마다)
작성일: 2026-05-25

PM 작업 개요

목적: 서버 OS 재기동 후 5개 시스템이 정상 복구되었는지 검증

순서:
  1단계 — 재기동 전 사전 점검 (Pre-PM Check)
  2단계 — 서버 재기동 수행
  3단계 — 재기동 후 사후 헬스체크 (Post-PM Health Check)
  4단계 — 전면 서비스 최종 확인 (Web 화면 직접 확인)
  5단계 — PM 결과 보고서 작성

점검 대상 서버 및 서비스 포트

시스템	URL	서비스 포트	비고
문화품앗이	https://csv.culture.go.kr/	80, 443	PHP/WEB
공식 누리집	https://www.kccf.or.kr/	80, 443	WEB (Read-Only)
누리집 관리자	https://mng.kccf.or.kr	80, 443	CMS
지역N문화	https://www.nculture.org/	80, 443, 8080	eGovFrame/WAS
통합자료관리	https://archive.nculture.org/	80, 443, 8080	Java Tomcat WAS

사전 준비물

필요한 것:
1. 서버 SSH 접속 가능한 터미널 (예: PuTTY, MobaXterm, Windows Terminal)
2. Chrome 또는 Edge 브라우저
3. 이 테스트케이스 문서 (인쇄 권장)
4. PM 결과 기록 시트 (엑셀 또는 노트)
5. 비상 연락망 (서버 담당자, 개발팀)
6. GUARDiA ITSM 로그인 (PM 작업 등록용)

결과 기호:
  O = 통과 (정상)
  X = 실패 (비정상 — 담당자 즉시 연락)
  △ = 보류 (추가 확인 필요)

1단계 — 재기동 전 사전 점검 (Pre-PM Check)

이 단계는 재기동 전에 현재 서비스 상태를 기록합니다.
재기동 후 비교 기준이 됩니다.

TC-PM-PRE-001: GUARDiA ITSM에 PM 작업 등록

목적: PM 시작 전 공식 작업 기록을 남깁니다.
소요 시간: 약 5분

번호	따라 할 행동	이렇게 되면 통과(O)
1	GUARDiA ITSM(`http://ITSM서버주소:8000/`)에 로그인합니다	대시보드가 열립니다
2	"정기점검(PM)" 메뉴 → "PM 작업 생성"을 클릭합니다	PM 작업 등록 양식이 나타납니다
3	작업명: `한국문화원연합회 분기별 서버 재기동 PM (YYYY-MM-DD)` 을 입력합니다	입력됩니다
4	점검 서버, 담당자, 예정 시작 시간을 입력합니다	입력됩니다
5	"저장" 버튼을 클릭합니다	PM 작업이 등록됩니다
6	워크타임테이블(업무 일정)에 PM 일정이 표시되는지 확인합니다	일정 캘린더에 PM이 보입니다

PM 작업 ID (등록 후 기록): ___________________

TC-PM-PRE-002: 웹 서비스 현재 상태 기록 (5개 사이트)

목적: 재기동 전 모든 사이트가 정상 응답하는지 확인 및 기록
소요 시간: 약 10분

아래 표에 현재 시간을 적고, 각 사이트의 상태를 기록하세요.

점검 시작 시각: ________

번호	사이트	URL
1	문화품앗이	https://csv.culture.go.kr/
2	공식 누리집	https://www.kccf.or.kr/
3	누리집 관리자	https://mng.kccf.or.kr
4	지역N문화	https://www.nculture.org/
5	통합자료관리	https://archive.nculture.org/

확인 방법 (브라우저):

각 URL을 Chrome에서 열고:
1. 페이지가 정상 표시되면 O
2. F12 → Network 탭 → 맨 위 요청의 Status 숫자 기록 (200이면 정상)
3. 로딩 시간은 Network 탭 하단 "Finish" 시간 참고

확인 방법 (터미널, 선택):

# 각 사이트 HTTP 상태 코드 확인
curl -o /dev/null -s -w "%{http_code}\n" https://csv.culture.go.kr/
curl -o /dev/null -s -w "%{http_code}\n" https://www.kccf.or.kr/
curl -o /dev/null -s -w "%{http_code}\n" https://mng.kccf.or.kr/
curl -o /dev/null -s -w "%{http_code}\n" https://www.nculture.org/
curl -o /dev/null -s -w "%{http_code}\n" https://archive.nculture.org/
# 모두 200이 출력되면 정상

TC-PM-PRE-003: 서버 프로세스 사전 현황 기록

목적: 재기동 전 서버에서 구동 중인 핵심 프로세스를 기록합니다.
소요 시간: 약 10분

SSH로 각 서버에 접속하여 아래 명령어를 실행하고 결과를 기록합니다.

3-1. Tomcat/WAS 프로세스 확인

# Tomcat 프로세스 확인
ps -ef | grep tomcat | grep -v grep

# 결과 예시 (정상):
# tomcat   12345     1  0 09:00 ?  00:01:23 java -Djava.util.logging...

서버	Tomcat 프로세스 PID	상태	기록
지역N문화 WAS
통합자료관리 WAS

3-2. 포트 리스닝 상태 확인

# 서비스 포트 확인 (80, 443, 8080)
ss -tlnp | grep -E ':80|:443|:8080'

# 또는
netstat -tlnp | grep -E ':80|:443|:8080'

포트	리스닝 여부	프로세스 이름	결과
80 (HTTP)
443 (HTTPS)
8080 (Tomcat)

3-3. 디스크 사용량 확인 (재기동 전)

df -h
# 루트(/) 파티션이 90% 이상이면 재기동 전 정리 필요!

파티션	사용량(%)	주의 필요?	기록
/ (루트)
/data (있는 경우)

TC-PM-PRE-004: DB 서비스 상태 확인

목적: 데이터베이스 서비스가 정상 동작 중인지 확인하고 재기동 후 비교합니다.
소요 시간: 약 5분

# MySQL/MariaDB 확인
systemctl status mysql     # Ubuntu
systemctl status mariadb   # CentOS
ps -ef | grep mysql | grep -v grep

# Oracle/PostgreSQL 확인 (사용 중인 경우)
ps -ef | grep ora_pmon | grep -v grep   # Oracle
systemctl status postgresql             # PostgreSQL

DB 종류	상태	프로세스 확인	결과
MySQL/MariaDB
Oracle/PostgreSQL

TC-PM-PRE-005: 현재 접속자 수 확인 (서비스 영향 최소화)

목적: 재기동 전 현재 접속자 수를 확인하여 최적 시간대를 선택합니다.
소요 시간: 약 3분

# 현재 웹 서버 접속 세션 수 확인
# Apache
grep "$(date +%d/%b/%Y)" /var/log/apache2/access.log | wc -l

# Nginx
grep "$(date +%d/%b/%Y)" /var/log/nginx/access.log | wc -l

# 현재 연결 수
ss -s | grep "estab"

항목	현재 값	기록
현재 접속 세션 수
오늘 방문자 수
점검 권장 시간대	새벽 1~5시 권장

💡 팁: 접속자가 거의 없는 시간대(새벽 1~5시)에 재기동을 수행하면 영향이 최소화됩니다.

2단계 — 서버 재기동 수행

TC-PM-REBOOT-001: 서비스 공지 및 사전 알림

목적: 사용자에게 점검 시간을 미리 알립니다.
소요 시간: 약 5분 (점검 1~2일 전 수행)

번호	따라 할 행동	이렇게 되면 통과(O)
1	각 사이트 관리자 화면에서 점검 공지 팝업을 등록합니다	공지 팝업이 등록됩니다
2	공지 내용: `시스템 정기 점검으로 YYYY-MM-DD HH:MM ~ HH:MM 서비스가 중단됩니다.`	공지 내용이 표시됩니다
3	GUARDiA Messenger로 관련 담당자에게 점검 일정 공유	메시지 발송 확인

TC-PM-REBOOT-002: 점검 모드 전환

목적: 서비스 중단 전 점검 페이지로 전환합니다.
소요 시간: 약 5분

각 서버의 웹 서버 설정에 따라 점검 페이지 표시 방법이 다를 수 있습니다.

# Nginx 점검 모드 예시
sudo mv /etc/nginx/conf.d/site.conf /etc/nginx/conf.d/site.conf.bak
sudo cp /etc/nginx/conf.d/maintenance.conf.template /etc/nginx/conf.d/site.conf
sudo nginx -t && sudo systemctl reload nginx

번호	따라 할 행동	이렇게 되면 통과(O)
1	각 서버에 SSH 접속합니다	터미널에 서버 프롬프트가 나타납니다
2	웹 서버에 점검 모드를 적용합니다 (위 예시 참고)	점검 페이지 설정이 적용됩니다
3	브라우저에서 해당 사이트를 열어 점검 페이지가 보이는지 확인합니다	"점검 중" 페이지가 표시됩니다

TC-PM-REBOOT-003: 서버 재기동 수행

목적: OS를 안전하게 재기동합니다.
소요 시간: 서버당 약 5~10분

⚠️ 주의: 재기동 전 아래 체크리스트를 반드시 확인하세요!

재기동 전 최종 체크리스트:

□ 1단계 사전 점검 모두 완료
□ 현재 접속자 수 0명 또는 최소 (새벽 시간대 권장)
□ DB 백업 완료
□ 점검 공지 팝업 활성화 확인
□ 비상 연락망 준비 (담당자 전화번호 옆에 두기)
□ GUARDiA ITSM PM 작업 상태 "진행 중"으로 변경

# Linux 서버 안전 재기동 명령어
sudo shutdown -r +1 "분기 정기 점검으로 1분 후 재기동합니다"
# 또는 즉시 재기동
sudo reboot

# 재기동 취소 (잘못 입력한 경우)
sudo shutdown -c

번호	따라 할 행동	이렇게 되면 통과(O)
1	위 체크리스트를 모두 확인합니다	모든 항목이 체크됩니다
2	서버에서 `sudo reboot` 명령을 실행합니다	SSH 연결이 끊어집니다 (정상)
3	5~10분 후 서버에 다시 SSH 접속을 시도합니다	SSH 접속이 다시 됩니다
4	`uptime` 명령으로 서버 재기동 시간을 확인합니다	재기동된 지 몇 분 안 된 시간이 표시됩니다

재기동 완료 시각: ________

# 재기동 확인 명령어
uptime
# 출력 예시: 02:15:33 up 3 min, 1 user, load average: 0.12, 0.10, 0.04
#                      ↑ "3 min" → 3분 전에 재기동됨을 의미

3단계 — 사후 헬스체크 (Post-PM Health Check)

이 단계가 가장 중요합니다. 재기동 후 모든 서비스가 정상 복구되었는지 확인합니다.

TC-PM-POST-001: 서버 부팅 기본 상태 확인

목적: 서버 OS가 정상적으로 부팅되었는지 확인합니다.
소요 시간: 약 5분

# 1. 부팅 시간 확인
uptime

# 2. 시스템 로그에서 오류 확인
sudo dmesg | grep -i "error\|fail\|critical" | tail -20

# 3. 디스크 마운트 상태 확인
df -h

# 4. 시스템 서비스 실패 항목 확인
sudo systemctl --failed
# → 0 loaded units listed 이면 실패 항목 없음 (정상)

번호	따라 할 행동	이렇게 되면 통과(O)	결과
1	SSH 접속 후 `uptime` 명령 실행	재기동 후 경과 시간이 표시됩니다
2	`sudo dmesg	grep -i error	tail -20` 실행
3	`df -h` 실행하여 디스크 마운트 상태 확인	모든 파티션이 정상 마운트됩니다
4	`sudo systemctl --failed` 실행	실패한 서비스가 0개입니다

오류 발견 시 기록: _______________________________________

TC-PM-POST-002: 데이터베이스 서비스 재기동 확인

목적: 재기동 후 DB가 자동으로 올라왔는지 확인합니다.
소요 시간: 약 5분

# MySQL/MariaDB 상태 확인
sudo systemctl status mysql
# 또는
sudo systemctl status mariadb

# 정상 출력:
# ● mysql.service - MySQL Community Server
#    Active: active (running) since ...

번호	따라 할 행동	이렇게 되면 통과(O)
1	`sudo systemctl status mysql` 명령을 실행합니다	"active (running)" 이 표시됩니다
2	DB가 자동 시작 설정인지 확인합니다: `sudo systemctl is-enabled mysql`	"enabled" 가 출력됩니다
3	DB가 시작되지 않았으면 수동으로 시작합니다: `sudo systemctl start mysql`	시작 후 "active (running)" 확인
4	재기동 전 기록한 DB 상태와 동일한지 비교합니다	동일한 DB 서비스가 동작 중입니다

DB 시작 실패 시 즉시 담당자 연락: 이 경우 다음 단계로 진행하지 마세요.

TC-PM-POST-003: Tomcat/WAS 서비스 재기동 확인

목적: Java WAS(Tomcat)가 자동으로 올라왔는지 확인합니다.
소요 시간: 약 10분

지역N문화(nculture.org)와 통합자료관리(archive.nculture.org)는 Java Tomcat WAS를 사용합니다.

# Tomcat 프로세스 확인
ps -ef | grep tomcat | grep -v grep

# 정상 출력 예시:
# tomcat   12345     1  5 02:15 ?  00:00:45 java -Djava.util.logging.config.file=...

# Tomcat 서비스 상태 (systemd 관리 시)
sudo systemctl status tomcat
sudo systemctl status tomcat9   # Ubuntu에서 tomcat9인 경우

# Tomcat 8080 포트 리스닝 확인
ss -tlnp | grep :8080

번호	따라 할 행동	이렇게 되면 통과(O)	결과
1	`ps -ef	grep tomcat	grep -v grep` 실행
2	`ss -tlnp	grep :8080` 실행	8080 포트가 LISTEN 상태입니다
3	Tomcat이 안 올라왔으면 수동 시작합니다: `sudo systemctl start tomcat`	프로세스가 나타납니다
4	Tomcat 로그에서 "Server startup in" 메시지를 확인합니다	시작 완료 메시지가 있습니다

Tomcat 로그 확인:

# 최근 Tomcat 시작 로그 확인
sudo tail -50 /var/log/tomcat9/catalina.out
# 또는
sudo tail -50 /opt/tomcat/logs/catalina.out

# 정상 시작 메시지 예시:
# INFO: Server startup in [12345] milliseconds

로그 파일 위치: ___________________
시작 완료 메시지 확인 여부: O / X

TC-PM-POST-004: 웹 서버 (Nginx/Apache) 재기동 확인

목적: 웹 서버가 자동 재시작되었고 정상 응답하는지 확인합니다.
소요 시간: 약 5분

# Nginx 상태 확인
sudo systemctl status nginx

# Apache 상태 확인
sudo systemctl status apache2   # Ubuntu
sudo systemctl status httpd     # CentOS

# 포트 80, 443 리스닝 확인
ss -tlnp | grep -E ':80|:443'

번호	따라 할 행동	이렇게 되면 통과(O)	결과
1	`sudo systemctl status nginx` (또는 apache2) 실행	"active (running)" 이 표시됩니다
2	`ss -tlnp	grep :443` 실행	443 포트가 LISTEN 상태입니다
3	`ss -tlnp	grep :80` 실행	80 포트가 LISTEN 상태입니다
4	웹 서버가 미시작 시: `sudo systemctl start nginx`	시작 후 "active (running)" 확인

TC-PM-POST-005: SSL 인증서 유효성 확인

목적: 재기동 후 SSL 인증서가 정상 작동하는지 확인합니다.
소요 시간: 약 5분

# 각 도메인의 SSL 인증서 만료일 확인
# GUARDiA ssl_expiry_check.sh 스크립트 사용
bash /opt/guardia/scripts/ssl/ssl_expiry_check.sh csv.culture.go.kr
bash /opt/guardia/scripts/ssl/ssl_expiry_check.sh www.kccf.or.kr
bash /opt/guardia/scripts/ssl/ssl_expiry_check.sh mng.kccf.or.kr
bash /opt/guardia/scripts/ssl/ssl_expiry_check.sh www.nculture.org
bash /opt/guardia/scripts/ssl/ssl_expiry_check.sh archive.nculture.org

# 출력 예시 (정상):
# {"host":"www.kccf.or.kr","port":443,"days_left":127,"level":"OK",...}

도메인	days_left	level	결과
csv.culture.go.kr
www.kccf.or.kr
mng.kccf.or.kr
www.nculture.org
archive.nculture.org

판정 기준: days_left > 30 이면 O, 7~30이면 △ (갱신 준비), 7 미만이면 X (즉시 갱신)

TC-PM-POST-006: 서비스 포트 전체 점검

목적: 모든 필수 포트가 정상 리스닝 상태인지 한 번에 확인합니다.
소요 시간: 약 5분

# 서비스 포트 전체 확인
ss -tlnp | grep -E ':80|:443|:8080|:3306|:5432'

# 결과에서 확인할 포트:
# :80    → HTTP (웹서버)
# :443   → HTTPS (웹서버 보안)
# :8080  → Tomcat WAS
# :3306  → MySQL/MariaDB
# :5432  → PostgreSQL (사용 시)

포트	서비스	LISTEN 여부	결과
80	HTTP 웹서버
443	HTTPS 웹서버
8080	Tomcat WAS
3306	MySQL/MariaDB

모든 포트가 LISTEN 상태여야 O 입니다. 하나라도 없으면 X로 기록 후 담당자 연락.

4단계 — 전면 서비스 최종 확인 (Web 화면 직접 확인)

이 단계는 브라우저로 직접 확인합니다.
서버 명령어를 몰라도 수행 가능합니다.