이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
이커머스 시스템의 운영 효율을 개선하기 위해 가장 먼저 한 것은 배포 파이프라인 자동화였습니다. 수동 배포 절차가 많을수록 실수 가능성이 높아지고 배포 빈도도 줄어들기 때문에, CI/CD 파이프라인을 구성해 테스트 통과 후 자동 배포가 이뤄지도록 했습니다.
장애 대응 속도를 높이기 위해 가시성 체계를 강화했습니다. 핵심 지표에 알람을 설정하고, 대시보드 한 곳에서 서비스 상태를 확인할 수 있도록 구성했습니다. 장애가 발생하면 어느 구간에서 문제인지 빠르게 파악하는 것이 사용자 영향을 줄이는 핵심이었습니다.
SLO를 정의한 것도 운영 문화를 바꿨습니다. 응답 시간·가용성·오류율 목표를 수치로 정하면 팀이 같은 기준으로 운영 판단을 할 수 있었고, 현재 상태가 목표에서 얼마나 벗어났는지를 객관적으로 파악할 수 있었습니다.
같은 장애가 반복되면서 매번 같은 순서로 슬랙을 뒤지는 상황이 불편했습니다. 어떻게 대응했는지 기억에 의존하다 보니 대응 시간이 사람마다, 시간대마다 달랐습니다. 그래서 제가 직접 주요 장애 유형별 대응 순서를 런북 문서로 정리하는 작업을 맡았습니다. DB 커넥션 풀 고갈, 캐시 미스 급증, 배포 직후 오류율 상승 세 가지 시나리오를 먼저 다뤘습니다.
Slack 봇을 활용해 알람이 울리면 해당 런북 링크가 자동으로 스레드에 붙도록 연결했습니다. 팀원들이 온콜 도중 런북을 따라가면서 대응하니 조치 시작까지 걸리는 시간이 눈에 띄게 줄었다는 피드백을 받았습니다. 런북은 쓰는 것보다 실제 장애에서 한 번 쓰이면서 개선되는 것이 더 중요하다는 걸 알았습니다.
처음 모니터링을 구성했을 때 알람이 너무 많이 울려서 정작 중요한 경고를 놓치는 상황이 됐습니다. 온콜 중 알람 40건 중 30건이 자정 이후에 일시적으로 올라갔다 내려오는 거짓 양성이었습니다. MTTR을 측정해보니 실제 장애 시작부터 조치까지 평균 23분이었는데, 대부분은 어떤 알람이 진짜인지 파악하는 데 시간을 쓴 것이었습니다.
Datadog 다운타임 설정으로 야간 배치 작업 시간대 알람을 억제하고, 임계치를 고정값 대신 이상 감지 알고리즘으로 바꿨습니다. 2주 후 측정하니 False Positive 비율이 75%에서 30%로 줄었고, MTTR도 23분에서 11분으로 단축됐습니다. 알람을 줄이는 것이 감지를 약화시키는 게 아니라 더 빠른 대응을 가능하게 한다는 걸 수치로 확인했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.