S(*). Architect

학습 목표메트릭·로그가 AIOps에서 서로 다른 intelligence 역할을 한다는 점을 설명할 수 있다.log classification으로 노이즈·카테고리·심각도를 구조화할 수 있다.metric correlation·lag로 연관 지표·선행 신호를 찾을 수 있다.embedding search로 유사 로그·incident 검색 패턴을 설명할 수 있다.intelligence 출력이 detect·correlate 단계로 어떻게 넘어가는지 연결할 수 있다.문제 상황Loki 수백만 줄/분 — grep ERROR만으로는 원인·우선순위 없음NullPointerException과 connection reset이 같은 severity로 pagelatency alert 때 어느 메트릭부터 볼지 모름 — CPU·DB·..

학습 목표point·contextual·collective 이상을 구분하고 메트릭에 맞출 수 있다.rolling baseline·z-score·MAD로 단변량 이상탐지를 구성할 수 있다.seasonality를 분해해 요일·시간 패턴의 false positive를 줄일 수 있다.isolation forest로 다변량·unsupervised 이상탐지를 설명할 수 있다.score → threshold → alert 연결과 precision·recall 트레이드오프를 판단할 수 있다.문제 상황cpu > 80% static rule — 매일 점심 피크에 false positive, on-call 무시 습관야간 배치 시간 정상 스파이크를 매번 page — contextual 개념 없음error rate가 천천히 상..

학습 목표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개 서비스마다 복붙 — 임계값 튜닝에..

이 글의 목적관측성 기초 본편 14편을 마쳤다. 이 글은 시리즈 전체를 압축·연결하고 다음에 어디로 갈지 짚는 에필로그다.14편 동안 본 개념을 한 장 지도로 다시 본다관측성에서 뻗어 나가는 주제와 블로그 내 다른 시리즈를 연결한다관측 지식이 어떤 직업·역할과 맞닿는지 정리한다손으로 확인하는 방법과 읽을거리를 남긴다1. 14편이 만든 큰 그림관측성은 알람 하나가 아니라 로그·메트릭·트레이스를 상관해 “왜?”에 답하는 능력이다.Part핵심 질문기억할 키워드0 오리엔테이션Monitoring과 Observability 차이는삼각형, unknown-unknown, correlation1 로그무슨 일이 일어났나JSON, pipeline, trace_id, tail·filter2 메트릭얼마나·얼마나 자주RED/US..

학습 목표AIOps와 MLOps가 각각 운영 신호와 모델 프로덕션에서 무엇을 담당하는지 구분할 수 있다.signal → detect → respond → train → serve → monitor 운영·ML 루프를 그릴 수 있다.Observability·Platform·DataAI·Security와 본 시리즈의 역할 분리를 설명할 수 있다.이상탐지·LLM copilot·MLflow·K8s serving·drift 등 키워드가 로드맵 어느 Part에 있는지 짚을 수 있다.18편 로드맵을 보고 학습 순서를 잡을 수 있다.문제 상황Prometheus 알람 하루 500건 — on-call 피로, 진짜 장애는 그중 3건runbook은 wiki에 있는데 page 때 어디서부터 읽을지 모름 — RAG·LLM 도입 논..