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

학습 목표운영 로그와 감사(audit) 로그의 목적·필드·보존 차이를 설명할 수 있다.PII·시크릿이 로그에 유입되는 경로와 마스킹·수집 전 필터 패턴을 설명할 수 있다.인증·인가·관리 이벤트를 감사 로그로 남기는 기준을 설명할 수 있다.trace_id·correlation_id로 Observability와 보안 조사를 연계할 수 있다.보존·접근 통제·SIEM 연동 개요를 설명할 수 있다.문제 상황로그인 실패 수천 건 — 누가·언제·어느 IP인지 집계 불가 (비구조화)logger.info(f"user email={email} card={pan}") — PII·카드 번호 평문 저장GDPR 삭제 요청 — 로그에 이메일 잔존·검색 불가관리자 role 변경 기록 없음 — 내부 어뷰 추적 실패13편 시크릿이 ac..

이 글의 목적관측성 기초 본편 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 도입 논..

학습 목표K8s 메트릭 3층(클러스터 상태 · 컨테이너 자원 · 앱 RED)을 구분해 설명할 수 있다.kube-state-metrics와 cAdvisor(kubelet 경유)가 무엇을 노출하는지 설명할 수 있다.metrics-server(HPA)와 관측 스택(Prometheus)의 역할 차이를 설명할 수 있다.Prometheus kubernetes_sd·ServiceMonitor로 K8s target을 scrape하도록 구성할 수 있다.장애 triage에서 어느 층의 메트릭·로그·트레이스를 먼저 볼지 판단할 수 있다.문제 상황kubectl get pods — 모두 Running — 그런데 checkout 5xx 100%Pod phase와 앱 SLI는 다른 신호Grafana CPU 패널 90% — on-c..

학습 목표Elastic Stack(ELK) 구성 요소와 source → ingest → index → visualize 흐름을 설명할 수 있다.Elasticsearch·Logstash·Kibana·Beats와 Elastic Cloud가 각각 어떤 역할을 담당하는지 구분할 수 있다.관측성 시리즈에서 본 로그 파이프라인·ELK vs Loki 개요와 본 시리즈의 심화 범위 차이를 설명할 수 있다.ILM·data stream·Fleet 등 프로덕션 키워드가 시리즈 어디에서 다루어지는지 짚을 수 있다.22편 로드맵을 보고 학습 순서를 잡을 수 있다.문제 상황JSON 로그는 앱에서 잘 쓰는데, 검색은 여전히 grep — 중앙 저장·UI가 없다Filebeat를 깔았더니 Elasticsearch 샤드·디스크가 금방 찬..

학습 목표인시던트 lifecycle(detect → mitigate → resolve → learn)을 설명할 수 있다.Severity(SEV1~4) 기준으로 page vs ticket·에스컬레이션을 구분할 수 있다.Runbook 구조·alert annotation 연결을 설계할 수 있다.Incident Commander·온콜·커뮤니케이션 역할을 설명할 수 있다.Blameless postmortem에서 타임라인·근본 원인·action item을 작성할 수 있다.문제 상황burn rate page — Slack에서 “뭐부터?” 없음runbook URL 404·6개월 전 스크린샷SEV 정의 없음 — “큰 장애”마다 누구를 깨울지 감으로on-call 1인 — mitigate + comms + root caus..

학습 목표SLI · SLO · SLA 차이를 설명하고 각각 누가 정의·측정하는지 구분할 수 있다.Error budget(허용 실패량)이 99.9% 같은 목표에서 어떻게 계산되는지 설명할 수 있다.Burn rate로 budget을 얼마나 빠르게 태우는지 측정·알람할 수 있다.Prometheus PromQL로 availability SLI·budget remaining·burn rate를 표현할 수 있다.Error budget 정책(배포 freeze, incident 우선)을 팀과 합의할 수 있다.문제 상황SLA 99.9% 계약 — 장애 후 “이번 달 몇 % 남았지?” 아무도 모름가용성 감은 있는데 숫자·정책이 없다알람이 CPU 80%·pod restart — 사용자 체감과 불일치5xx rate는 오는데 o..