26M5b
Cloud Native Data Lakehouse SRE — PIR 체계 전체 설명
1. PIR 체계의 목적과 철학
PIR의 핵심 원칙: Blameless (무결책 문화)
"장애는 사람의 실수가 아니라
시스템과 프로세스의 취약점이 드러난 것"
→ 개인을 탓하지 않고
→ 시스템/프로세스/자동화 부족을 찾아내
→ 반복 장애를 구조적으로 차단PIR이 달성해야 할 3가지
① 철저한 원인 분석 → "왜 일어났나"를 뿌리까지 파헤침
② 재발 방지 → 액션아이템으로 실질적 개선
③ 조직 학습 → 팀 전체가 장애에서 배움2. 전체 PIR 라이프사이클
[장애 발생]
↓
① Incident 선언 및 대응 (On-call)
↓
② 복구 완료
↓
③ PIR 작성 (24~48시간 이내)
↓
④ PIR 리뷰 미팅 (48~72시간 이내)
↓
⑤ 액션아이템 등록 (Jira)
↓
⑥ 액션아이템 추적 및 완료
↓
⑦ PIR 종결 (Closed)
↓
⑧ 월간/분기 PIR 트렌드 분석
↓
⑨ 인프라/프로세스 개선 반영
↓
[다음 장애 예방]3. 심각도(Severity) 체계
Lakehouse 환경 특성에 맞게 정의합니다.
┌──────┬────────────────────────────────┬──────────────┬──────────────┐
│ SEV │ 정의 │ PIR 작성기한 │ 리뷰 기한 │
├──────┼────────────────────────────────┼──────────────┼──────────────┤
│ SEV1 │ 전체 플랫폼 다운 │ 24시간 이내 │ 48시간 이내 │
│ │ 데이터 유실 발생 │ │ │
│ │ 전체 사용자 영향 │ │ │
├──────┼────────────────────────────────┼──────────────┼──────────────┤
│ SEV2 │ 핵심 서비스 부분 장애 │ 48시간 이내 │ 72시간 이내 │
│ │ (StarRocks/Spark/MinIO 중 하나)│ │ │
│ │ 일부 사용자 영향 │ │ │
├──────┼────────────────────────────────┼──────────────┼──────────────┤
│ SEV3 │ 비핵심 서비스 장애 │ 72시간 이내 │ 1주일 이내 │
│ │ 성능 저하 (SLO 위반) │ │ │
│ │ 소수 사용자 영향 │ │ │
├──────┼────────────────────────────────┼──────────────┼──────────────┤
│ SEV4 │ 경미한 이슈 │ 선택 │ 선택 │
│ │ 사용자 영향 없음 │ │ │
└──────┴────────────────────────────────┴──────────────┴──────────────┘Lakehouse 특화 SEV1 판단 기준
MinIO AIStor 전체 접근 불가 → SEV1
Milvus 데이터 손상 → SEV1
CNPG Primary 장애 + Failover 실패 → SEV1
Kafka 메시지 유실 → SEV1
K8s Control Plane 다운 → SEV1
StarRocks FE(Frontend) 전체 다운 → SEV2
Spark Job 전체 실패 → SEV2
JupyterLab 접속 불가 → SEV34. PIR 문서 구조 (Confluence 상세)
문서 상단 메타데이터 (Page Properties)
┌──────────────────┬────────────────────────────────────────┐
│ PIR ID │ PIR-2025-003 │
│ 인시던트 제목 │ MinIO AIStor 클러스터 전체 접근 불가 │
│ 심각도 │ SEV-1 │
│ 상태 │ Draft → Review → Closed │
│ 발생 일시 │ 2025-03-05 14:23 KST │
│ 감지 일시 │ 2025-03-05 14:31 KST (감지 지연 8분) │
│ 복구 일시 │ 2025-03-05 16:45 KST │
│ TTD │ 8분 (Time to Detect) │
│ TTR │ 2시간 22분 (Time to Restore) │
│ 영향 서비스 │ Spark, StarRocks, JupyterLab, Airflow │
│ 영향 사용자 수 │ 약 80명 │
│ 데이터 유실 │ 없음 / 있음 (상세 명시) │
│ SLO 위반 여부 │ 가용성 99.9% → 실제 98.2% (위반) │
│ 근본 원인 범주 │ 인프라 / 소프트웨어 / 프로세스 / 외부 │
│ 인시던트 리더 │ @홍길동 │
│ 작성자 │ @홍길동 │
│ 검토자 │ @김영희, @이철수 │
│ 관련 컴포넌트 │ component:minio-aistor, component:k8s │
│ 관련 Jira │ INC-567 │
│ 액션아이템 수 │ 5건 (완료: 2, 진행: 2, 예정: 1) │
└──────────────────┴────────────────────────────────────────┘섹션 1: 요약 (Executive Summary)
## 1. 요약
한 문단으로 비기술직 리더도 이해할 수 있게 작성
"2025년 3월 5일 오후 2시 23분,
MinIO AIStor 스토리지 클러스터에 접근 불가 장애가 발생하여
약 80명의 데이터 분석가 및 엔지니어가
Spark 작업, StarRocks 쿼리, JupyterLab 노트북을
2시간 22분간 사용할 수 없었습니다.
근본 원인은 Cilium BGP 설정 변경 이후
MinIO Pod의 네트워크 정책이 의도치 않게 차단된 것이며,
동일 유형의 재발을 막기 위해 5건의 액션아이템을 수립하였습니다."섹션 2: 타임라인
## 2. 타임라인 (Timeline)
| 시각 (KST) | 경과 | 이벤트 | 담당자 |
|-----------|------|--------|--------|
| 14:23 | 0분 | MinIO 접근 불가 시작 (실제 장애 발생) | - |
| 14:31 | +8분 | Prometheus Alert 발화 → PagerDuty 수신 | 자동 |
| 14:33 | +10분| @홍길동 Incident 선언, Slack #incident 채널 개설 | 홍길동 |
| 14:38 | +15분| MinIO Pod 상태 확인 → Running이나 요청 실패 확인 | 홍길동 |
| 14:45 | +22분| Cilium 로그에서 DROP 패킷 발견 | 김영희 |
| 14:52 | +29분| 당일 오전 Cilium BGP 설정 변경 이력 확인 | 홍길동 |
| 15:10 | +47분| 변경 내역 롤백 적용 시도 | 홍길동 |
| 15:30 | +67분| 롤백 후에도 일부 Pod 미복구 확인 | 전체 |
| 15:45 | +82분| NetworkPolicy 강제 재적용 결정 | 이철수 |
| 16:30 | +127분| 전체 MinIO Pod 정상화 확인 | 홍길동 |
| 16:45 | +142분| 사용자 접속 정상 확인 → Incident 종결 선언 | 홍길동 |
| 17:00 | +157분| 이해관계자 복구 완료 공지 | 이철수 |
※ 감지 지연(8분): Alert 임계값이 너무 높게 설정되어 있었음 → 액션아이템 #1섹션 3: 근본 원인 분석 (RCA — 5 Whys)
## 3. 근본 원인 분석
### 3-1. 직접 원인 (Proximate Cause)
Cilium BGP CiliumNetworkPolicy 변경 시 MinIO 관련
ingress 규칙이 누락되어 외부 트래픽이 차단됨
### 3-2. 5 Whys 분석
Why 1. MinIO에 왜 접근이 안 됐나?
→ Cilium NetworkPolicy가 MinIO Pod의 인바운드 5432 포트를 차단함
Why 2. 왜 NetworkPolicy가 차단했나?
→ 당일 오전 Cilium BGP 설정 변경 시 기존 NetworkPolicy와 충돌하는
새로운 정책이 적용됨
Why 3. 왜 충돌하는 정책이 적용됐나?
→ 변경 전 영향도 검토(Impact Analysis)에서
MinIO NetworkPolicy와의 연관성을 확인하지 않음
Why 4. 왜 영향도 검토가 누락됐나?
→ 작업계획서 템플릿에 "연관 서비스 NetworkPolicy 확인" 항목이 없었음
→ Cilium 설정 변경 시 NetworkPolicy 시뮬레이션 절차가 없었음
Why 5. 왜 시뮬레이션 절차가 없었나?
→ SOP에 Cilium 변경 시 사전 검증 절차가 정의되어 있지 않음
→ 스테이징 환경에서 동일 설정을 검증하는 게이트가 없었음
🎯 근본 원인 (Root Cause)
"Cilium 네트워크 설정 변경 프로세스에
사전 영향도 분석 및 스테이징 검증 단계가 없었음"섹션 4: 영향도 분석
## 4. 영향도 분석
### 서비스 영향
| 서비스 | 영향 유형 | 영향 시간 | 영향 범위 |
|--------|----------|----------|----------|
| MinIO AIStor | 전체 접근 불가 | 142분 | 모든 버킷 |
| Spark | Job 실패 | 142분 | 모든 Job |
| StarRocks | 쿼리 실패 | 142분 | 외부 테이블 |
| JupyterLab | 스토리지 접근 불가 | 142분 | 분석가 전원 |
| Airflow | DAG 실패 | 142분 | 스토리지 의존 DAG |
| CNPG | 영향 없음 | - | - |
### SLO 영향
| SLO | 목표 | 실제 | 위반 여부 |
|----|------|------|---------|
| 가용성 (월간) | 99.9% (43분/월) | 98.2% (142분) | ✅ 위반 |
| TTD | 5분 이내 | 8분 | ✅ 위반 |
| TTR (SEV1) | 1시간 이내 | 2시간 22분 | ✅ 위반 |
### 비즈니스 영향
- 데이터 분석가 80명 × 2.3시간 = 184 인시간 손실
- 배치 파이프라인 지연: 12개 DAG (야간 배치로 순연)
- 데이터 유실: 없음섹션 5: 재발 방지 액션아이템
## 5. 재발 방지 액션아이템
| # | 유형 | 항목 | 담당자 | 기한 | Jira | 상태 |
|---|------|------|--------|------|------|------|
| 1 | 감지 | MinIO 가용성 Alert 임계값 조정 (8분→2분) | @홍길동 | 2025-03-08 | LAKE-1240 | ✅ 완료 |
| 2 | 예방 | Cilium 변경 SOP에 NetworkPolicy 충돌 검토 단계 추가 | @김영희 | 2025-03-15 | LAKE-1241 | 🔄 진행중 |
| 3 | 예방 | 스테이징 환경에서 Cilium 변경 사전 검증 게이트 구축 | @이철수 | 2025-03-31 | LAKE-1242 | 🔄 진행중 |
| 4 | 대응 | Cilium NetworkPolicy 긴급 롤백 Runbook 작성 | @홍길동 | 2025-03-20 | LAKE-1243 | ⏳ 예정 |
| 5 | 탐지 | Hubble을 활용한 Drop 패킷 실시간 대시보드 구성 | @박민수 | 2025-04-15 | LAKE-1244 | ⏳ 예정 |
### 유형 분류
- 감지(Detection): Alert / 모니터링 개선
- 예방(Prevention): SOP / 프로세스 / 자동화
- 대응(Mitigation): Runbook / 훈련
- 복구(Recovery): 자동화 / 도구섹션 6: 잘된 점 / 개선점
## 6. 회고 (Blameless Retrospective)
### 잘된 점 👍
- Slack #incident 채널을 10분 내 개설하여 커뮤니케이션 집중
- Cilium 로그 분석으로 22분 만에 원인 컴포넌트 식별
- 이해관계자에게 15분 간격으로 진행 상황 공유
### 개선이 필요한 점 👎
- Alert 감지가 8분 걸린 것 (목표 2분)
- Runbook이 없어 롤백 판단까지 47분 소요
- 스테이징 환경이 없어 변경 전 검증 불가
### 다음 Incident 때 다르게 할 것
- Cilium 변경 시 Hubble monitor를 먼저 켜놓고 작업
- 롤백 결정 기준을 사전에 작업계획서에 명시5. PIR 리뷰 미팅 운영
준비 (전날까지)
① PIR 초안 작성 완료 → Confluence 공유
② 참석자 전원 사전 읽어오기 의무화
③ 타임라인 오류/누락 확인 요청
미팅 진행 (45분~60분)
[00:00~05:00] 타임라인 확인 및 사실관계 정정
[05:00~20:00] 5 Whys 근본 원인 토론 (가장 중요)
[20:00~35:00] 액션아이템 도출 및 우선순위 합의
[35:00~45:00] 담당자/기한 배정 + Jira 티켓 생성
[45:00~60:00] 잘된 점/개선점 공유 (Blameless)
참석자
- 인시던트 리더 (필수)
- 대응에 참여한 SRE (필수)
- 관련 서비스 담당자 (필수)
- 팀 리드 (필수)
- 이해관계자 (선택)
Rule
❌ "왜 몰랐어요?" 금지
❌ 개인 비판 금지
✅ "시스템/프로세스가 왜 이를 허용했나" 관점6. PIR → 개선 연결 체계
PIR 액션아이템
↓
Jira Task 생성 (담당자/기한/우선순위)
↓
├── 단기 (1~2주): Alert 튜닝, Runbook 작성
│ ↓
│ 해당 SOP/Runbook 페이지 업데이트
│
├── 중기 (1개월): 스테이징 환경 구축, 자동화
│ ↓
│ 작업계획서 작성 → 배포
│
└── 장기 (분기): 아키텍처 개선, 플랫폼 변경
↓
과제 문서 등록 → 분기 OKR 반영7. PIR 트렌드 분석 (월간/분기)
Confluence Page Properties Report + 수동 집계로 아래 뷰를 만듭니다.
월간 PIR 리포트 항목
① 인시던트 발생 수 (SEV별)
SEV1: 1건 / SEV2: 3건 / SEV3: 5건
② 평균 TTD / TTR 추이
[이번 달] TTD: 8분, TTR: 142분
[지난 달] TTD: 5분, TTR: 60분
→ TTR 악화 → 원인 분석 필요
③ 근본 원인 분류 비율 (파레토)
프로세스 부재: 40% ← 가장 많음
설정 변경 실수: 30%
용량 부족: 20%
외부 의존성: 10%
→ 프로세스 개선에 집중 투자 필요
④ 컴포넌트별 장애 빈도
MinIO AIStor: 3건
Cilium: 2건
StarRocks: 1건
→ MinIO 안정화 집중 과제 도출
⑤ 액션아이템 완료율
총 23건 중 완료: 18건 (78%)
기한 초과: 5건 → 담당자 리마인드
⑥ SLO 달성률
가용성: 98.2% (목표 99.9% 미달)
→ 다음 달 집중 개선 목표8. Confluence 구현 시 핵심 팁
① PIR 템플릿 페이지 생성
→ 새 PIR 작성 시 "이 페이지를 복사" 하여 시작
→ Page Properties 항목이 사전 세팅되어 있어야 함
② PIR 대시보드 페이지 (부모 페이지)
→ Page Properties Report 매크로로 자동 집계
→ Status 필터로 "Review 중인 PIR" 만 강조
③ Label 자동화
status:draft → 작성 직후
status:review → 미팅 전
status:closed → 액션아이템 Jira 등록 완료 후
④ Jira 양방향 연동
→ PIR 페이지에 Jira 티켓 링크
→ Jira 티켓에 PIR 페이지 링크
→ Jira 상태 변경 시 PIR 액션아이템 수동 갱신
(또는 Confluence Automation으로 자동화)
⑤ 알림 설정
→ PIR 페이지 Watch 설정 → 수정 시 팀 전원 알림
→ 액션아이템 기한 D-3일에 담당자 Slack 알림
(Confluence Automation 또는 Jira 알림 활용)9. 한눈에 보는 PIR 성숙도 단계
Lv.1 초기
→ 장애 기록은 하지만 형식 없음
→ 원인 분석 피상적
→ 액션아이템 follow-up 없음
Lv.2 정착
→ 표준 템플릿 사용
→ 5 Whys 분석 정기 수행
→ 액션아이템 Jira 등록
Lv.3 개선 (지금 목표)
→ Blameless 문화 정착
→ 월간 트렌드 분석
→ SLO와 연동된 우선순위 결정
→ 액션아이템 완료율 80% 이상
Lv.4 예측 (다음 목표)
→ PIR 트렌드로 장애 예측
→ 카오스 엔지니어링으로 사전 검증
→ 자동 감지 → 자동 완화 (Auto-Remediation)
→ 장애 발생 수 분기 대비 감소 추세핵심: PIR은 문서 작성이 목적이 아니라 액션아이템 완료가 목적입니다. 아무리 잘 쓴 PIR이라도 액션아이템이 방치되면 같은 장애가 반복됩니다. Jira 연동 + 월간 follow-up이 PIR 체계의 실질적인 생명줄입니다.
engineer