AIOps 개요

학습 목표

AIOps가 IT 운영 신호에 AI·ML을 적용해 toil·노이즈를 줄이는 접근임을 설명할 수 있다.

signal과 noise를 구분하고 alert flood가 on-call에 미치는 영향을 설명할 수 있다.

rule-based alert와 ML-based detection의 트레이드오프를 판단할 수 있다.

ingest → enrich → detect → correlate → respond AIOps 파이프라인을 그릴 수 있다.

Observability SLO·burn rate 알람과 AIOps 보완 관계를 설명할 수 있다.

문제 상황

• Prometheus Alertmanager 하루 480건 — pager 무시 습관화, 실제 장애 3건 놓침
• cpu > 80% rule 50개 서비스마다 복붙 — 임계값 튜닝에 주 1일
• 야간 계절성 트래픽에 매일 false positive — static threshold 한계
• 동일 root cause인데 12개 alert가 따로 옴 — correlation 없음
• runbook 열기 전에 어느 메트릭부터 볼지 20분 — context 수집 toil
• “AIOps 도입”만 외치고 신호 품질·SLO 정리 없이 ML 모델부터 — 효과 없음
• Observability에서 burn rate는 썼지만 — 노이즈·그룹핑은 여전히 pain

오리엔테이션에서 AIOps·MLOps 루프를 봤다. 이번 편은 AIOps가 왜 필요한지 — signal vs noise, rule vs ML, toil. 이상탐지 알고리즘은 3편, incident correlation은 5편이다.

1. AIOps란?

AIOps — 메트릭·로그·트레이스·알림·incident 데이터에 ML·자동화·(선택) LLM을 적용해 운영 의사결정을 빠르고 정확하게 만드는 접근.

목표	내용
Noise reduction	false positive·중복 alert 감소
Signal amplification	진짜 사용자 영향·이상에 집중
Toil reduction	반복 트리아지·컨텍스트 수집 자동화
Faster MTTR	correlation·hint로 원인 좁히기

• Observability — 신호 수집·저장·SLO (선행)
• AIOps — 신호 위에서 지능 (detect·correlate·prioritize)
• MLOps — 모델 프로덕션 (본 시리즈 Part 3~)
• AIOps ≠ 모든 것을 LLM — rule 정리·SLO가 먼저인 경우가 많음

2. Signal vs Noise

	Signal	Noise
정의	조치 또는 의사결정에 도움	alert만 쌓이고 행동 없음
예	SLO burn, error rate 급증	idle CPU spike, known deploy
on-call	page 정당	피로·missed real incident

Raw events (metrics · logs · traces)
    → curated signals (SLO · SLI · golden signals)
    → alert rules / anomaly models
    → incidents (actionable)  vs  noise (suppress · tune)

• Alert fatigue — noise가 많으면 모든 pager를 무시
• Symptom vs cause — symptom alert는 많고 cause는 하나 — correlation 필요 (5편)
• Actionable — Google SRE: “이 alert로 뭘 할지” 없으면 rule 삭제 검토

노이즈가 늘 때 흔한 원인

원인	예
Static threshold	피크·요일 패턴 미반영
Missing context	deploy·scale event 무시
Alert per symptom	CPU·latency·error 각각 page
No ownership	team=unknown route
SLO 없음	사용자 영향 없는 지표 alert

3. Toil reduction

Toil — 반복·수동·자동화 가치 있는 운영 작업 (SRE).

Toil 예 (AIOps 전)	AIOps 방향
alert 50건 수동 확인	grouping·dedup
대시보드 10개 열어 비교	correlation·topology
runbook 검색	RAG·copilot (6~7편)
임계값 주간 수정	baseline·seasonality (3편)
postmortem 타임라인 수작업	event 타임라인 자동

• toil 0이 목표는 아님 — 판단·승인은 human
• 자동 remediation — guardrail·approval 없으면 위험 (8편)
• AIOps ROI — on-call 시간·MTTR·false positive rate로 측정

4. Rule-based alerting (기선)

Observability에서 이미 쓰는 rule — AIOps의 기반이자 비교 대상.

# code/prometheus-alert-slo.yaml (발췌)
groups:
  - name: api-slo
    rules:
      - alert: ApiHighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m])) > 0.05
        for: 10m
        labels:
          severity: page
          service: order-api
        annotations:
          summary: "5xx rate above 5% for 10m"
          runbook_url: "https://wiki.example/runbooks/order-api-5xx"

rule 장점	rule 한계
해석 가능	계절·트렌드 수동 반영
예측 가능	cardinality 폭발 시 rule 폭증
감사·컴플라이언스	새 패턴 미탐
SLO burn와 잘 맞음	다변량 이상 어려움

• Burn rate alert — error budget 소진 속도 (Observability)
• for: 10m — flapping 감소
• labels — service, severity, team — routing·correlation의 입력

5. Rule vs ML

	Rule-based	ML-based
조건	명시적 expr·threshold	데이터에서 패턴 학습
해석	쉬움	모델·feature 설명 필요
적합	SLO·hard limit·known symptom	seasonality·multivariate·unknown
운영	rule PR·review	retrain·drift·데이터 품질
실패	threshold 틀림	false negative·블랙박스

언제 rule을 유지할까

• 사용자 영향 명확 — availability·latency SLO
• 규제·계약 — “5xx > 5%” 문서화 필요
• 희귀 이벤트 — “결제 실패 > 0” — ML보다 단순 rule

언제 ML을 검토할까

• threshold 매주 손보는 메트릭
• 다차원 — CPU+latency+queue 동시 이상
• 로그 패턴 분류·유사 incident 검색 (4편)
• 충분한 과거 데이터·라벨(또는 unsupervised)
• Hybrid — rule로 page, ML로 ticket·early warning
• ML 도입 전 — 신호 정리·중복 rule 제거·SLO 정의

6. AIOps 파이프라인 개요

단계	역할	예
Ingest	메트릭·로그·alert·change event 수집	Prometheus, Loki, Alertmanager webhook
Enrich	metadata — service, deploy, topology	K8s labels, CMDB, trace link
Detect	rule·anomaly·threshold	PromQL, isolation forest (3편)
Correlate	alert 그룹·root cause hint	time window, topology (5편)
Respond	route·runbook·ticket·(선택) auto	PagerDuty, LLM copilot (6편)

Alertmanager → webhook → enrich (deploy tag)
    → correlate (same service · 5m window)
    → one incident "order-api degradation"
    → runbook link · on-call

• Closed loop — incident 피드백으로 rule·model 튜닝
• Change correlation — deploy 직후 alert는 severity down 또는 suppress
• 벤더 AIOps 플랫폼 — 위 단계를 패키지; 원리는 동일

7. 실무 체크리스트

#	질문
1	이 alert로 on-call이 무엇을 하는가
2	SLO 없는 symptom-only page가 있는가
3	동일 incident에서 alert 수가 몇 개인가
4	rule 튜닝 빈도가 비정상적으로 높은가
5	deploy·scale context가 alert에 붙는가
6	ML 도입 전 신호·라벨 품질이 있는가

# code/alert-routing.labels.yaml (발췌)
routing_labels:
  required:
    - service
    - team
    - severity
  optional:
    - runbook_url
    - slo
annotation_standards:
  summary: "user-facing one line"
  description: "what to check first"
  runbook_url: "wiki link"

정리

• AIOps — 운영 신호 위 intelligence로 noise·toil 감소
• Signal — actionable; noise — tune·suppress·delete
• Rule — SLO·명확 symptom에 1차; ML — seasonality·multivariate·패턴
• 파이프라인 — ingest → enrich → detect → correlate → respond
• Observability 수집·SLO는 전제 — AIOps는 대체가 아님

다음에 다룰 것

• 이상탐지 기초
• statistical baseline, isolation forest, seasonality

---

해당 내용은 Google SRE Workbook (Alerting on SLOs), Chappell et al. — AIOps concepts 를 기반으로 합니다.