Reliability · Observability · Engineering Leadership
Building reliable systems is both a technology and an organizational problem.
대규모 서비스를 운영하며 마주한 장애, 관찰 가능성, 비용과 조직의 문제를 기록합니다. 기술보다 판단의 기준과 그 결과에 집중합니다.
선별한 글
SRE가 개발 단계의 장애 예방에 집중하는 이유
운영에서 발견한 장애 패턴을 코드 검사로 옮기기 위해 CI 단계의 예방 체계를 검토한 경험
글 읽기02030405
고객 영향에 맞춘 점진적 배포 정책
고객에게 직접 영향을 줄 수 있는 롤에 점진적 배포를 필수로 적용해 전체 배포 후 롤백을 줄인 경험
Observability 플랫폼의 SLO는 어떻게 만들어야 할까?
로그와 메트릭 조회 성공률과 응답시간을 기준으로 만든 Observability 플랫폼 SLO
장애 대응 시간을 비교하려면 기록 기준부터 맞춰야 한다
장애 기록의 발생·인지·복구 시각을 같은 기준으로 맞추고 대응 시간을 비교한 경험
배치가 실패하면 장애일까?
시스템 이상(Failure)과 서비스 장애(Incident)를 구분하는 기준과 조직의 대응 수준을 실제 고객 영향에 맞추는 방법
최근 글
전체 글 보기010203040506
SRE가 개발 단계의 장애 예방에 집중하는 이유
운영에서 발견한 장애 패턴을 코드 검사로 옮기기 위해 CI 단계의 예방 체계를 검토한 경험
재발 방지 조치는 어디까지 확인해야 끝날까?
쿼리 수정 후 DB 송신량을 비교하며 변경 적용과 효과 확인을 구분한 경험
서비스 등급만으로 의존 관계의 위험을 알 수 있을까?
낮은 등급의 의존 서비스 때문에 주요 기능이 멈춘 장애와 요청별 의존 관계 검토
Loki의 스케일을 줄였는데 쓰기가 실패한 이유
RF를 2로 유지하는 Loki에서 스케일을 줄일 때 발생하는 쓰기 실패를 분석하고 개선안을 제안하는 과정
팀 성과를 티켓 수로 측정해도 될까?
비용 개선 작업을 마쳐도 팀 목표가 남았던 경험과 다음 업무의 우선순위를 정하는 기준
고객 영향에 맞춘 점진적 배포 정책
고객에게 직접 영향을 줄 수 있는 롤에 점진적 배포를 필수로 적용해 전체 배포 후 롤백을 줄인 경험