4주차에서 Metrics / Logs / Traces 개념을 배웠다. 이번엔 그걸 실제로 어떻게 구축하는지다. Prometheus는 Pull 방식으로 메트릭을 수집한다. 서비스가 메트릭을 보내는 게 아니라 Prometheus가 주기적으로 가져간다. 서비스 →

마이크로서비스 환경에서 서비스가 수십 개가 되면 서비스 간 통신이 복잡해진다. 각 서비스가 직접 다른 서비스를 호출하는데, 이때 문제가 생긴다.어떤 서비스가 어디로 트래픽을 보내는지 보이지 않는다서킷 브레이커, 재시도 로직을 서비스마다 따로 구현해야 한다서비스 간

기능이 완성됐다고 바로 프로덕션에 올리면 안 된다. 모니터링이 없거나, On-call 담당자가 없거나, 장애 대응 절차가 없는 상태로 나가면 첫 장애 때 아무것도 못 한다. PRR은 서비스가 프로덕션에 나갈 준비가 됐는지 체계적으로 검토하는 프로세스다. Obse

둘 다 개발과 운영의 간극을 줄이는 게 목적이지만 접근 방식이 다르다. DevOps가 "무엇을 해야 한다"라면 SRE는 "어떻게 한다"다. Google이 DevOps를 구체적으로 실현하기 위해 만든 것이 SRE다. Toil은 수동적이고 반복적이고 자동화 가능한

클라우드를 쓰면 비용이 눈에 안 보인다. 서버를 켜두고 잊어버리거나, 필요 이상으로 큰 인스턴스를 쓰거나, 아무도 안 쓰는 리소스가 돈을 먹고 있다. FinOps는 클라우드 비용을 최적화하고 비용 대비 가치를 높이는 것이다. 단순히 비용을 줄이는 게 아니라 SLO를

개발자가 인프라를 직접 다루려면 배워야 할 게 너무 많다. K8s 설정, CI/CD 파이프라인, 모니터링 연동, 보안 정책... 이걸 개발자마다 각자 하면 비효율적이고 실수도 많다. Platform Engineering은 개발자가 인프라를 직접 몰라도 쉽게 쓸 수

컨테이너 환경은 기존 서버 환경과 다르다. Pod가 언제든 죽고 다시 생기고, IP가 바뀌고, 스케일이 자동으로 오르내린다. 기존 방식으로 모니터링하면 놓치는 게 많다. 핵심 차이는 수명과 동적 변화다. 기존 환경은 "이 서버의 CPU가 높다"처럼 대상이 명확하다

장애는 막을 수 없다. 대신 장애가 전파되지 않게 막거나, 부분적으로만 동작하거나, 빠르게 회복하도록 설계할 수 있다. 그게 Reliability Patterns의 목적이다. 문제가 생긴 서비스로의 요청을 자동으로 차단해서 장애 전파를 막는 패턴이다. 실패율이

서비스 장애의 70% 이상은 변경(Change)에서 발생한다. 새 기능 배포, 설정 변경, 인프라 업그레이드 — 전부 변경이다. Change Management는 변경으로 인한 장애를 최소화하기 위한 프로세스다. 변경을 막는 게 아니라, 변경을 안전하게 하는 것이

알림 기준을 어떻게 정할 건지가 문제다. CPU 75%면 알림? 에러율 1%면 알림? 이 숫자들이 감으로 정해진 거라면 SLO 달성과 직접 연결이 안 된다. SLO 기반 알림은 SLO와 Error Budget을 기준으로 알림을 설계하는 방식이다. Error Bu

시스템이 "잘 돌아가고 있다"는 건 장애가 없는 게 아니라 장애가 와도 버틸 수 있다는 뜻이다. Chaos Engineering은 그걸 미리 검증하는 방법이다. 한 줄 정의: 의도적으로 장애를 만들어서 시스템의 약점을 먼저 찾는 것 Netflix가 처음 만든 개

On-call은 서비스 장애가 발생했을 때 즉시 대응할 수 있는 당직 체계다. 24시간 365일 서비스를 운영하면 언제든 장애가 터질 수 있는데, 그때 "누가 받을 건데?"를 미리 정해두는 것이다. 개발자 한 명이 항상 대기하는 게 아니라, 팀원들이 돌아가면서

Capacity Planning 장애가 나고 나서 서버를 늘리는 게 아니라, 미리 예측해서 준비하는 방법에 대한 내용이다. 한 줄 정의는 이렇다."미래의 트래픽을 예측해서 서버 용량을 미리 준비하는 것" 준비가 안 됐을 때와 됐을 때의 차이는 명확하다. ❌ 준

서비스를 수치로 정의하는 개념이다. SLI는 현재 서비스 상태를 측정한 수치고, SLO는 팀 내부에서 유지해야 하는 목표값이다. SLA는 그 목표를 고객과 계약으로 맺은 것으로, 위반하면 패널티가 생긴다. 쉽게 기억하는 방법은 이렇다. SLI → 지금

인시던트가 뭔가 서비스 품질이 저하되거나 중단되는 사건이다. 중요한 건 발생했을 때 표준화된 절차로 대응하는 것이다. --- 인시던트 대응 5단계 | 단계 | 설명 | |---|---| | Detection (감지) | 알림으로 장애 인지

나쁜 알림 설계의 가장 큰 부작용이다. 알림이 너무 많으면 → 팀원이 알림에 무감각해짐 → 진짜 중요한 알림도 무시하게 됨 → 실제 장애를 늦게 발견 → 서비스 다운 알림의 신뢰도를 유지하는 것 자체가 SRE의 중요한 역할이다. ❌ 나쁜 알림 CPU

Observability(관측 가능성) 처음엔 모니터링이랑 같은 말인 줄 알았는데 달랐다. 모니터링: "CPU가 80%다" → 미리 정해둔 지표를 보는 것 Observability: "왜 저 요청만 느린 거지?" → 어떤 질문이든 데이터로 답할 수 있는 것 모니

한 줄 정의"자동화할 수 있는데 사람이 손으로 반복하고 있는 작업" 단순히 귀찮은 일이 아니다. Toil로 분류되려면 6가지를 만족해야 한다. 처음에 헷갈렸던 부분이다. ✅ Toil 맞음서버 추가할 때마다 설정 파일 직접 수정배포할 때마다 같은 체크리스트 수동

지난 글에서 SLI / SLO / SLA를 정리했다. 이번엔 SLO를 배우고 나면 자연스럽게 나오는 질문, "그래서 얼마나 실패해도 되는 거야?" 에 대한 답인 Error Budget을 정리해본다. SLO를 정하고 나면 팀 안에서 이런 상황이 생긴다. SRE팀:

SRE가 뭔데 Google이 2003년에 만든 직군이자 운영 방법론이다. 핵심은 이 한 문장이다. > "소프트웨어 엔지니어링 방식으로 운영 문제를 해결한다" 기존에는 개발팀이 코드를 만들면 운영팀이 서버를 관리하는 구조였는데, 서비스가 커질수록