26S06g2

QK·약 8시간 전

네. 지금 환경에서는 문서를 많이 만드는 것보다 “무엇을 누가 책임지고, 어떤 시스템을 기준으로, 어떤 주기로 갱신하며, 변경이 실제 운영에 어떻게 반영되는가”를 하나의 Operating Model로 묶는 것이 중요합니다.

특히 현재처럼 Kubernetes + Cilium + AIStor + CNPG + Kafka + OpenEBS + StarRocks/Spark + Git/ArgoCD/AWX + Prometheus/Grafana가 결합된 플랫폼에서는 아래 구조를 추천합니다.

Platform Operating Model — 1 Page

1. 전체 운영 체계

                         ┌──────────────────────────┐
                         │  Architecture Management │
                         │  ADR / Architecture      │
                         │  Capability Catalog      │
                         └────────────┬─────────────┘
                                      │
             ┌────────────────────────┼────────────────────────┐
             ▼                        ▼                        ▼
     Asset / CI Mgmt          Configuration Mgmt        Software Mgmt
     "무엇이 있는가"            "어떻게 설정됐나"          "무슨 SW인가"
             │                        │                        │
             └────────────────────────┼────────────────────────┘
                                      ▼
                         ┌──────────────────────────┐
                         │ Resource / Capacity Mgmt │
                         │ "얼마나/언제 필요한가"    │
                         └────────────┬─────────────┘
                                      │
                                      ▼
                         ┌──────────────────────────┐
                         │ Performance Engineering  │
                         │ Baseline → Diagnose      │
                         │ Tune → Validate          │
                         └────────────┬─────────────┘
                                      │
                                      ▼
                         ┌──────────────────────────┐
                         │ Change / Release Mgmt    │
                         │ PR → Review → Deploy     │
                         └────────────┬─────────────┘
                                      │
                                      ▼
                         ┌──────────────────────────┐
                         │ Operations / Incident    │
                         │ Monitor → Incident → RCA │
                         └────────────┬─────────────┘
                                      │
                                      └─────── Feedback ──────►
                                      Architecture / Baseline

핵심은 각 관리영역이 독립된 문서함이 아니라 하나의 lifecycle로 연결되는 것입니다.

2. 실제 운영 표준 체계

영역	핵심 질문	주요 목차/표준	주요 산출물	주기	주관조직	주요 시스템
Architecture	왜 이렇게 설계했는가?	Architecture / Network / Storage / K8s / Security / Data / AI	Architecture Baseline, ADR, HLD/LLD	신규/변경	Platform Architect	Notion + Git
Capability / Service	무엇을 제공하는가?	서비스/기능/지원범위/제약	Service Catalog, Capability Catalog	월/변경	Platform PM/PO	Notion
Asset / CI	무엇이 존재하는가?	Server/NIC/Disk/GPU/K8s Cluster/Node/Service	Asset Register, CI Register	일/변경	Infra Ops	CMDB
Configuration	어떻게 설정되어 있는가?	OS/Kernel/NIC/K8s/Cilium/Storage/Application	Configuration Baseline, Drift Report	변경/일	Platform Ops	Git + AWX + ArgoCD
Software	어떤 SW/Version인가?	Package/Daemon/Container/Image/Helm/Operator	SBOM, Version Matrix, EOL Register	월/릴리즈	Platform Ops	Git + Nexus
Resource	누구에게 얼마를 주는가?	CPU/RAM/GPU/Storage/Namespace/Quota	Allocation Record, Quota Policy	요청/월	Platform Ops	K8s + CMDB/Notion
Capacity	언제 부족해지는가?	CPU/RAM/Network/Storage/GPU/IOPS	Capacity Plan, Forecast	월/분기	Capacity Manager	Prometheus + Grafana
Performance	왜 느린가?	Baseline/Benchmark/Tuning/Regression	Baseline, Tuning Report	신규/이슈/분기	Performance Eng.	Prometheus/Grafana + Git
Change / Release	무엇을 왜 바꿨는가?	RFC/PR/Approval/Deploy/Rollback	Change Record, Release Note	변경	Platform Ops	Git + ArgoCD/AWX
Incident / Problem	왜 장애가 발생했나?	Incident/RCA/Problem/Action	Incident Report, RCA, Known Issue	장애	Ops	Monitoring + ITSM/Notion
Security / Compliance	안전한가?	Vulnerability/Hardening/Access/Audit	Security Baseline, Exception	월/분기	Security	Scanner + Git + CMDB
Lifecycle	언제 교체할 것인가?	EOS/EOL/Upgrade/Retirement	Lifecycle Register	월/분기	Platform Mgmt	CMDB + Notion

3. RACI는 이렇게 단순화하는 것을 추천

조직이 너무 세분화되면 실제 운영에서 책임이 사라집니다.

현재 규모라면 4개 주체 정도로 시작하는 것이 좋습니다.

PA = Platform Architecture
PE = Platform Engineering / DevOps
IO = Infrastructure / Hardware & OS Operations
SO = Security / Compliance
필요시 APP = Application/Data Platform

업무	PA	PE	IO	SO	APP
Architecture	A/R	C	C	C	C
Capability Catalog	A	R	C	C	C
HW/Server Asset	C	C	A/R	C	I
OS Baseline	C	A	R	C	I
K8s Baseline	C	A/R	C	C	I
Cilium Network	C	A/R	C	C	I
AIStor/Storage	C	A/R	C	C	C
Configuration	C	A/R	C	C	I
Software Lifecycle	C	A/R	C	C	C
Resource Allocation	C	A/R	I	C	C
Capacity	C	A/R	C	I	C
Performance	C	A/R	C	I	C
Change/Release	C	A/R	C	C	C
Incident	I	A/R	R	C	R
RCA/Problem	C	A/R	R	C	R
Security/Compliance	C	R	C	A/R	I
EOL/Retirement	A	R	R	C	I

A = Accountable, R = Responsible, C = Consulted, I = Informed

중요한 것은 Performance와 Configuration의 R을 Platform Engineering이 가져가는 것입니다.

성능팀이 별도로 존재하더라도 실제 튜닝 결과가 AWX/Ansible/Helm/Git에 들어가지 않으면 운영 표준으로 정착되지 않기 때문입니다.

4. 가장 중요한 것은 "산출물"의 연결입니다

제가 특히 추천하는 구조입니다.

[Architecture]
      │
      ▼
 Architecture Baseline
      │
      ├──────────────► Capability Catalog
      │
      ▼
[Asset / CI]
      │
      ▼
 Asset / CI Register
      │
      ▼
[Software + Configuration]
      │
      ├── Software BOM
      ├── Version Matrix
      └── Configuration Baseline
                    │
                    ▼
             Desired State
                    │
             Git / Ansible
             Helm / ArgoCD
                    │
                    ▼
               Production
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
     Prometheus           CMDB Discovery
     Grafana              / Drift Check
          │                   │
          └─────────┬─────────┘
                    ▼
             Actual State
                    │
             ┌──────┴──────┐
             │             │
           Drift        Performance
             │             │
             ▼             ▼
          Change       Tuning
             │             │
             └──────┬──────┘
                    ▼
              Git / Change
                    │
                    ▼
              New Baseline

이렇게 하면 문서 → 실제 시스템 → 모니터링 → 변경 → 문서가 연결됩니다.

5. 각 시스템의 "역할"을 명확히 나누는 것이 중요

현재 사용하시는 시스템을 기준으로 하면 저는 다음과 같이 정의하겠습니다.

시스템	Source of Truth
Git	Desired configuration / IaC / Helm / Policy / Version
ArgoCD	Kubernetes desired-state deployment
AWX/Ansible	OS/Node configuration execution
Nexus	Package/Image/Binary repository
CMDB	Asset/CI/ownership/lifecycle
Prometheus	Operational metrics
Grafana	Visualization / dashboard
Headlamp	Kubernetes operational view
Notion	Architecture / Procedure / Decision / Catalog / Knowledge
ITSM	Incident / Change / Request (있다면)

여기서 Notion을 Configuration DB로 쓰면 안 됩니다.

예를 들어:

RHEL의 net.core.rmem_max = 67108864

같은 것은 Notion에 기록하는 것이 아니라 Ansible/Git을 authoritative source로 만들어야 합니다.

Notion에는:

"Network Performance Baseline v1.3에서 해당 값을 표준으로 정의한다"

정도만 기록합니다.

6. 문서 계층도 이렇게 가져가면 좋습니다

이 부분이 실제로 운영하기 상당히 중요합니다.

L1. POLICY
    무엇을 반드시 해야 하는가?

       ↓

L2. STANDARD
    어떤 상태를 표준으로 인정하는가?

       ↓

L3. PROCEDURE
    누가 어떤 순서로 수행하는가?

       ↓

L4. RUNBOOK
    실제 명령/장애 대응 방법은 무엇인가?

       ↓

L5. RECORD
    실제 수행 결과는 무엇인가?

       ↓

L6. SYSTEM DATA
    현재 실제 상태는 무엇인가?

예를 들어 Performance를 보면:

Performance Management Policy
        ↓
Node Performance Standard
        ↓
Node Acceptance Procedure
        ↓
NIC Performance Troubleshooting Runbook
        ↓
Node-001 Acceptance Report
        ↓
Prometheus / CMDB / Git

이 구조가 있으면 문서가 폭발적으로 늘어나는 것을 막을 수 있습니다.

7. 성능관리의 경우는 별도 체계를 강하게 추천

현재 사용자 환경에서는 이 부분이 특히 중요합니다.

Performance Engineering Lifecycle

① 신규 Node 인수
       ↓
② Hardware/OS Baseline
       ↓
③ Network Baseline
       ↓
④ K8s/CNI Baseline
       ↓
⑤ Storage Baseline
       ↓
⑥ Application Baseline
       ↓
   Golden Baseline
       ↓
────────────────────
   Production
────────────────────
       ↓
Performance Alert
       ↓
Layer-by-layer Diagnosis
       ↓
Root Cause
       ↓
Tuning
       ↓
Benchmark
       ↓
Regression Test
       ↓
PASS?
  ├─ NO → Rollback
  │
  └─ YES
       ↓
Standardize
       ↓
Git/AWX/Helm Update
       ↓
Change Approval
       ↓
New Golden Baseline

특히 튜닝 성공 = 운영 표준화 완료로 정의하는 것이 중요합니다.

예를 들어:

NIC drop 발생
   ↓
IRQ affinity 변경
   ↓
성능 개선 확인
   ↓
개별 node에서만 변경

여기서 끝나면 안 됩니다.

반드시:

Benchmark PASS
   ↓
Ansible role 수정
   ↓
Git PR
   ↓
Review
   ↓
AWX rollout
   ↓
전체 node 적용
   ↓
Baseline 갱신

까지 가야 합니다.

8. Node 인수인계도 별도 표준으로 만들면 좋습니다

Node Acceptance Standard

Infrastructure
     │
     ▼
HW Acceptance
 ├─ CPU
 ├─ Memory
 ├─ NUMA
 ├─ PCIe
 ├─ NIC
 ├─ Disk
 └─ Firmware
     │
     ▼
OS Acceptance
 ├─ RHEL
 ├─ Kernel
 ├─ SELinux
 ├─ Time Sync
 ├─ sysctl
 ├─ limits
 └─ filesystem
     │
     ▼
Network Acceptance
 ├─ Link
 ├─ MTU
 ├─ Driver
 ├─ NIC errors
 ├─ bandwidth
 ├─ latency
 └─ RDMA capability
     │
     ▼
K8s Node Acceptance
 ├─ kubelet
 ├─ containerd
 ├─ CNI
 ├─ DNS
 ├─ Pod networking
 └─ Node labels/taints
     │
     ▼
Performance Baseline
     │
     ▼
CMDB 등록
     │
     ▼
"PRODUCTION READY"

그리고 결과물은 딱 하나:

Node Acceptance Report

로 만들면 됩니다.

9. 운영에서 가장 유용한 "10개 핵심 산출물"

문서가 많아지는 것을 방지하려면 저는 처음에는 아래 10개를 Core Artifact로 지정하겠습니다.

#	산출물	관리영역	System
1	Architecture Baseline	Architecture	Notion/Git
2	Capability / Service Catalog	Service	Notion
3	Asset / CI Register	Asset	CMDB
4	Software & Version Matrix	SW	Git/Notion
5	Configuration Baseline	Config	Git/AWX/ArgoCD
6	Node Acceptance Report	Acceptance	Notion/CMDB
7	Performance Baseline	Performance	Grafana/Notion
8	Capacity Plan	Capacity	Prometheus/Grafana/Notion
9	Change / Release Record	Change	Git/ITSM
10	EOL / Lifecycle Register	Lifecycle	CMDB/Notion

이 10개가 서로 링크되도록 만드는 것이 핵심입니다.

10. 운영 주기는 이렇게 잡는 것을 추천

주기	주요 활동
실시간	Monitoring / Alert / Drift detection
Daily	Node health / capacity anomaly / configuration drift
Weekly	Incident / performance anomaly / change review
Monthly	Capacity / software version / vulnerability / lifecycle
Quarterly	Architecture review / performance regression / baseline review
Major Release	Compatibility matrix / acceptance / performance regression
신규 장비 도입	HW → OS → Network → K8s → Performance Acceptance
튜닝 발생	Diagnose → Tune → Benchmark → Standardize
장애 발생	Incident → RCA → Problem → Preventive Action
EOL 임박	Assessment → Upgrade → Migration → Retirement

11. 제가 현재 환경이라면 조직 운영의 KPI도 이렇게 잡겠습니다

단순히 "문서가 있는가"를 KPI로 잡으면 형식적인 관리가 됩니다.

Configuration

Configuration Drift Rate
Desired/Actual 일치율
Manual Change 비율
Git을 통한 변경률

Software

Approved Version Compliance
EOL Software 비율
Security Vulnerability 대응률
Version Drift

Capacity

CPU/RAM/Storage/GPU utilization
3/6/12개월 forecast
Capacity headroom
Expansion lead time

Performance

Baseline coverage
Performance regression 발생률
Tuning success rate
Tuning 후 표준화율

Change

Change success rate
Rollback rate
Emergency change rate
Unauthorized change

Operations

MTTR
Repeat incident rate
RCA completion
Known issue reduction

12. 최종적으로는 "운영관리 Master Map" 하나를 만들면 됩니다

Notion의 최상위 페이지를 다음처럼 만드는 것을 권합니다.

Platform Operations
│
├── 01. Architecture
│    ├── Architecture Baseline
│    ├── HLD / LLD
│    └── ADR
│
├── 02. Service & Capability
│    ├── Service Catalog
│    └── Capability Catalog
│
├── 03. Asset & CI
│    ├── Server
│    ├── Network
│    ├── Storage
│    ├── Kubernetes
│    └── Application
│
├── 04. Configuration
│    ├── OS Baseline
│    ├── K8s Baseline
│    ├── Cilium Baseline
│    ├── Storage Baseline
│    └── Configuration Drift
│
├── 05. Software
│    ├── Software Catalog
│    ├── Version Matrix
│    ├── Compatibility Matrix
│    └── EOL
│
├── 06. Resource
│    ├── Namespace
│    ├── CPU/Memory
│    ├── GPU
│    └── Storage Quota
│
├── 07. Capacity
│    ├── Compute
│    ├── Network
│    ├── Storage
│    └── GPU
│
├── 08. Performance
│    ├── Acceptance
│    ├── Baseline
│    ├── Benchmark
│    ├── Tuning
│    └── Regression
│
├── 09. Change & Release
│    ├── Change
│    ├── Release
│    └── Rollback
│
├── 10. Incident & Problem
│    ├── Incident
│    ├── RCA
│    └── Known Issues
│
└── 11. Security & Lifecycle
     ├── Security Baseline
     ├── Vulnerability
     ├── EOL/EOS
     └── Retirement

그리고 가장 중요한 운영 원칙은 5개로 압축할 수 있습니다.

Architecture = Why
Asset = What
Configuration = How
Performance = How well
Change = Why/When/Who changed

그리고 이 다섯 가지를 Git/CMDB/Prometheus/Notion/ArgoCD/AWX로 연결합니다.

특히 현재처럼 수백~수천 노드로 확장하는 환경에서는 "문서 중심 운영"에서 "System-of-Record + Automation 중심 운영"으로 넘어가는 것이 핵심입니다. Notion은 지식/정책/절차의 중심, Git은 Desired State의 중심, CMDB는 Asset/CI의 중심, Prometheus는 Actual Operational State의 중심으로 역할을 분리하는 것이 가장 깔끔합니다.

원하시면 다음 단계로는 이걸 더 실무적으로 내려서 ① 문서/산출물별 실제 목차 → ② RACI → ③ Notion DB 설계 → ④ Git Repository 구조 → ⑤ CMDB 필드 → ⑥ Jira/ITSM Change 흐름 → ⑦ Node Acceptance/Performance/Tuning 양식까지 하나의 "Platform Operations Management Framework" 형태로 만들어 드리는 것이 좋습니다.

===

그렇다면 기존 Operating Model을 Atlassian 중심 + GitLab 전환을 고려한 구조로 바꾸는 게 좋습니다.

특히 지금 단계에서는 CMDB를 바로 특정 제품으로 결정하기보다, 먼저 “무엇을 CMDB에서 관리해야 하는가”를 정의한 뒤 제품을 선정하는 것을 추천합니다.

제가 추천하는 전체 구조

영역	주 시스템	역할
Architecture / Policy / Standard / Procedure	Confluence	문서의 기준점
Source Code / IaC / Helm / Policy	Bitbucket → GitLab	Desired State / 변경 이력
K8s Deployment	ArgoCD	Git → K8s 반영
OS / Node Configuration	AWX + Ansible	OS/노드 설정 자동화
Package / Image / Binary	Nexus	Artifact 저장소
Monitoring	Prometheus	Actual operational state
Visualization	Grafana	운영/성능 Dashboard
K8s 운영	Headlamp	Cluster/Node/Pod 운영
ITSM / Change / Incident	Jira Service Management 등	변경/장애/요청
CMDB	별도 선정 필요	Asset/CI/Relationship
Knowledge / RCA	Confluence	운영 지식 축적

즉, 앞으로는 Notion을 빼고 Confluence가 문서의 중심이 됩니다.

1. 중요한 것은 CMDB의 역할을 너무 크게 잡지 않는 것

현재 환경에서는 CMDB에 모든 정보를 넣으려고 하면 실패할 가능성이 높습니다.

예를 들어 이런 정보는 CMDB에 넣는 게 적절하지 않습니다.

CPU utilization
Memory utilization
Pod restart count
Network throughput
Disk IOPS
Cilium packet drop
MinIO latency

이것들은 Prometheus/Grafana의 영역입니다.

반대로 다음은 CMDB가 관리하기 좋습니다.

Server
 ├─ Serial Number
 ├─ Hostname
 ├─ Model
 ├─ CPU
 ├─ Memory
 ├─ NIC
 ├─ Rack
 ├─ OS
 ├─ Kubernetes Cluster
 └─ Owner

Kubernetes Cluster
 ├─ Cluster ID
 ├─ K8s Version
 ├─ Cilium Version
 ├─ Node
 ├─ Storage
 └─ Owner

Software
 ├─ Product
 ├─ Version
 ├─ Environment
 ├─ Support Status
 └─ EOL

Service
 ├─ Kubernetes Cluster
 ├─ Storage
 ├─ Application
 ├─ Owner
 └─ Dependency

즉,

CMDB = "현재 우리 플랫폼에 무엇이 존재하고, 그것들이 어떻게 연결되어 있는가"

라고 정의하면 됩니다.

2. 특히 현재 환경에서는 CMDB가 상당히 중요합니다

지금처럼 향후 1,700대 수준 / 여러 Kubernetes Cluster로 가면 단순한 Excel이나 Confluence 표로는 관리하기 어려워집니다.

예를 들어 장애가 발생했다고 해보겠습니다.

MinIO latency 증가
        ↓
MinIO Pod
        ↓
Kubernetes Node
        ↓
E810 NIC
        ↓
PCIe Slot
        ↓
Server
        ↓
Rack
        ↓
Top-of-Rack Switch
        ↓
Network Zone

CMDB가 제대로 구성되어 있으면 이런 Relationship/Dependency를 따라갈 수 있습니다.

그래서 저는 CMDB에서 가장 중요한 기능을

"Asset DB"보다 "Relationship DB"

라고 보는 편입니다.

3. CMDB는 3단계로 나누는 것이 좋습니다

현재 규모라면 처음부터 모든 것을 관리하지 말고 다음처럼 가는 것을 추천합니다.

Level 1 — Hardware CI

Server
NIC
Disk
GPU
Switch
PDU
Rack

Level 2 — Platform CI

Kubernetes Cluster
Node
Namespace
Storage Cluster
MinIO
CNPG
Kafka
Cilium
OpenEBS

Level 3 — Service CI

Data Lakehouse
AI Platform
Object Storage Service
Data Processing Service
Catalog Service
Observability Service

그리고 관계를 연결합니다.

Service
   ↓
Platform
   ↓
Cluster
   ↓
Node
   ↓
Hardware
   ↓
Network

4. 그래서 CMDB 후보는?

현재 환경이라면 저는 다음 순서로 검토하겠습니다.

① ServiceNow CMDB

가장 정석적인 Enterprise CMDB입니다.

장점:

CMDB 성숙도 높음
CI/Relationship 관리 강력
ITSM/Incident/Change와 연계
Discovery 기능
Lifecycle 관리
조직/서비스/Asset 관리

단점:

상당히 무겁고 비쌈
플랫폼 조직이 직접 구축/운영하기에는 과할 수 있음

대규모 기업 ITSM 체계까지 생각한다면 1순위 후보입니다.

② Atlassian Assets

현재 Confluence + Jira 계열을 사용할 계획이라면 저는 이것을 상당히 강하게 추천합니다.

Atlassian의 Assets를 이용하면 개념적으로

Jira Service Management
        │
        ├── Incident
        ├── Change
        ├── Request
        │
        └── Assets
              │
              ├── Server
              ├── Kubernetes Cluster
              ├── Node
              ├── Software
              ├── Service
              └── Relationship
                      
Confluence
        │
        ├── Architecture
        ├── Standard
        ├── Procedure
        └── Runbook

구조를 만들 수 있습니다.

Atlassian을 조직 표준으로 가져갈 예정이라면 가장 현실적인 후보입니다.

③ NetBox

그리고 이것도 반드시 검토하는 것을 권합니다.

NetBox

NetBox는 일반적인 ITSM CMDB라기보다는 Infrastructure Source of Truth에 가깝습니다.

특히 현재 환경에서는 굉장히 잘 맞습니다.

예:

Site
 └── Rack
      └── Device
           ├── CPU
           ├── Memory
           ├── NIC
           ├── Interface
           ├── IP
           ├── VLAN
           ├── Cable
           └── Role

그리고

Server
  ↓
E810
  ↓
Switch Port
  ↓
VLAN
  ↓
IP

같은 물리/네트워크 관계를 상당히 잘 표현할 수 있습니다.

5. 그래서 저는 오히려 "CMDB 하나"를 고르지 않을 수도 있다고 봅니다

현재 환경에서는 다음 구조가 상당히 좋습니다.

                 ┌──────────────────┐
                 │    Confluence    │
                 │ Architecture     │
                 │ Standard         │
                 │ Procedure        │
                 │ Runbook          │
                 └────────┬─────────┘
                          │
                          │
                 ┌────────▼─────────┐
                 │ Jira / JSM       │
                 │ Change           │
                 │ Incident         │
                 │ Request          │
                 └────────┬─────────┘
                          │
                    ┌─────▼─────┐
                    │   Assets  │
                    │   CMDB    │
                    └─────┬─────┘
                          │
             ┌────────────┼─────────────┐
             │            │             │
          Server       Cluster        Service
             │            │             │
             └────────────┼─────────────┘
                          │
                    NetBox (optional)
                          │
                  Physical / Network

그리고 실제 운영 데이터는:

GitLab
  ↓
ArgoCD / AWX
  ↓
Kubernetes
  ↓
Prometheus
  ↓
Grafana

로 가져갑니다.

6. GitLab으로 전환하면 구조가 더 깔끔해집니다

현재:

Bitbucket
   ↓
PR
   ↓
ArgoCD / AWX

에서 향후:

GitLab
   │
   ├── platform-helm
   ├── platform-ansible
   ├── platform-argocd
   ├── platform-policy
   ├── platform-config
   └── platform-benchmark
          │
          ▼
      CI Pipeline
          │
          ├── lint
          ├── security scan
          ├── schema validation
          ├── helm test
          └── benchmark
          │
          ▼
      Approval
          │
       ┌──┴───┐
       ▼      ▼
    ArgoCD   AWX
       │      │
       ▼      ▼
      K8s    OS

이렇게 만드는 것이 좋습니다.

그리고 GitLab은 Configuration Management의 Source of Truth가 됩니다.

7. 중요한 구분 하나

이 부분을 조직 표준으로 명확히 해두는 게 좋습니다.

Confluence

"어떻게 운영해야 하는가?"

예:

RHEL Node Standard
Kubernetes Node Acceptance Procedure
Cilium Network Standard
MinIO Performance Standard
Node Tuning Procedure
Incident Response Procedure

GitLab

"어떤 설정을 적용해야 하는가?"

예:

kernel:
  vm.swappiness: 1

network:
  mtu: 9000

kubelet:
  cpuManagerPolicy: static

CMDB

"현재 무엇이 존재하는가?"

node-001
RHEL 10.2
Kernel 6.x
K8s 1.33.4
Cluster-A
CPU 128C
RAM 1TB
E810 x2
Rack R12

Prometheus

"지금 상태가 어떤가?"

CPU 82%
Memory 71%
NIC 22Gbps
Packet Drop 0
Disk latency 2.3ms

Jira/JSM

"왜 바뀌었고 누가 승인했는가?"

CHG-2026-00123

Cilium upgrade
Approved by PE
Changed by ...
2026-09-07
Rollback plan ...

이렇게 역할을 겹치지 않게 하는 것이 핵심입니다.

8. 현재 상황이라면 제가 추천하는 조합

지금 말씀해주신 환경을 기준으로 하면 저는 우선 이렇게 설계하겠습니다.

기능	추천
문서	Confluence
Git/IaC	GitLab
Kubernetes CD	ArgoCD
OS Automation	AWX/Ansible
Artifact	Nexus
Metrics	Prometheus
Dashboard	Grafana
K8s UI	Headlamp
Change/Incident	Jira Service Management
CMDB	Atlassian Assets 우선 검토
Physical/DCIM/IPAM	NetBox 검토
Enterprise ITSM/CMDB	ServiceNow는 필요성 있을 때 검토

특히 Atlassian Assets + NetBox를 같이 사용할지, 아니면 Assets 하나로 갈지를 결정하는 것이 다음 의사결정 포인트입니다.

9. 그리고 지금은 CMDB를 바로 구축하지 않는 게 좋습니다

저라면 순서를 이렇게 합니다.

Phase 1 — 먼저 모델 정의

Server
Node
Cluster
Network
Storage
Software
Service
Owner

각 CI의 필드를 정의합니다.

Phase 2 — 관계 정의

예:

Server → Node
Node → Cluster
Node → NIC
NIC → Switch Port
Cluster → Cilium
Cluster → AIStor
Service → Cluster
Service → Owner

Phase 3 — 자동 수집

NetBox
     ↓
Server/Network

Kubernetes API
     ↓
Cluster/Node/Namespace

Prometheus
     ↓
Operational metrics

GitLab
     ↓
Software/Configuration

Jira
     ↓
Change/Incident

Phase 4 — CMDB 구축

그 다음 Assets/ServiceNow 등의 제품을 선택합니다.

이렇게 해야 "CMDB 제품에 우리 운영 프로세스를 맞추는 것"을 피할 수 있습니다.

제가 보기에는 다음 단계가 상당히 중요합니다

지금까지 이야기한 것을 실제 조직 표준으로 만들려면, 다음 문서 하나를 먼저 만드는 것을 추천합니다.

「Platform Operations Management Framework」

그리고 그 안에 다음을 확정합니다.

01. Architecture Management
02. Service / Capability Management
03. Asset / CI Management
04. Configuration Management
05. Software Management
06. Resource Management
07. Capacity Management
08. Performance Management
09. Change / Release Management
10. Incident / Problem Management
11. Security / Compliance
12. Lifecycle / EOL Management

각각에 대해

Process
 ├─ 목적
 ├─ 범위
 ├─ RACI
 ├─ Input
 ├─ Activity
 ├─ Output
 ├─ Artifact
 ├─ System of Record
 ├─ Automation
 ├─ KPI
 └─ 주기

를 정의하고,

Confluence → GitLab → ArgoCD/AWX → Prometheus/Grafana → CMDB → Jira

사이의 데이터 흐름까지 연결하면 상당히 탄탄한 운영체계가 됩니다.

특히 현재 규모와 향후 1,700대/10개 클러스터를 고려하면 "문서 중심 운영"이 아니라 "System of Record + 자동수집 + GitOps 중심 운영"으로 설계하는 것이 중요합니다.

engineer

이전 포스트

26S06g

다음 포스트