26M5c
Cloud Native Data Lakehouse SRE — SOP 체계 전체 설명
1. SOP의 유형 분류
먼저 SOP를 목적별로 분류하는 것이 핵심입니다.
SOP 유형
│
├── 1. Admin SOP 정기적/반복적 운영 절차
├── 2. Runbook SOP 장애 감지 → 대응 → 복구
├── 3. Change SOP 변경/배포/업그레이드 절차
├── 4. Onboarding SOP 신규 구성원/서비스 합류
└── 5. Compliance SOP 보안/감사/정책 준수2. SOP ID 네이밍 체계
문서가 쌓일수록 ID 체계가 없으면 파편화됩니다.
형식: {유형}-{컴포넌트}-{번호}
Admin SOP
ADM-K8S-001 K8s 노드 추가/제거
ADM-MINIO-001 MinIO 노드 교체
ADM-CNPG-001 CNPG 백업 검증
ADM-CILIUM-001 Cilium 업그레이드
Runbook SOP
RB-MINIO-001 MinIO 접근 불가 대응
RB-K8S-001 K8s 노드 NotReady 대응
RB-CNPG-001 CNPG Primary 장애 대응
RB-SPARK-001 Spark Job 전체 실패 대응
RB-CILIUM-001 Cilium NetworkPolicy 차단 대응
Change SOP
CHG-K8S-001 K8s 버전 업그레이드
CHG-MINIO-001 MinIO AIStor 버전 업그레이드
CHG-CILIUM-001 Cilium BGP 설정 변경
Onboarding SOP
OBD-USER-001 신규 분석가 환경 세팅
OBD-SRE-001 신규 SRE 온보딩
OBD-SVC-001 신규 서비스 플랫폼 등록
Compliance SOP
CMP-SEC-001 시크릿 로테이션
CMP-AUDIT-001 분기 감사 로그 검토
CMP-CERT-001 TLS 인증서 갱신3. SOP 유형별 상세 구조
3-1. Admin SOP (정기 운영)
정해진 주기나 특정 조건에서 수행하는 반복 작업입니다.
대상 작업 예시
- 노드 추가/제거/교체
- 정기 백업 검증
- 용량 증설
- 인증서 갱신
- 패치/업데이트
- 모니터링 임계값 조정## [ADM-MINIO-001] MinIO AIStor 노드 교체 절차
### 메타데이터 (Page Properties)
SOP ID: ADM-MINIO-001
버전: v1.3
카테고리: Admin
컴포넌트: component:minio-aistor
주기: 비정기 (하드웨어 장애/증설 시)
예상 소요시간: 2~3시간
필요 권한: K8s Admin, MinIO Admin
다운타임: 없음 (롤링 방식)
작성자: @홍길동
최종 수정일: 2025-03-01
다음 검토일: 2025-09-01
관련 SOP: ADM-K8S-001, RB-MINIO-001
---
## 1. 개요
MinIO AIStor 클러스터에서 물리 노드를 교체하는 표준 절차.
H/W RAID 구성으로 디스크 미러링이 되어 있으며,
MinIO Erasure Coding으로 데이터 보호.
## 2. 사전 조건 체크리스트
- [ ] 교체 대상 노드 확인 (kubectl get nodes)
- [ ] MinIO 클러스터 상태 정상 확인 (mc admin info)
- [ ] 현재 사용 용량 확인 (70% 미만이어야 안전)
- [ ] 작업 시간대 확인 (배치 Job 없는 시간대)
- [ ] 롤백 시나리오 숙지
## 3. 작업 절차
### Step 1. 노드 Drain
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
# 예상 소요: 10~20분
### Step 2. MinIO 데이터 재분산 모니터링
mc admin heal -r myminio/
watch -n 5 'mc admin info myminio | grep -A5 Drives'
### Step 3. 물리 노드 교체 (하드웨어팀 협력)
...
### Step 4. 노드 재합류
kubectl uncordon <node>
### Step 5. 검증
mc admin info myminio # 모든 드라이브 OK
mc ls myminio/test-bucket/ # 읽기 정상
mc cp testfile myminio/test-bucket/ # 쓰기 정상
## 4. 롤백 절차
# 노드 교체 전 단계 → 해당 단계로 복귀
kubectl uncordon <original-node>
## 5. 완료 후 조치
- [ ] Grafana에서 MinIO 대시보드 정상 확인
- [ ] 작업일지 기록
- [ ] 변경된 사항 CMDB 업데이트
## 6. 알려진 이슈
- Drain 시 PDB(PodDisruptionBudget) 설정에 따라 블락될 수 있음
→ kubectl describe pdb -n minio 확인 후 조치
## 7. 변경 이력
| 버전 | 날짜 | 변경 내용 | 작성자 |
|------|------|----------|--------|
| v1.3 | 2025-03-01 | Step 2 모니터링 명령 추가 | 홍길동 |
| v1.2 | 2024-12-01 | 검증 절차 강화 | 김영희 |3-2. Runbook SOP (장애 대응)
장애 발생 시 빠른 판단과 복구가 목적입니다. 일반 SOP보다 간결하고 결정 트리 구조로 작성해야 합니다.
Runbook의 핵심 원칙
"새벽 3시에 장애가 났을 때
반쯤 잠든 SRE가 보더라도
5분 안에 다음 행동을 결정할 수 있어야 한다"
→ 설명 최소화, 명령어 바로 실행 가능하게
→ Yes/No 분기로 판단 지점 명확화
→ 복구 시간 목표(TTR) 명시## [RB-MINIO-001] MinIO AIStor 접근 불가 대응
### 메타데이터
SOP ID: RB-MINIO-001
유형: Runbook
심각도: SEV1 가능
TTR 목표: 60분
컴포넌트: component:minio-aistor
On-call 트리거: Alert "MinIODown" 발화 시
관련 PIR: PIR-2025-003
관련 Runbook: RB-CILIUM-001, RB-K8S-001
---
## ⚡ 즉시 확인 (< 5분)
### 1. 현재 상태 파악
# MinIO Pod 상태
kubectl get pods -n minio -l app=minio
# S3 엔드포인트 응답 확인
curl -I http://minio-svc:9000/minio/health/live
# MinIO 클러스터 전체 상태
mc admin info myminio
---
## 🔍 원인 판별 트리
### MinIO Pod이 Running인가?
YES → [섹션 A] 네트워크/접근 문제
NO → [섹션 B] Pod 기동 문제
---
## [섹션 A] Pod Running이지만 접근 불가
### A-1. Cilium NetworkPolicy 차단 확인
# Drop 패킷 실시간 확인
kubectl exec -n kube-system ds/cilium -- \
cilium monitor --type drop | grep minio
# Drop이 보이면 → RB-CILIUM-001 참조
# Drop 없으면 → A-2로
### A-2. MinIO 내부 오류 확인
kubectl logs -n minio -l app=minio --tail=50
# "Unable to read 'format.json'" → 디스크 손상 → A-3
# "Healing" 메시지 → 자가 복구 중 → 10분 대기 후 재확인
# 로그 정상 → A-4로
### A-3. 디스크/LVM 문제
# 해당 노드에서
lvdisplay dbvg
kubectl get lvmvolume -n minio
# OpenEBS LVM 볼륨 상태 이상 → ADM-MINIO-LVM-001 참조
### A-4. Service/Endpoint 확인
kubectl get svc -n minio
kubectl get endpoints -n minio
# Endpoint 없음 → Pod Label 불일치 가능
kubectl describe svc minio-svc -n minio
---
## [섹션 B] Pod NotRunning
### B-1. Pod 상태 상세 확인
kubectl describe pod <pod-name> -n minio
kubectl logs <pod-name> -n minio --previous
# OOMKilled → 메모리 부족 → 리소스 Limit 조정
# Pending → 노드 리소스 부족 또는 PVC 문제
# CrashLoopBack → 앱 오류 → 로그 확인
### B-2. PVC 상태 확인
kubectl get pvc -n minio
# Pending이면 → OpenEBS LVM 확인
kubectl get lvmvolume -n minio
---
## ✅ 복구 확인
mc admin info myminio | grep -E "Status|Drives"
# 모든 드라이브 OK + 클러스터 상태 online 확인
# 쓰기/읽기 테스트
echo "test" | mc pipe myminio/test-bucket/healthcheck.txt
mc cat myminio/test-bucket/healthcheck.txt
# Grafana MinIO 대시보드 정상 확인
---
## 📢 에스컬레이션
복구 30분 경과 후에도 미복구:
→ 팀 리드 @이철수 호출
→ Slack #incident 채널 상황 공유
데이터 손상 의심 시:
→ 즉시 MinIO 쓰기 차단 (read-only 모드)
→ 팀 리드 + 데이터팀 리드 즉시 호출
mc admin config set myminio/ storage class \
standard=EC:4 # 복구 우선
---
## 📋 완료 후 조치
- [ ] Slack #incident 채널에 복구 완료 공지
- [ ] 타임라인 기록 (PIR 작성용)
- [ ] Alert이 제때 울렸는지 확인
- [ ] 재발 가능성 있으면 PIR 작성 결정3-3. Change SOP (변경/배포)
변경 작업은 장애의 가장 큰 원인입니다. PIR을 보면 대부분 "변경 후 장애"입니다.
Change SOP의 핵심 구조
사전 검증 게이트 → 작업 → 검증 → 롤백 기준 명시## [CHG-CILIUM-001] Cilium BGP 설정 변경 절차
### 핵심 원칙
- 스테이징 환경에서 먼저 검증 (필수)
- NetworkPolicy 영향도 분석 필수
- 롤백 기준 사전 합의 후 작업 시작
## 1. 변경 전 게이트 (Go/No-Go)
- [ ] 스테이징 환경 동일 변경 적용 및 24시간 안정 확인
- [ ] 영향 받는 NetworkPolicy 목록 작성
- [ ] Hubble monitor 모니터링 세션 열어두기
- [ ] 롤백 명령어 사전 준비 및 테스트
## 2. 작업 중 실시간 모니터링
# 별도 터미널에서 Drop 패킷 감시 (작업 내내 유지)
kubectl exec -n kube-system ds/cilium -- \
cilium monitor --type drop
## 3. 롤백 기준 (사전 합의)
아래 중 하나라도 발생 시 즉시 롤백:
- Drop 패킷 발생
- 주요 서비스 헬스체크 실패
- 작업 시작 후 15분 내 정상화 안 되면
...3-4. Onboarding SOP
## [OBD-USER-001] 신규 데이터 분석가 환경 세팅
## 1. K8s 네임스페이스 및 RBAC 생성
kubectl create ns analyst-{이름}
kubectl apply -f rbac/analyst-role.yaml
## 2. Keycloak 계정 생성 및 그룹 배정
→ Keycloak Admin Console에서 수행
그룹: data-analysts
## 3. JupyterHub 프로파일 할당
→ JupyterHub Admin에서 analyst 프로파일 배정
CPU: 4 core / Memory: 8Gi / GPU: 없음
## 4. MinIO 버킷 접근 권한 부여
mc admin policy attach myminio analyst-policy \
--user {사용자명}
## 5. StarRocks 계정 생성
CREATE USER '{사용자명}'@'%' IDENTIFIED BY '{임시비밀번호}';
GRANT SELECT ON *.* TO '{사용자명}'@'%';
## 6. 사용자 안내 메일 발송
→ 템플릿: [OBD-EMAIL-ANALYST-001]
## 7. 완료 확인
- [ ] JupyterLab 접속 확인 (사용자 직접)
- [ ] StarRocks 쿼리 실행 확인
- [ ] MinIO 버킷 읽기 확인3-5. Compliance SOP
## [CMP-CERT-001] TLS 인증서 갱신 절차
주기: 90일마다 (Cert-Manager 자동화되지 않은 경우)
알림: 만료 30일 전 Grafana Alert 발화
## 1. 만료 예정 인증서 확인
kubectl get certificates -A
kubectl get secrets -A | grep tls
## 2. Cert-Manager 자동 갱신 확인
kubectl describe certificate <name> -n <ns>
# "Certificate is up to date" → 완료
# 갱신 실패 시 → 수동 갱신 절차 수행
## 3. 수동 갱신 (자동화 실패 시)
kubectl delete secret <tls-secret>
# Cert-Manager가 자동 재발급
kubectl describe certificaterequest -n <ns>
## 4. 검증
echo | openssl s_client -connect <host>:443 2>/dev/null \
| openssl x509 -noout -dates4. SOP 관리 운영 원칙
버전 관리
SOP는 살아있는 문서 — 반드시 버전 관리
v1.0 최초 작성
v1.1 마이너 수정 (명령어 수정, 누락 항목 추가)
v2.0 주요 변경 (절차 구조 변경, 컴포넌트 대규모 변경)
변경 이력 표를 문서 하단에 필수 유지
모든 버전 변경 시 검토자 승인 필요검토 주기
유형 검토 주기 트리거
Admin SOP 6개월마다 정기 또는 컴포넌트 변경 시
Runbook SOP 3개월마다 PIR 발생 후 즉시 + 정기
Change SOP 변경 발생 시마다 배포/업그레이드 후
Onboarding SOP 분기마다 플랫폼 구조 변경 시
Compliance SOP 1년마다 법규/정책 변경 시검증 방법 (SOP가 실제로 동작하는지)
Runbook SOP 검증 → 카오스 엔지니어링 훈련
월 1회 특정 Runbook을 실제 장애 시나리오에서 실행
"Runbook만 보고 복구할 수 있는가" 측정
→ 불명확한 부분 즉시 개정
Admin SOP 검증 → 체크리스트 실행 후 완료 서명
작업 완료 후 담당자가 Confluence에 완료 기록
→ "실행해보니 이상한 점" 피드백 반영
Change SOP 검증 → 변경 작업 후 회고
작업계획서 완료 후 SOP와 실제 차이 비교
→ 차이 발견 시 SOP 즉시 업데이트5. Confluence 구현 구조
📖 SOP (루트 페이지)
│
├── 📊 SOP 현황 대시보드 ← Page Properties Report
│ 모든 SOP을 자동 집계
│ (만료 임박 SOP 강조)
│
├── 🔧 Admin SOP
│ ├── K8s / Cilium
│ │ ├── ADM-K8S-001 노드 추가
│ │ └── ADM-CILIUM-001 업그레이드
│ ├── MinIO AIStor
│ │ ├── ADM-MINIO-001 노드 교체
│ │ └── ADM-MINIO-002 버킷 정책 관리
│ ├── CNPG
│ ├── StarRocks
│ └── Spark / Airflow
│
├── 🚨 Runbook SOP
│ ├── 플랫폼 장애
│ │ ├── RB-MINIO-001 접근 불가
│ │ ├── RB-K8S-001 노드 NotReady
│ │ ├── RB-CNPG-001 DB Primary 장애
│ │ └── RB-CILIUM-001 NetworkPolicy 차단
│ ├── 데이터 레이어 장애
│ │ ├── RB-SPARK-001 Job 전체 실패
│ │ ├── RB-STARROCKS-001 FE 다운
│ │ └── RB-KAFKA-001 Consumer Lag 급증
│ └── 공통
│ └── RB-ESCALATION-001 에스컬레이션 절차
│
├── 🔄 Change SOP
│ ├── CHG-K8S-001 버전 업그레이드
│ ├── CHG-CILIUM-001 BGP 설정 변경
│ └── CHG-MINIO-001 버전 업그레이드
│
├── 👋 Onboarding SOP
│ ├── OBD-SRE-001 신규 SRE
│ └── OBD-USER-001 신규 분석가
│
└── 🔒 Compliance SOP
├── CMP-CERT-001 인증서 갱신
├── CMP-SEC-001 시크릿 로테이션
└── CMP-AUDIT-001 감사 로그 검토SOP 대시보드 (Page Properties Report)
SOP 현황 대시보드에서 자동 집계되는 뷰
[만료 임박 SOP]
Label: doc-type:sop AND status:approved
정렬: 다음검토일 오름차순
→ 검토 필요한 SOP를 한눈에 파악
[Runbook 커버리지]
Label: doc-type:runbook
컴포넌트별 그룹핑
→ "아직 Runbook 없는 컴포넌트" 식별
[최근 수정된 SOP]
Label: doc-type:sop
정렬: 최종수정일 내림차순
→ 팀원들이 최신 변경사항 빠르게 파악6. SOP와 다른 문서의 연결
장애 발생
↓
Runbook SOP 참조 → 복구
↓
PIR 작성
↓
PIR 액션아이템
├── Runbook SOP 개정 (절차 보완)
├── Admin SOP 추가 (예방 점검 추가)
└── Change SOP 강화 (변경 게이트 추가)
↓
작업계획서 작성 (Change SOP 기반)
↓
작업 완료 → SOP 검증 및 최신화7. 한눈에 보는 SOP 유형별 비교
┌──────────────┬────────────┬──────────────┬───────────┬────────────┐
│ 유형 │ 목적 │ 작성 스타일 │ 주요 독자 │ 검토 주기 │
├──────────────┼────────────┼──────────────┼───────────┼────────────┤
│ Admin SOP │ 정기 운영 │ 단계별 절차 │ SRE │ 6개월 │
│ Runbook SOP │ 장애 복구 │ 결정 트리 │ On-call │ 3개월/PIR후│
│ Change SOP │ 안전한 변경│ 게이트+롤백 │ SRE+팀리드│ 변경 후 │
│ Onboarding │ 합류 지원 │ 순서형 체크 │ 신규 구성원│ 분기 │
│ Compliance │ 보안/감사 │ 단계별 절차 │ SRE+보안팀│ 연간 │
└──────────────┴────────────┴──────────────┴───────────┴────────────┘핵심: SOP는 "문서화를 위한 문서"가 아니라 "새벽 3시 장애 상황에서 실제로 꺼내 쓰는 도구"입니다. 특히 Runbook은 명령어를 복사-붙여넣기만 해도 돌아가도록 작성하고, PIR이 발생할 때마다 반드시 해당 Runbook을 검토하여 개선하는 루프를 만드는 것이 핵심입니다.
engineer