운영 분석
1) 운영 분석이란 무엇이며 왜 필요한가
Operational Analytics (Ops Analytics) 는 관찰 가능성 (메트릭/로그/트레일), ITSM (사고/문제/변경), CI/CD (릴리스/컨피그), 공급자 (PSP/KYC/CDN/클라우드), FinOps I (비용) 및 비즈니스 SLS (지불 성공) 결정.
목표:- 원인의 조기 발견 및 정확한 귀속을 통해 MTTD/MTTR을 줄입니다.
- SLO 및 오류 예산을 통제하십시오.
- 링크 변경 → 영향 (릴리스/구성 → SLI/SLO/불만/비용)
- 팀과 경영진에게 셀프 서비스 분석을 제공합니다.
2) 소스 및 표준 데이터 계층
원격 측정: 메트릭 (SLI/리소스), 로그 (샘플링/PII 에디션), 트레일 (trace _ id/span _ id, 릴리스 태그).
ITSM/Incident 모듈: SEV, T0/Detched/Ack/Declared/Mitigated/Recovered 타임 스탬프, RCA/CAPA.
CI/CD 및 설정: 버전, 커밋, 카나리아/청록색, 플래그 상태, 대상 구성 요소.
제공자: 상태/SLA, 지연, 오류 코드, 경로 가중치.
FinOps: 태그/계정/테넌트, $/단위 (1k 오페라) 별 비용 .
DataOps: 창 신선도, DQ 오류, 계보.
주요 원칙은 식별자를 통한 단일 상관 관계입니다: '서비스', '지역', '테넌트', '릴리스 _ id', 'change _ id', 'sacle _ id', 'provider', 'trace _ id'.
3) 단일 데이터 모델 (단순화 된 프레임 워크)
dim_service(service_id, owner, tier, slo_targets…)
dim_time(ts, date, hour, tz)
dim_region(region_id, country, cloud)
dim_provider(provider_id, type, sla)
fact_sli(ts, service_id, region_id, tenant, metric, value, target, window)
fact_incident(incident_id, service_id, sev, t0, t_detected, t_ack, t_declared, t_mitigated, t_recovered, root_cause, trigger_id, burn_minutes)
fact_change(change_id, type(code config infra), service_id, region_id, started_at, finished_at, canary_pct, outcome(ok rollback), annotations)
fact_cost(ts, service_id, region_id, tenant, cost_total, cost_per_1k)
fact_provider(ts, provider_id, region_id, metric(latency error status), value)
fact_dq(ts, dataset, freshness_min, dq_errors)4) SLI/SLO 및 비즈니스 지표
차이점을 찾을 수 없습니다.
가용성: '가용성', 'http _ p95', '오류 _ rate', '큐 _ 깊이'.
SLO 계층: 대상 + 연소율 (짧은/긴 창), 위반의 자동 주석.
정규화: 1k 당 성공적인 운영/사용자/트래픽 지표.
5) 원인의 상관 및 귀속
릴리스/컨디션으로 SLI/SLO: 그래프에 주석; 원인 및 결과 보고서 (변경 사건의 비율; MTTR 변경 사건).
제공 업체 비즈니스 SLI: 경로 대 대기 시간/오류, 각 제공 업체가 SLO 미스에 기여한 경로 가중치.
용량/자원 대기 시간-풀 과열 → p95 성장 → 변환 영향.
6) 변칙과 예측
변칙적 탐지: 계절성 + 백분위 수 임계 값 + 변경 검색 기능 (릴리스 전/후).
예측: 주간/계절로드 패턴, 번 아웃 오류 예산 예측, 비용 예측 ($/단위).
Gardrails: 쿼럼 소스 (합성 + RUM + 비즈니스 SLI) 에서만 경고합니다.
7) 쇼케이스 및 대시 보드 (참조)
1. 이그제큐티브 28d: SEV 믹스, 중간 MTTR/MTTD, SLO 준수, $/단위, 주요 이유.
2. SRE Ops: SLI/SLO + 번 레이트, 페이지 스톰, 실행 가능한%, 실패율 변경.
3. 영향 변경: 릴리스/구성 SLI/SLO/불만, 롤백 및 그 효과.
4. 제공자: PSP/KYC/CNC 상태 라인, 비즈니스 SLI에 영향을 미침, 응답 시간.
5. FinOps: 1k txn 당 비용, 로그/탈출, 비용 이상, 권장 사항 (샘플링, 스토리지).
6. DataOps: 창 신선도, DQ 오류, 파이프 라인 SLA, 백필 성공.
8) 데이터 품질 및 거버넌스
이벤트 계약: 사건/릴리스/SLI (필수 필드, 균일 한 시간대) 에 대한 명확한 체계.
DQ- 체커: 완전성, 키의 고유성, 타임 라인 일관성 (t0
계보: 소싱하기위한 대시 보드 (추적 가능).
PII/비밀: 정책에 의한 편집/마스킹; 증거를위한 WORM.
SLA 신선도: Ops는 5 분 지연을 보여줍니다.
9) 운영 분석 성숙도 지표
적용 범위: 상점 및 SLO 보드에서 중요한 서비스의% (대상 95% 이상).
신선도: 신선함이있는 위젯의 점유율은 5 분입니다 (목표는 95% 이상).
액션 가능성: 대시 보드에서 액션으로% 전환 (플레이 북/SOP/티켓) 90% 이상.
탐지 범위: 사고의 85% 이상이 자동화에 의해 감지됩니다.
주문률: 원인이 확인되고 90% 이상으로 트리거되는 사건의 비율.
영향 점유율 변경: 변경 사항과 관련된 사건의 비율 (추세 제어).
데이터 품질: DQ 오류/주간 → QoQ 텍스트.
10) 프로세스: 데이터에서 행동으로
1. 컬렉션 → 디스플레이 케이스의 정규화 → (ETL/ELT, ML의 기능 계층).
2. 매트릭스 감지/예측 → 확장 (IC/P1/P2/Comms).
3. 동작: 플레이 북/SOP, 릴리스 게이트, 기능 플래그, 공급자 스위치.
4. 증거 및 AAR/RCA: 타임 라인, 그래프, 릴리스/로그/트랙에 대한 링크.
5. CAPA 및 제품 솔루션: 화상 시간과 $ 영향으로 우선 순위를 정합니다.
11) 쿼리 예 (아이디어)
11. SLO에 대한 릴리스의 영향 1 개 (24 시간)
sql
SELECT r. change_id,
COUNT(i. incident_id) AS incidents,
SUM(i. burn_minutes) AS burn_total_min,
AVG(CASE WHEN i.root_cause='code' THEN 1 ELSE 0 END) AS code_ratio
FROM fact_change r
LEFT JOIN fact_incident i
ON i.trigger_id = r. change_id
WHERE r. started_at >= NOW() - INTERVAL '24 hours'
GROUP BY 1
ORDER BY burn_total_min DESC;11. 2 지역 별 공급자의 문제 공유
sql
SELECT region_id, provider_id,
SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END) AS prov_inc,
COUNT() AS all_inc,
100. 0SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END)/COUNT() AS pct
FROM fact_incident
WHERE t0 >= DATE_TRUNC('month', NOW())
GROUP BY 1,2
ORDER BY pct DESC;11. 3 1k 성공적인 지불 당 비용
sql
SELECT date(ts) d,
SUM(cost_total)/NULLIF(SUM(success_payments)/1000. 0,0) AS cost_per_1k
FROM fact_cost c
JOIN biz_payments b USING (ts, service_id, region_id, tenant)
GROUP BY d ORDER BY d DESC;12) 아티팩트 패턴
12. 1 사건 이벤트 다이어그램 (JSON, 조각)
json
{
"incident_id": "2025-11-01-042",
"service": "payments-api",
"region": "eu",
"sev": "SEV-1",
"t0": "2025-11-01T12:04:00Z",
"detected": "2025-11-01T12:07:00Z",
"ack": "2025-11-01T12:09:00Z",
"declared": "2025-11-01T12:11:00Z",
"mitigated": "2025-11-01T12:24:00Z",
"recovered": "2025-11-01T12:48:00Z",
"root_cause": "provider",
"trigger_id": "chg-7842",
"burn_minutes": 18
}12. 2 메트릭 카탈로그 (YAML, 단편)
yaml metric: biz. payment_success_ratio owner: team-payments type: sli target: 99. 5 windows: ["5m","1h","6h","28d"]
tags: [tier0, region:eu]
pii: false12. 3 경영진 성적표 (섹션)
1) SEV mix and MTTR/MTTD trends
2) SLO adherence and burn-out risks
3) Change Impact (CFR)
4) Providers: Degradation and switchover
5) FinOps: $/unit, log anomalies/egress
6) CAPAs: Status and Deadlines13) 도구 및 아키텍처 패턴
Data Lake + DWH: 원격 측정을위한 "원시" 계층, 솔루션을위한 쇼케이스.
스트림 처리: 거의 실시간 SLI/번 레이트, 이상에 대한 온라인 기능.
Feature Store: 기능 재사용 (카나리아, 계절, 공급자 신호).
시맨틱 레이어/메트릭 스토어: 균일 한 메트릭 정의 (SLO, MTTR...).
액세스 제어: RBAC/ABAC, 세입자/지역의 행 수준 보안.
카탈로그/계보: 검색, 설명, 종속성, 소유자.
14) 점검표
14. 1 운영 분석 시작
- 승인 된 사전 SLI/SLO, SEV, 이유, 유형 변경.
- 이벤트 다이어그램 및 균일 한 우편 번호.
- 원격 측정 커넥터, ITSM, CI/CD, 공급자, 청구.
- 쇼케이스: SLI/SLO, 사건, 변경 사항, 공급자, FinOps.
- Executive/SRE/Change/Providers 대시 보드를 사용할 수 있습니다.
- 정원 경보 및 억제는 유지 보수 창에서 구성됩니다.
14. 2 주간 Ops 검토
- SEV 트렌드, MTTR/MTTD, SLO 누락, 화상 시간.
- 충격 및 CFR 변경, 롤백 상태.
- 공급자 사고 및 반응 시간.
- FinOps: $/단위, 로그 이상/탈출.
- CAPA 상태, 연체, 우선 순위.
15) 반 패턴
행동하지 않고 "그래프의 벽".
명령에 대한 메트릭의 다른 정의 (의미 계층 없음).
릴리스/창 주석 부족-원인의 속성이 약합니다.
p95/p99 대신 중간 방향.
볼륨에 대한 정규화는 없습니다. 대규모 서비스는 "더 나빠 보입니다".
통나무/상점 내 PII, 리텐 장애.
데이터는 "정체" 됩니다 (실시간 위젯의 경우> 5-10 분).
16) 구현 로드맵 (4-8 주)
1. 네드. 1: 메트릭 사전, 이벤트 체계, I- 상관 관계에 대한 계약; SLI/SLO 및 ITSM 연결.
2. 네드. 2: 사건/변경/제공자 쇼케이스, 주석 공개; 이그제큐티브 및 SRE 대시 보드.
3. 네드. 3: FinOps 층 ($/단위), SLI와의 인대; 정족수에 의한 이상 감지.
4. 네드. 4: 셀프 서비스 (시맨틱 레이어/미터법 저장소), 카탈로그 및 계보.
5. 네드. 5-6: 로드/비용 예측, 공급자에게보고, CAPA 쇼케이스.
6. 네드. 7-8: 보통 95% Tier-0/1, SLA 신선도는 5 분, 정기적 인 Ops 리뷰입니다.
17) 결론
운영 분석은 의사 결정 기계입니다. 지표의 균일 한 정의, 신선한 상점, 원인의 올바른 속성 및 플레이 북 및 SOP로의 직접 전환. 이러한 시스템에서 팀은 편차를 신속하게 감지하고 설명하며 릴리스 및 공급자의 영향을 정확하게 평가하고 비용을 관리하며 체계적으로 위험을 줄이며 사용자는 안정적인 서비스를받습니다.