글
신뢰성(Reliability)과 관찰 가능성(Observability)을 운영하며 내린 결정들
대규모 시스템을 운영하며 겪은 문제와 그때 내린 결정을 씁니다.
2026
SRE가 개발 단계의 장애 예방에 집중하는 이유
운영에서 발견한 장애 패턴을 코드 검사로 옮기기 위해 CI 단계의 예방 체계를 검토한 경험
재발 방지 조치는 어디까지 확인해야 끝날까?
쿼리 수정 후 DB 송신량을 비교하며 변경 적용과 효과 확인을 구분한 경험
서비스 등급만으로 의존 관계의 위험을 알 수 있을까?
낮은 등급의 의존 서비스 때문에 주요 기능이 멈춘 장애와 요청별 의존 관계 검토
Loki의 스케일을 줄였는데 쓰기가 실패한 이유
RF를 2로 유지하는 Loki에서 스케일을 줄일 때 발생하는 쓰기 실패를 분석하고 개선안을 제안하는 과정
팀 성과를 티켓 수로 측정해도 될까?
비용 개선 작업을 마쳐도 팀 목표가 남았던 경험과 다음 업무의 우선순위를 정하는 기준
고객 영향에 맞춘 점진적 배포 정책
고객에게 직접 영향을 줄 수 있는 롤에 점진적 배포를 필수로 적용해 전체 배포 후 롤백을 줄인 경험
장애 대응에서 AI는 무엇을 해야 할까?
팀원이 개발한 Incident Agent 사례로 살펴본 장애 맥락 수집과 AI 분석 결과의 검증
공개된 메트릭만으로 DB의 한계를 판단할 수 있을까?
부하 테스트에서 확인한 여유와 운영 트래픽의 차이를 겪으며 관리형 DB의 보이지 않는 한계를 판단한 경험
Observability 플랫폼의 SLO는 어떻게 만들어야 할까?
로그와 메트릭 조회 성공률과 응답시간을 기준으로 만든 Observability 플랫폼 SLO
SRE 팀은 장애를 대신 해결해주는 팀이어야 할까?
중앙 SRE와 서비스 팀의 장애 대응 책임을 나누고 개별 대응을 조직의 역량으로 바꾸기 위해 정한 기준
장애 대응 시간을 비교하려면 기록 기준부터 맞춰야 한다
장애 기록의 발생·인지·복구 시각을 같은 기준으로 맞추고 대응 시간을 비교한 경험
로그를 오래 보관하는 것이 정말 Reliability에 도움이 될까?
모든 로그에 같은 보관 기간을 적용하지 않고 사용 목적과 감사 기준에 따라 나눠야 했던 이유
하루 수백 TB 로그 플랫폼을 운영하면서 알게 된 것
대규모 로그 플랫폼에서 Loki를 선택한 이유와 버퍼를 기준으로 자동 확장과 비용을 조정한 경험
장애 대응에서 복구와 원인 규명을 분리해야 하는 이유
장애 중에는 고객 영향을 먼저 줄이고 근본 원인 분석은 복구 이후에 끝내야 하는 이유
배치가 실패하면 장애일까?
시스템 이상(Failure)과 서비스 장애(Incident)를 구분하는 기준과 조직의 대응 수준을 실제 고객 영향에 맞추는 방법