# Cloud-Native Data Lakehouse SRE Templates Design

## 1. Understanding Summary
*   **What is being built:** A suite of structured SRE templates for a Cloud-Native Data Lakehouse, heavily prioritizing Work Plans (작업계획서) and Maintenance SOPs.
*   **Why it exists:** To standardize and bulletproof operations, ensuring changes are executed safely at enormous scale (11PB) without breaching strict uptime SLAs (99.9% -> 99.99%).
*   **Who it is for:** The Core Platform SRE Team managing the underlying infrastructure.
*   **Tech Stack:** Kubernetes, Cilium (CNI), MinIO AIStor (Object Storage), Keycloak (IAM), Jenkins & ArgoCD (GitOps CI/CD), OpenSearch (Search/Log Analytics), Prometheus & Grafana (Observability).
*   **Explicit Non-goals:** We are not designing the application-level data pipelines (ETL/ELT) or data-science models; we are strictly designing operational templates for the platform infrastructure.

## 2. Assumptions & Constraints
1.  **Air-Gapped Network:** Because the environment is offline (except for a Nexus proxy), every SOP/Work Plan *must* include a prerequisite step to verify that the required container images, Helm charts, and binaries are already cached in Nexus before deployment begins.
2.  **GitOps First:** Direct cluster manipulation (e.g., `kubectl edit`, `helm upgrade`) is forbidden for standard changes. The Work Plan template reflects Git commits/PRs as the primary mechanism for change.
3.  **Massive Scale (11PB):** Storage operations (MinIO, OpenSearch) carry extreme risk. Templates require explicit steps for verifying data sync, quorum health, and replication status before and after maintenance.
4.  **Enterprise Work Plan Format:** The layout bridges modern cloud-native actions with professional Korean IT standards (including Schedule, Scope, Rollback Plan, and Approvers).

## 3. Decision Log
* **Decision 1:** Template Audience
  * **Decided:** Platform/Core SRE teams.
  * **Alternatives Considered:** Data Engineers, Leadership.
  * **Reason:** Ensures the templates are deeply technical and infrastructure-focused (dealing with K8s, MinIO, Cilium).
* **Decision 2:** Delivery Medium
  * **Decided:** Wiki / Issue-Tracker Templates (Confluence / Jira format).
  * **Alternatives Considered:** Git-Managed Markdown Templates, Automated Executable Runbooks.
  * **Reason:** Aligns with the user's preference for their organizational workflow, making it easy to copy-paste into ticketing systems tracking approvals, while still enforcing a GitOps operational behavior within the steps.

---

## 4. Final Design: Work Plan (작업계획서) Templates

These templates are designed to be copied directly into Jira Issues or Confluence Pages. They emphasize GitOps flows and Air-Gap prerequisites.

### 🇬🇧 English Work Plan Template

```markdown
# Cloud-Native Data Lakehouse SRE Work Plan

## 1. Meta Information
* **Task ID / Ticket:** [e.g., SRE-1234]
* **Target System & Component:** [e.g., MinIO AIStor Cluster 1, ArgoCD, Cilium]
* **Maintenance Window:** [YYYY-MM-DD HH:MM to HH:MM]
* **Expected Downtime:** [e.g., Zero (Rolling Restart), 5 minutes]
* **Operator:** [Name]
* **Approvers:** [L1 Approver Name], [L2 Approver Name]

## 2. Objective & Scope
* **Objective:** [Explain *why* this maintenance is required. e.g., Upgrade MinIO to patch CVE-202X-XXXX]
* **Scope of Changes:** [List specific changes. e.g., Update Helm chart version from 1.2 to 1.3 in `k8s-manifests` repo]
* **Impact Radius:**
  - Will data ingestion (Jenkins -> Data Pipeline) be affected? [Yes/No]
  - Will querying (OpenSearch) be affected? [Yes/No]
  - Risk Level: [Low/Medium/High/Critical]

## 3. Air-Gap & GitOps Prerequisites (Pre-Flight Checks)
* [ ] **Nexus Proxy Check:** Verified required container images and Helm charts are cached in the internal Nexus registry.
  - *Image(s):* `nexus.internal/minio/minio:RELEASE.2023-XX...`
* [ ] **Git PR Status:** Pull Request #[Number] is created, reviewed by [Reviewer Name], and ready to merge.
* [ ] **Storage/Cluster Health:**
  - Prometheus alerts are clear. [Link to Dashboard]
  - MinIO Quorum is healthy (No offline drives/nodes in 11PB cluster).
  - OpenSearch cluster status is `green`.
* [ ] **Communication:** Notification sent to stakeholders via Slack/Teams/Email regarding the maintenance window.

## 4. Execution Steps (GitOps Workflow)
*⚠️ Reminder: Direct `kubectl` edits are prohibited unless an emergency break-glass is authorized.*
1. [ ] Suspend ArgoCD Auto-Sync for the target application (if manual control is needed) [Optional].
2. [ ] Merge approved PR #[Number] into the `main` (or specific environment) branch.
3. [ ] Monitor ArgoCD Sync status: [Link to ArgoCD App URL]
4. [ ] Monitor Kubernetes rollout status using read-only access (`kubectl rollout status ...`).
5. [ ] [Add any component-specific steps, e.g., wait for DB schema migration, check Cilium endpoint health]

## 5. Rollback Plan
* **Rollback Trigger Conditions:**
  - ArgoCD sync fails or remains `Degraded` for > 5 minutes.
  - New pods enter `CrashLoopBackOff` or `ImagePullBackOff`.
  - Prometheus error rate spikes > 1% post-deployment.
* **Rollback Procedure:**
  1. [ ] Execute `git revert <commit-hash>` locally on the IaC repo.
  2. [ ] Create, approve, and merge the Revert PR.
  3. [ ] Verify ArgoCD synchronizes the reverted state.
  4. [ ] [Add specific data rollback steps if applicable - Note: stateful rollbacks require manual verification]

## 6. Validation & Sign-off (Post-Flight Checks)
* [ ] **Application Health:** Pods are `Running` and `Ready`.
* [ ] **Observability Verification:** 
  - Grafana dashboard shows nominal traffic and storage IOPS/latency. [Link to Dashboard]
  - No new Critical/Warning alerts generated.
* [ ] **System Functionality:** (e.g., OpenSearch accepts queries, MinIO AIStor accepts PUT/GET, Keycloak auth succeeds).
* [ ] **Sign-off:** Send "Maintenance Complete" notification to stakeholders and close the ticket.
```

### 🇰🇷 Korean Work Plan Template (작업계획서)

```markdown
# 클라우드 네이티브 데이터 레이크하우스 SRE 작업계획서

## 1. 기본 정보 (Meta Information)
* **작업 ID / 티켓:** [예: SRE-1234]
* **대상 시스템 및 컴포넌트:** [예: MinIO AIStor Cluster 1, ArgoCD, Cilium 등]
* **작업 일시:** [YYYY-MM-DD HH:MM ~ HH:MM]
* **예상 서비스 중단 시간 (Downtime):** [예: 무중단 (Rolling Restart), 5분 등]
* **작업자:** [이름]
* **결재자 / 승인자:** [1차 승인자 담당자명], [2차 승인자 파트장/팀장명]

## 2. 작업 목적 및 범위 (Objective & Scope)
* **작업 목적:** [작업 배경 기재. 예: CVE-202X-XXXX 보안 취약점 패치를 위한 MinIO 버전 업그레이드]
* **상세 작업 범위:** [작업 내용 기재. 예: `k8s-manifests` 레포지토리 내 Helm Chart 버전을 1.2에서 1.3으로 갱신]
* **서비스 영향도 (Impact Radius):**
  - 데이터 적재 (Jenkins Data Pipeline 구간) 트래픽에 영향이 있는가? [예 / 아니오]
  - 데이터 조회 (OpenSearch Query 구간) 에 영향이 있는가? [예 / 아니오]
  - 작업 위험도: [하(Low) / 중(Medium) / 상(High) / 초고위험(Critical)]

## 3. 폐쇄망 & GitOps 사전 점검 (Pre-Flight Checks)
* **[중요]** [ ] **Nexus 레포지토리 검증:** 배포에 필요한 컨테이너 이미지 및 Helm 차트가 폐쇄망 내부 프록시(Nexus)에 캐싱 되어 있는지 확인 완료.
  - *대상 이미지 경로:* `nexus.internal/minio/minio:RELEASE.2023-XX...`
* [ ] **Git PR 상태:** 인프라 변경 사항에 대한 Pull Request #[번호] 생성 완료. [리뷰어 이름]의 코드 리뷰 승인 완료 후 병합(Merge) 대기 중.
* [ ] **인프라/스토리지 헬스체크:**
  - Prometheus 알람 정상 (진행 중인 Alert 없음). [대시보드 링크]
  - MinIO Quorum 상태 정상 확인 (11PB 클러스터 내 Offline 노드/드라이브 없음).
  - OpenSearch 클러스터 상태 `Green` 확인.
* [ ] **이해관계자 공지:** 관련 개발 조직 및 유관 담당자에게 작업 일정 및 예상 영향도 사전 공지 완료 (Slack/Email 발송).

## 4. 작업 세부 절차 (Execution Steps - GitOps 기준)
*⚠️ 주의: 긴급 장애 복구(Break-glass) 상황을 제외하고, 클러스터에 대한 직접 적인 명령(`kubectl edit`, `helm upgrade`)은 엄격히 금지됩니다.*
1. [ ] (선택 사항) 통제된 롤아웃을 위해 대상 앱의 ArgoCD Auto-Sync 일시 중지 (Suspend).
2. [ ] 승인된 PR #[번호]를 `main` 브랜치(또는 타겟 환경 브랜치)로 Merge(병합) 수행.
3. [ ] ArgoCD 동기화(Sync) 뷰 모니터링: [ArgoCD 대상 앱 URL]
4. [ ] Kubernetes 배포 상태 모니터링 (Read-only 권한 사용. 예: `kubectl rollout status ...`).
5. [ ] [컴포넌트 종속 작업 추가. 예: Cilium Endpoint 상태 체크, DB 마이그레이션 모니터링 등]

## 5. 원복(Rollback) 계획
* **원복 판단 기준 (Trigger Conditions):**
  - ArgoCD 동기화가 실패하거나 5분 이상 `Degraded` 상태로 지연되는 경우.
  - 신규 배포된 Pod가 `CrashLoopBackOff` 또는 폐쇄망 이미지 풀 에러(`ImagePullBackOff`)에 빠지는 경우.
  - 작업 직후 Prometheus 기반 에러율(Error Rate) 1% 이상 급증, 혹은 Latency 지표 악화 시.
* **원복 절차:**
  1. [ ] Git 레포지토리에서 병합된 PR을 즉시 Revert 처리 (`git revert <commit-hash>`).
  2. [ ] 생성된 Revert PR을 긴급 승인 후 메인 브랜치로 병합(Merge).
  3. [ ] ArgoCD가 Revert된 이전 형상으로 정상 복구(Sync)되는지 모니터링.
  4. [ ] [Stateful 데이터에 대해 특수한 원복 스크립트가 필요한 경우 해당 절차 상세 기재]

## 6. 사후 검증 및 보고 (Post-Flight Checks)
* [ ] **애플리케이션 상태:** 대상 어플리케이션의 모든 Pod가 `Running` 및 `Ready` 상태인지 검증.
* [ ] **가시성(Observability) 검증:** 
  - Grafana 대시보드 상 트래픽, 스토리지 IOPS 대역폭이 평시 수준을 회복했는지 확인. [대시보드 링크]
  - 신규로 발생한 Critical/Warning 알람이 없는지 재확인.
* [ ] **기능/연동 점검:** (예: OpenSearch 쿼리 정상 작동 검증, MinIO 데이터 Read/Write 테스트 성공, Keycloak 인증 통과).
* [ ] **작업 종료 보고:** 이해관계자 채널에 "작업 완료 및 서비스 정상 확인" 최종 공지 발송.
```