Davi's Devlog

Appearance

0. 이 챕터의 목적 ​

본 챕터는 핸드북 전반에 걸쳐 반복 사용되는 양식(template)을 통합 제공한다. 각 양식은 복사해서 바로 쓸 수 있도록 설계되었다.

0.1 양식 목록 ​

#양식1차 용도본 챕터 §
1자원 생성 요청서신규 VM·스토리지·네트워크 자원 생성 시§2
2VM 처분 제안서처분 대상 VM의 소유자 확인 요청§3
3작성자 추적 리포트작성자 미상 자원의 체계적 추적§4
4WorkLog 작성 가이드개별 작업의 종적 기록 표준화§5
5STN 복기 템플릿STN 당일/사후 복기 (챕터 09 §4.1 정제)§6
6정찰 베이스라인 카드주간 클러스터 상태 스냅샷§7
7이상 상태 보고서정찰 중 이상 발견 보고§8
8개발팀/운영팀 협의 의제 템플릿P0·P1 항목의 팀 간 협의§9
9위험 평가 카드 (격자 매트릭스)개별 작업 전 자가 평가§10
10비상 사고 보고서Level 3 비상 중단 후§11
11신규 테스터 온보딩 체크리스트팀 합류 시 핸드북 학습 순서§12

0.2 양식 사용 원칙 ​

  • 각 양식은 마크다운 코드 블록 안에 복사 가능한 형태로 제공
  • 각 양식 앞에 "언제 쓰는가 / 어떤 정보가 필수인가 / 관련 챕터" 메타 정보 명시
  • 실제 양식 작성 시 v3 마스킹 정책 준수 (masking-policy-v3.md §1)
  • 양식 변경·신설은 본 챕터를 갱신 후 사용

0.3 본 챕터가 해결하는 문제 ​

핸드북 01~08을 작성하면서 각 챕터 §6에 비슷한 양식이 반복 등장했다:

  • 챕터 02 §6.2 "노드 이상 상태 보고서"
  • 챕터 03 §6.3 "스토리지 이상 보고서"
  • 챕터 05 §6.2 "네트워크 이상 보고서"
  • 챕터 06 §6.2 "VM 처분 제안서"
  • 챕터 07 §6.2 "작성자 추적 리포트"
  • 챕터 09 §4.1 "STN 복기 템플릿"

양식의 대부분 공통 구조는 "대상·현황·제안·격자·후속" 5요소. 본 챕터에서 이 구조를 일반화하고, 각 챕터 양식은 본 챕터의 변형 또는 참조로 통합한다.

1. 양식 공통 요소 ​

모든 양식이 공유하는 구성 요소:

요소의미예시
제목·메타문서 유형·일자·작성자# VM 처분 제안 — 2026-04-26
대상양식이 다루는 자원·사건VMID, 스토리지명, 노드명
현황관측 가능한 사실상태, 이력, 사용량
판단본 양식 작성자의 해석근거와 함께
제안수행할 조치체크박스 가능
격자Blast Radius × Reversibility§10 참조
후속합의·후속 기한응답 요청일

각 양식은 이 공통 요소를 자기 목적에 맞게 구체화한 것.

2. 양식 1 — 자원 생성 요청서 ​

2.1 언제 쓰는가 ​

  • 새 VM 생성 시 (권장)
  • 새 스토리지 등록 시 (L2 이상이면 필수)
  • 새 iSCSI target 추가 시 (필수)
  • Cluster 설정 변경 시 (필수)

2.2 양식 ​

markdown
# 자원 생성 요청서 — YYYY-MM-DD

## 요청자
- 이름: (작성자)
- 역할: (testerX / PL / TA / admin)

## 자원 정보
- 유형: [ ] VM  [ ] 스토리지  [ ] 네트워크  [ ] 기타(___)
- 이름 (예정): ___
  - test 포함 여부: [ ] 포함 [ ] 미포함
  - 포함 미포함의 근거: ___
- 노드: ___ (또는 해당 없음)
- VMID 또는 식별자: ___

## 용도
- 주 용도: ___
- 테스트 시나리오: ___
- 예상 수명: [ ] STN 기간만  [ ] 1주 이상  [ ] 무기한

## 자원 사양
### VM인 경우
- CPU: N cores / M sockets
- Memory: NNN MiB
- 디스크: {storage}:{size}GiB × N
- 네트워크: vmbr{0/1/2} × N
- OS: ___
- Cloud-init 사용 여부: [ ] 예  [ ] 아니오
  - ciuser: ___ (v3: 회사명 파생어 금지)

### 스토리지인 경우
- 유형: [ ] LVM  [ ] LVM-Thin  [ ] ZFS  [ ] Directory  [ ] iSCSI  [ ] NFS
- 용량: NNN GiB
- 공유 여부: [ ] shared  [ ] local
- 노드 바인딩: ___

## 격자 평가
- Blast Radius: L__
- Reversibility: R__
- 단독 수행 가능? [ ] Yes  [ ] No (사유: ___)

## 다른 자원에 미치는 영향
- 저장소 사용 증가: NNN GiB
- 네트워크 트래픽 증가: 평면 ___ (예상)
- 다른 테스터 자원과 이름 충돌 없음 확인: [ ] 확인

## 생성 후 자가 점검
- [ ] 이름 규약 준수 (`{vmid}-test-{testerID}-{용도}`)
- [ ] 네트워크 기본값 vmbr1 (vm 평면) 확인
- [ ] description·comment에 HTML 태그 없음
- [ ] tags에 `test-YYYY-MM-DD` 또는 `{testerID}` 포함

## 승인 (L3 이상의 경우)
- 승인자: ___
- 승인일시: ___

2.3 사용 예시 ​

챕터 06 §2.6.1의 "처분 가능 VM 24건"을 보면, 명명 규약 미준수 VM이 다수 있다. 본 양식은 그런 누적을 방지하기 위한 사전 필터. 작성 자체가 품질 확인 단계.

3. 양식 2 — VM 처분 제안서 ​

3.1 언제 쓰는가 ​

  • 처분 대상 VM의 소유자 확인 요청 시
  • 소유자 불명 VM의 Slack 질의 전 준비용
  • 처분 결정의 사후 기록 (복기 자료)

3.2 양식 ​

markdown
# VM 처분 제안 — YYYY-MM-DD

## 대상 VM
- VMID: ___
- 이름: ___
- 노드: ___
- 현재 상태: [ ] running  [ ] stopped  [ ] template  [ ] migration 중단
- 디스크 정보: {storage}:{path}  ({size}GiB)
- 네트워크: vmbr{N}
- 작성 시각 (ctime): YYYY-MM-DD HH:MM
- 마지막 편집 (mtime): YYYY-MM-DD HH:MM

## 처분 근거 체크
- [ ] test 규칙: 이름에 `test` 포함
- [ ] 장기 방치: N일 이상 stopped 또는 running but idle
- [ ] 작성자 확인: [ ] 완료 (___)  [ ] 미상 → 추적 리포트 (양식 3) 참조
- [ ] 리소스 사용: CPU ___, Mem ___, Disk ___
- [ ] HA 등록: [ ] 없음  [ ] 있음 (state: ___)
- [ ] Snapshot 보유: [ ] 없음  [ ] 있음 (수: N, 가장 오래된: ___)
- [ ] 마이그레이션 제약: [ ] 없음  [ ] 있음 (사유: ___)

## 제안 조치
- [ ] 즉시 삭제 (L1~L2 또는 소유자 합의 완료)
- [ ] 정지 후 N일 대기 (소유자 응답 없으면 삭제)
- [ ] 다른 스토리지·노드로 이전 (사유: ___)
- [ ] 보류 (사유: ___)
- [ ] HA에서 제거 (state ignored → 등록 해제)

## 격자 평가
- Blast Radius: L__
- Reversibility: R__
- 단독 수행 가능? [ ] Yes  [ ] No

## 소유자 확인 상태
- 문의 경로: [ ] Slack 전체  [ ] 개별 DM  [ ] 대면
- 문의 일시: ___
- 답변 기한: ___
- 답변 상태: [ ] 수령 (___)  [ ] 24시간 경과 무응답

## 후속 조치 기록 (수행 후)
- 수행 일시: ___
- 수행 결과: [ ] 성공  [ ] 부분 성공  [ ] 실패 (사유: ___)
- 부가 발견: ___

3.3 본 양식이 필수인 사례 (챕터 06 §7 참조) ​

  • VM 112: 작성자 미상, 3일 고부하 → 본 양식 작성 후 Slack 질의
  • VM 101 bani: admin01이 편집 시도 중 → 본 양식으로 admin01과 합의
  • VM 802: 마이그레이션 중단 8일 → 프로세스 종료 + 디스크 보존 제안

4. 양식 3 — 작성자 추적 리포트 ​

4.1 언제 쓰는가 ​

  • VM·스토리지·iSCSI target의 작성자 미상 시 체계적 추적
  • 챕터 07 §2.9의 실전 절차를 형식화

4.2 양식 ​

markdown
# 작성자 추적 리포트 — {자원 유형} {자원ID}

## 대상 자원
- 유형: [ ] VM  [ ] 스토리지  [ ] iSCSI target  [ ] 기타(___)
- 식별자: ___
- 노드: ___
- ctime (생성 시각): YYYY-MM-DD HH:MM:SS (Unix: NNNNNNNN)
- mtime (마지막 편집): YYYY-MM-DD HH:MM:SS

## 추적 시도 기록

### [1] 설정 파일 mtime 확인
- 파일: `/etc/pve/nodes/{node}/qemu-server/{vmid}.conf`
- mtime: YYYY-MM-DD HH:MM
- 비고: ___

### [2] pvedaemon access log 조회
- 조회 범위: YYYY-MM-DD HH:MM ± 15분 (ctime 또는 mtime 기준)
- 명령: `journalctl -u pvedaemon --since "..." --until "..." | grep -iE "VM {vmid}|qmcreate:{vmid}"`
- 결과:
  - [ ] `<{user}@{realm}>` 확인됨 → 작성자: ___
  - [ ] 해당 시각 로그 없음 (journald 보존 밖)
  - [ ] 로그 있으나 관련 작업 없음

### [3] task log 조회
- 명령: `grep "qmcreate:{vmid}\|qmconfig:{vmid}" /var/log/pve/tasks/index*`
- 결과: ___

### [4] wtmpdb 교차 확인
- 해당 시각 노드 로그인 이력: ___
- 비고: 일반적으로 보존 기간 짧음 (5일 이하)

### [5] HA comment 확인
- `ha-manager config`의 `vm:{vmid}` 블록 comment:
  - [ ] 작성자 명시됨: ___
  - [ ] 없음

### [6] description·notes 확인
- `qm config {vmid} | grep -E 'description|notes'`
- 결과: ___

## 추적 결과
- [ ] 확정: 작성자 ___ (근거: ___)
- [ ] 추정: 작성자 ___ (확률 ___%, 근거: ___)
- [ ] 미상: 다음 단계로 이동

## 다음 단계
- [ ] Slack 전체 질의 발송 (문안 별첨)
- [ ] 24시간 무응답 → 처분 보류 유지
- [ ] 해당 시점 근무자 전원 DM 개별 질의

## Slack 질의 문안 (해당 시)
> 안녕하세요. 아래 {자원 유형}의 작성자를 확인하고 있습니다.
> - 식별자: {vmid / 자원명}
> - 생성일: YYYY-MM-DD
> - 노드: pve-nd0X
> - 현재 상태: ___
> 작성하신 분이 계시면 응답 부탁드립니다. 24시간 내 응답이 없으면
> 처분 보류 상태로 두되, 추가 조치 시 본 메시지에 회신드리겠습니다.

5. 양식 4 — WorkLog 작성 가이드 ​

5.1 언제 쓰는가 ​

  • 단일 작업(프로비저닝, 진단, 복구 등)의 종적 기록
  • 여러 세션에 걸친 문제 해결 과정의 연속 기록
  • 핸드북 본체에 통합하기엔 너무 세밀한 작업 기록

5.2 핸드북과의 관계 ​

핸드북과 WorkLog의 역할 분리 (챕터 07 §0.1 재확인):

축핸드북WorkLog
시야클러스터 전체 상태단일 작업 전 과정
시간수집 시점 스냅샷작업 시작~종료 연속 기록
대상 독자팀 전체·STN 준비자자기 자신·미래의 자기
깊이계층 간 연결·정책단일 문제의 근본 원인·해결

5.3 양식 — 일반 WorkLog ​

markdown
---
title: "WorkLog — {작업 요약}"
date: YYYY-MM-DD
author: "Davi"
slug: "{작업-slug}-worklog"
series: "CMP Pre-Test WorkLogs"
series_order: N
category: "linux/proxmox/cmp-test/worklog"
tags: [{상황-태그들}]
status: "active"
version: "Proxmox VE 9.1.1"
masking_policy: "v3"
---

## 환경 정보
| 항목            | 값  |
| --------------- | --- |
| 작업 노드       |     |
| Proxmox VE 버전 |     |
| 관련 자원       |     |
| 작업 시작       |     |
| 작업 종료       |     |

## 0. 이 워크로그의 목적
(무엇을 하려고 했는가, 왜 이 기록이 필요한가)

## 1. 배경 개념
(독자가 이해하기 위해 필요한 최소 배경)

## 2. 초기 상태
(작업 시작 시점의 시스템 상태)

## 3. 작업 과정
(시간 순 또는 논리적 순서로 구체 기술)

### 3.1 {서브 단계}
명령 + 결과 + 해석

### 3.2 {서브 단계}
...

## 4. 문제 발생 (있을 경우)
(작업 중 발생한 예기치 못한 상황)

### 4.1 증상
### 4.2 진단 과정
### 4.3 근본 원인
### 4.4 해결 절차

## 5. 잔여 과제
(본 작업 범위 밖이지만 인지된 관련 과제)

## 6. CMP 설계 관점 (선택)
(본 작업 경험에서 CMP가 자동화해야 할 항목)

## 7. 데이터 원본
(인용된 명령의 타임라인 — 챕터 07 §6.2 참조)

## 8. 잔여 정비·추적 항목 (표)
| # | 항목 | 인계 대상 | 우선순위 | 상태 |

## 9. 교훈 요약 (부록)
| 교훈 | 근거 § |

5.4 WorkLog 특수 유형들 ​

특정 목적의 WorkLog는 위 일반 양식을 변형.

유형변형 포인트
프로비저닝 워크로그§3에 단계별 설계 결정 명시, §4 대신 §5에 설계 반전 기록
진단 워크로그§4를 §3 전에 배치 (문제 → 진단 → 해결 순)
복기 워크로그§6에 STN·사건 반성, §8의 교훈이 핵심
계획 워크로그§3 대신 계획 수립 기록, 실행은 후속 WorkLog로

5.5 WorkLog 파일명 규칙 ​

markdown
worklog-YYYY-MM-DD-{간결한-주제}.md

예:

  • worklog-2026-04-24-iscsi-multi-storage-provisioning.md
  • worklog-2026-05-01-vm-112-owner-investigation.md
  • worklog-2026-05-03-stn-day1-review.md

날짜는 작업 시작일 기준. 한 작업이 여러 날에 걸치면 -continued-{N} 접미사 사용.

6. 양식 5 — STN 복기 템플릿 ​

챕터 09 §4.1의 복기 템플릿을 본 챕터로 이관. 중복 방지.

6.1 본 양식의 위치 ​

챕터 09 §4.1 복기 템플릿은 본 챕터 §6을 참조하는 것으로 정리. 중복 제거.

6.2 양식 ​

markdown
---
title: "WorkLog — STN Day-N 복기"
date: YYYY-MM-DD
author: "Davi"
series: "CMP Pre-Test WorkLogs"
category: "linux/proxmox/cmp-test/worklog/stn-review"
tags: [stn, review, postmortem]
masking_policy: "v3"
---

## 0. STN 기본 정보
- 일자: YYYY-MM-DD
- 시간: HH:MM ~ HH:MM (총 NhN분)
- 참여 테스터: {목록}
- 테스트 영역: {CMP 기능 또는 시나리오}

## 1. 계획 대비 실제
### 1.1 계획한 것
### 1.2 실제로 한 것
### 1.3 차이와 사유

## 2. P0 5건의 해소 상태 (챕터 08 §5.1 기준)
| 항목            | 당일 아침 | 진입 시 | 종료 시 |
| --------------- | --------- | ------- | ------- |
| P0-A 링크 속도  |           |         |         |
| P0-B CMP 라우팅 |           |         |         |
| P0-C NFS alias  |           |         |         |
| P0-D iSCSI 유령 |           |         |         |
| P0-E VM 112     |           |         |         |

## 3. 헬스 체크 이상 발견
### 3.1 STAGE 1~3 (챕터 09 §2) 이상 신호
### 3.2 30분 주기 체크에서의 이상

## 4. 새로 발견된 리스크
| # | 발견 | 격자 (L×R) | 우선순위 | 인계 |

## 5. 붉은 선 위반 여부
- [ ] 전면 금지 항목 위반 없음
- [ ] 합의 필수 항목은 모두 사전 합의 거침
- 사전 합의 없이 수행된 중요 작업: ___

## 6. CMP 기능 검증 결과
### 6.1 성공한 시나리오
### 6.2 실패한 시나리오 (재현 여부 포함)
### 6.3 설계 제안 도출

## 7. 다음 STN까지의 조치
| # | 항목 | 담당 | 기한 |

## 8. 핸드북 갱신 필요 항목
- 챕터 ___ §___: ___

## 9. 비상 상황 복기 (해당 시)
### 9.1 감지 경로
### 9.2 근본 원인
### 9.3 파급 범위
### 9.4 복구 과정 (시간대별)
### 9.5 재발 방지

7. 양식 6 — 정찰 베이스라인 카드 ​

7.1 언제 쓰는가 ​

  • 주간 클러스터 상태 스냅샷 (금요일 저녁 권장)
  • STN 회차 간 비교 기준
  • 핸드북의 데이터 객관적 근거

7.2 양식 (주간 요약) ​

markdown
# 클러스터 베이스라인 카드 — YYYY-MM-DD (주간 요약)

## 1. 클러스터 상태
- 정족수: [ ] OK ({투표/총})  [ ] 이상
- 노드: N/N online
- 마지막 설정 변경: YYYY-MM-DD HH:MM (`config_version`: N)

## 2. 노드별 가동·부하
| 노드 | Uptime | Load (1/5/15) | Mem % | Disk IO (주간 peak) |
| ---- | ------ | ------------- | ----- | ------------------- |

## 3. 네트워크 상태
### 3.1 5노드 링크 속도
| 노드 | enp3s0 | enp4s0 | enp10s0/9s0 | enp13s0/12s0 |

### 3.2 5노드 간 mgmt ping RTT
(표)

### 3.3 iSCSI 세션 분포
| 노드 | 세션 수 | storage 평면 | mgmt 평면 (⚠) |

## 4. VM 인벤토리 요약
- 총 VM: N (test 포함 M, 없음 K)
- 템플릿: N
- HA 등록: N
- Snapshot 보유 VM: N

## 5. 로그 시스템
- /var/log/journal 총 용량: 각 노드
- 지난 7일 ERROR 누적: 각 노드
- 지난 7일 OOM 이력: 각 노드

## 6. 주간 변화 (전주 대비)
- 신규 VM: N
- 삭제 VM: N
- 신규 스토리지: N
- 변경된 storage.cfg 항목: ___

## 7. 다음 주 주시 항목
- (현재 추세가 계속되면 임계 도달 예상 항목)

8. 양식 7 — 이상 상태 보고서 ​

8.1 언제 쓰는가 ​

  • 정찰 중 이상 관찰 시 즉시 보고
  • 대응이 필요하나 Level 1 수준일 때
  • 챕터 02/03/05/07의 각 §6.2 형식 통합

8.2 양식 ​

markdown
# 이상 상태 보고 — YYYY-MM-DD HH:MM

## 발견 경위
- 발견자: ___
- 발견 시각: YYYY-MM-DD HH:MM
- 발견 명령 또는 경로: ___

## 이상 내용
- 대상 (노드/VM/스토리지/네트워크/로그): ___
- 현상: (구체 관찰 내용)

### 인용된 출력 (v3 마스킹 적용)
\`\`\`
(명령 출력 그대로, 마스킹 처리 후)
\`\`\`

## 정상 패턴과의 차이
- 예상값: ___
- 실제값: ___
- 편차: ___

## 추정 원인
- 1차 추정: ___
- 배제된 원인: ___

## 영향 범위
- 즉시 영향: ___
- 잠재 영향: ___
- 격자 평가: L__ × R__

## 수행한 조치
- (있다면, 없다면 "조치 없음, 관찰만")

## 제안 조치
- [ ] 단독 수행 가능
- [ ] 합의 필요 (대상: ___)
- [ ] 운영팀·개발팀 인계
- [ ] 추가 관찰

## 관련 챕터·WorkLog
- 핸드북 챕터 ___ §___
- WorkLog: ___

## 추적 상태
- [ ] 신규
- [ ] 조치 중
- [ ] 조치 완료 (일시: ___)
- [ ] 다음 주간 재평가 대기

9. 양식 8 — 개발팀/운영팀 협의 의제 템플릿 ​

9.1 언제 쓰는가 ​

  • P0·P1 항목 중 타팀 협의 필요 건
  • 챕터 04 (보류된 스토리지 자원 관리) 작성 시 의제
  • 정기 협의 회의의 표준화

9.2 양식 ​

markdown
# 협의 의제 — YYYY-MM-DD

## 협의 대상
- 팀: [ ] 개발팀  [ ] 운영팀  [ ] 양측
- 예상 참석자: ___
- 회의 형태: [ ] 오프라인  [ ] Slack huddle  [ ] 화상

## 의제 1 — {제목}

### 1.1 배경
(현상, 왜 문제가 되는지, 최근 변화)
관련: 핸드북 챕터 ___ §___

### 1.2 질문 사항 (타팀에게)
- [ ] ___
- [ ] ___

### 1.3 제안 사항 (우리 팀에서)
- 제안 A: ___
- 제안 B: ___
- 각 제안의 예상 소요·위험

### 1.4 결정 필요 시점
- 최소 결정 기한: YYYY-MM-DD (이후 STN 지연 가능)

## 의제 2 — ...

## 협의 후 기록 (회의 후 작성)
- 합의 내용: ___
- 후속 조치:
  - 우리 팀: ___
  - 타팀: ___
- 다음 협의 일정: ___

9.3 실사용 예시 (2026-04-25 기준 개발팀 협의 의제) ​

챕터 08 §5.1의 P0-B "CMP 요청 nd01 집중"을 의제로 쓰면:

  • 질문: 5노드 CMP 실행은 분산 설계인가, 의도된 집중인가, 미구현 상태인가?
  • 제안 A: 5노드 분산이 설계 의도면 → 로드밸런서 또는 DNS RR 도입 필요
  • 제안 B: 집중 설계 의도면 → HA는 active-passive로 재정의 필요
  • 제안 C: 현재 상태가 구현 미완이면 → 일정 확인
  • 결정 기한: STN 전 (3일 이내)

이 양식이 챕터 08 §5.1 P0-B를 단순한 항목에서 실행 가능한 의제로 격상시킨다.

10. 양식 9 — 위험 평가 카드 (격자 매트릭스) ​

10.1 언제 쓰는가 ​

  • 단일 작업 수행 전 자가 평가
  • 본 양식 없이 수행한 작업이 사고로 이어진 후의 반성용
  • 경험 누적 후 표준 평가 감각 체득

10.2 양식 ​

markdown
# 위험 평가 — {작업명}

## 작업 내용
- 명령: `___`
- 대상: ___
- 목적: ___

## Blast Radius (L1~L5)
- [ ] L1: 자기 소유 자원 범위
- [ ] L2: 단일 노드 내 여러 자원
- [ ] L3: 단일 노드 전체 또는 타 테스터 자원
- [ ] L4: 클러스터 다수 노드 또는 모든 사용자 영향
- [ ] L5: 외부 시스템 또는 비가역 영향

판단 근거: ___

## Reversibility (R1~R4)
- [ ] R1: 완전 가역 (즉시 원복 가능)
- [ ] R2: 가역이지만 일정 작업 필요
- [ ] R3: 부분 가역 또는 데이터 일부 손실
- [ ] R4: 비가역

판단 근거: ___

## 격자 조합 → 실행 권한
- L__ × R__ = ___

| 조합                 | 실행 권한              |
| -------------------- | ---------------------- |
| L1×R1                | 즉시 (단독)            |
| L2×R1~R2             | 백업 후 단독           |
| L3 이상 또는 R3 이상 | 합의 필수              |
| L4 또는 R4           | 두 번 확인 + 롤백 계획 |
| L5×R4                | 원칙적 금지            |

## 사전 준비
- [ ] 대상 자원의 현재 상태 기록
- [ ] 백업 또는 snapshot (R2~R3인 경우)
- [ ] 롤백 절차 명시 (R3~R4인 경우)
- [ ] 합의자 확인 (L3 이상)

## 수행 기록 (사후)
- 수행 일시: ___
- 실제 결과: [ ] 예상대로  [ ] 일부 차이 (___)  [ ] 예상 외 (___)
- 복구 필요? [ ] 아니오  [ ] 예 (수행: ___)

10.3 자주 수행하는 작업의 사전 등록 격자 ​

팀 내에서 자주 수행되는 작업의 격자 값을 미리 합의해 두면 매번 평가할 필요 없음.

작업격자실행 권한
qm config {vmid} (조회)L1×R1즉시
qm start/stop {vmid} (본인 VM)L1×R1즉시
qm snapshot {vmid}L1×R2즉시 (용량 여유 확인)
qm rollback {vmid}L1×R3확인 절차 필수 (비가역적 시점 되돌림)
qm destroy {vmid} (본인 VM)L1×R42회 확인
qm destroy {vmid} (타인 VM)L3×R4금지 (합의 필요 → L3이지만 R4이므로 실질 금지 수준)
pvesm addL3×R2합의
pvesm removeL3×R3합의 (storage.cfg 블록 삭제, 재등록 시 설정 재작성 필요)
iscsiadm -o delete (본인 target)L1×R2즉시
iscsiadm -o delete (타인 target)L2×R2합의 (§WorkLog 2026-04-24 §4.7 참조)
systemctl restart pvestatdL2×R1즉시
systemctl restart pve-clusterL3×R1합의 (pmxcfs 영향)
pvecm delnode {node}L5×R4금지 (운영팀 공식 승인만)
/etc/corosync/corosync.conf 편집L4×R3운영팀 승인

본 표는 필요에 따라 팀 합의로 확장. 개인 판단과 팀 합의가 충돌하면 팀 합의 우선.

11. 양식 10 — 비상 사고 보고서 ​

11.1 언제 쓰는가 ​

  • 챕터 09 §5.3 Level 3 비상 중단 발생 후
  • OOM, 정족수 이탈, TrueNAS 응답 없음, Call Trace 등

11.2 양식 ​

markdown
# 비상 사고 보고서 — YYYY-MM-DD HH:MM

## 사고 개요
- 발생 시각: YYYY-MM-DD HH:MM:SS
- 감지 시각: YYYY-MM-DD HH:MM:SS (지연: NN초)
- 종결 시각: YYYY-MM-DD HH:MM:SS
- 총 영향 시간: NhNm

## 감지 경로
- [ ] 자동 (헬스 체크 스크립트 — §3)
- [ ] 수동 (테스터 관찰)
- [ ] 외부 보고 (사용자 또는 타팀)
- [ ] 증상: ___

## 사고 유형
- [ ] 정족수 이탈
- [ ] OOM Killer 활성
- [ ] 커널 Call Trace
- [ ] TrueNAS 응답 없음
- [ ] 네트워크 평면 DOWN
- [ ] 기타: ___

## 영향 범위
- 영향받은 노드: ___
- 영향받은 VM: ___ (개수·목록)
- 영향받은 테스터: ___
- 실제 데이터 손실:
  - [ ] 없음
  - [ ] 있음: ___

## 비상 스냅샷
- 저장 경로: `/tmp/stn-emergency-YYYYMMDD-HHMMSS/`
- 포함된 파일 목록: ___

## 시간대별 조치 기록
| 시각  | 액션             | 결과                   | 담당 |
| ----- | ---------------- | ---------------------- | ---- |
| HH:MM | Slack STOP 공유  | 모든 테스터 정지 확인  | ___  |
| HH:MM | 비상 스냅샷 수집 | 완료                   | ___  |
| HH:MM | PL 호출          | 합류                   | ___  |
| HH:MM | 1차 진단         | 원인 좁힘: ___         | ___  |
| HH:MM | 복구 시도        | [ ] 성공 [ ] 실패      | ___  |
| HH:MM | 정상 상태 확인   | 헬스 체크 전 항목 PASS | ___  |

## 근본 원인 분석
- 1차 원인 (직접 트리거): ___
- 2차 원인 (선행 조건): ___
- 3차 원인 (조직·규약): ___

## 재발 방지
| 대응                              | 담당 | 기한 |
| --------------------------------- | ---- | ---- |
| 붉은 선 목록 갱신 (§1)            |      |      |
| 체크리스트 §2·§3 갱신             |      |      |
| 챕터 08 리스크 매트릭스 항목 추가 |      |      |
| 헬스 체크 스크립트 개선           |      |      |

## 사후 교훈
| 교훈 | 근거 |
| ---- | ---- |

## 첨부
- 비상 스냅샷 tar.gz (있다면)
- 관련 로그 발췌
- Slack 채널 로그

11.3 본 보고서 작성 후 처리 ​

  1. WorkLog 시리즈에 저장
  2. 팀 전체 공유 (Slack 채널)
  3. 핸드북 챕터 08 §7 "새로 식별된 리스크"에 항목 추가
  4. 다음 주간 베이스라인 카드 §7에 주시 항목 추가

12. 양식 11 — 신규 테스터 온보딩 체크리스트 ​

12.1 언제 쓰는가 ​

  • 팀에 새 테스터 합류 시
  • 기존 테스터의 핸드북 학습 순서 확인

12.2 양식 ​

markdown
# 신규 테스터 온보딩 — {이름}

## 기본 정보
- 이름 (마스킹 후): tester___
- 합류일: YYYY-MM-DD
- 주 담당: ___

## 1주차 — 환경 이해
- [ ] 챕터 00 (핸드북 개요) 정독
- [ ] 챕터 08 §3 (붉은 선) 숙지 — 출력본 서명
- [ ] 마스킹 정책 v3 숙지 — 실명·회사명 작성 금지 원칙
- [ ] 본인의 계정 생성 (`test_{ID}@pve`)
- [ ] 본인의 테스트 영역 노드 합의 (§자원 격리 §4.1 참조)
- [ ] 본인의 VMID 대역 합의 (가능 시)

## 2주차 — 실무 시작
- [ ] 챕터 01~03 (클러스터·노드·디스크) 정독
- [ ] 첫 VM 생성 — 자원 생성 요청서 (양식 1) 작성 후
- [ ] 첫 WorkLog 작성 (양식 4)
- [ ] 헬스 체크 스크립트 직접 실행 (§챕터 09 §2.2)

## 3주차 — 챕터별 정찰
- [ ] 챕터 04~07 정독 (네트워크·VM·로그)
- [ ] 본인 담당 영역 정찰 1회 수행
- [ ] 베이스라인 카드 (양식 6) 1건 작성

## 4주차 — 자립
- [ ] 챕터 09 (Pre-test 체크리스트) 정독
- [ ] 챕터 10 (본 문서) 정독
- [ ] 격자 평가 (양식 9) 자가 수행 3건 기록
- [ ] 첫 STN 참여
- [ ] STN 복기 (양식 5) 작성

## 확인
- 온보딩 멘토: ___
- 최종 확인 일자: ___
- 비고: ___

13. 양식 간 관계 ​

본 챕터의 양식들은 서로 참조·연쇄된다. 주요 흐름:

markdown
    [자원 생성 요청서 §2]       ← 첫 단추
              ↓
          자원 사용
              ↓
      [베이스라인 카드 §7]       ← 주간 관찰
              ↓ (이상 발견 시)
     [이상 상태 보고서 §8]       ← Level 1
              ↓ (Level 2~3 격상)
      [비상 사고 보고서 §11]
              ↓
    [협의 의제 §9 — 타팀 인계]


    [VM 처분 제안서 §3]          ← 처분 흐름
              ↓
    [작성자 추적 리포트 §4]
              ↓
         Slack 질의
              ↓
         처분 수행
              ↓
      [WorkLog §4 기록]


    [STN 진행]                   ← STN 흐름
         ↓ (9§2 체크 실행)
    [STN 복기 §5]
         ↓ (새 리스크 발견 시)
    챕터 08 매트릭스 갱신

양식 5·8·9·11이 자주 함께 쓰이는 관계. 양식 1·2·3·4는 생성·처분 흐름.

14. 본 챕터에서 발견된 추가 항목 ​

#항목우선순위
14.1양식을 JSON/YAML schema로도 제공 (기계 판독용)P3
14.2양식 사용 이력 추적 (Slack thread 링크 누적)P3
14.3양식 간 자동 교차 참조 시스템 (링크 자동 갱신)P3
14.4STN 규모 확장 시 양식 확장 여지 (10명 이상 팀)P3

본 챕터는 현재 5명 팀 규모에 최적화되어 있다. 팀 확장 시 양식 간소화가 필요할 수 있다.

15. 본 챕터에서 인지한 양식의 한계 ​

15.1 양식은 판단을 대체하지 못한다 ​

양식은 판단의 일관성과 기록의 완전성을 돕지만, 판단 자체를 대신하지 못한다. 각 항목을 체크박스로 채우는 것이 곧 "잘 수행한 것"이 되지 않는다.

양식의 진짜 가치는:

  1. 누락 방지: 중요한 체크 항목을 잊지 않게 함
  2. 기록 표준화: 시간 지난 후 다시 볼 때 일관된 구조로 이해 가능
  3. 공유 원활: 팀원 간 양식이 일치하면 교차 참조·인수인계가 쉬움
  4. 사후 분석: 여러 사건의 패턴을 양식 구조로 비교 가능

이 4가지가 달성되면 양식의 역할 끝. 양식 작성 자체가 판단 책임을 면제하지 않는다.

15.2 양식 과잉의 반작용 ​

  • 양식 작성에 시간이 많이 들면 실제 작업 시간이 줄어든다
  • 양식이 많아지면 어떤 양식을 써야 할지 판단하는 데 시간 소비
  • 양식이 형식적으로 채워지면 "작성했다"는 사실만 남고 내용 가치는 0

본 챕터의 11종 양식은 각기 다른 목적에 최적화되어 설계. 모두를 매번 쓸 필요 없음. 필요한 양식만 선택하는 감각도 학습 사항.

부록 A. 양식 Quick Reference ​

markdown
        사전 / 계획     |         사후 / 기록
  ───────────────────┼─────────────────────
  §2  자원 생성 요청서     §5  STN 복기 템플릿
  §3  VM 처분 제안서       §7  이상 상태 보고서
  §4  작성자 추적 리포트    §10 비상 사고 보고서
  §9  협의 의제 템플릿     §11 온보딩 체크리스트
  §10 위험 평가 카드
                       §7  베이스라인 카드 (주기)
  §4  WorkLog 작성 가이드 (연속 기록)

부록 B. 본 챕터에서 통합되어 사라진 양식 ​

본 챕터 완성 후 다음 중복 양식은 본 챕터의 참조로 간소화 권고:

  • 챕터 02 §6.2 노드 이상 상태 보고서 → 본 챕터 §8
  • 챕터 03 §6.3 스토리지 이상 보고서 → 본 챕터 §8
  • 챕터 05 §6.2 네트워크 이상 보고서 → 본 챕터 §8
  • 챕터 06 §6.2 VM 처분 제안서 → 본 챕터 §3
  • 챕터 07 §6.2 작성자 추적 리포트 → 본 챕터 §4
  • 챕터 09 §4.1 STN 복기 템플릿 → 본 챕터 §6

각 챕터의 §6은 본 챕터 참조 링크만 남기는 것으로 간소화 가능. 단 본 핸드북은 이미 v2 상태로 확정됐으므로 소급 수정은 하지 않고, 향후 갱신 시 자연 반영.

부록 C. 참고 자료 ​

주제본 핸드북 참조
격자 매트릭스챕터 08 §1 / 부록 A
붉은 선챕터 08 §3, 챕터 09 §1
WorkLog 시리즈 원칙챕터 07 §0.1, §7.1
마스킹 정책 v3masking-policy-v3.md
STN 체크리스트챕터 09 전체
주제외부 링크
Postmortem Template (Google SRE)https://sre.google/workbook/postmortem-culture/
Runbook vs Playbook 개념https://www.pagerduty.com/resources/learn/what-is-a-runbook/
Incident Report 구조https://response.pagerduty.com/after/post_mortem_process/

다음 단계: 본 챕터 이후 04-storage-resource-management.md 작성 (개발팀 협의 성사 시) 또는 첫 STN 수행 후 WorkLog 시리즈 확장. 핸드북 본 시리즈(01~10)는 본 챕터로 1차 완결된다.