이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 장애가 나야만 알 수 있는 구조로 운영되던 서비스를 맡았습니다. 에러가 나도 로그를 직접 찾아야 했고, 응답 시간 추이를 볼 방법이 없었습니다.
Prometheus로 에러율, 응답 시간 P50/P95, 활성 요청 수를 수집하고 Grafana 대시보드를 만들었습니다. 처음엔 알람 기준이 없어 에러가 1개만 나도 알람이 울려 팀이 알람 피로도를 호소했습니다. 에러율 기준으로 바꾸고 5분 집계 창을 두니 오탐이 줄었습니다.
가용성 지표로는 업타임 체크를 1분 간격으로 추가해 서비스가 아예 내려간 경우를 즉시 감지하게 했습니다. 모니터링 이전엔 장애를 사용자가 먼저 알았는데, 이후엔 내부에서 먼저 인지하게 됐습니다. 가시성은 곧 대응 속도라는 걸 그때 배웠습니다.
팀 프로젝트에서 서비스 알람을 처음 붙였을 때 하루 50건 이상 알람이 울렸습니다. 모두 진짜 이상이 아니라 일시적 스파이크였는데, 팀이 알람을 보지 않게 됐습니다. 알람이 너무 많으면 없는 것과 같다는 걸 직접 경험했습니다.
알람을 3등급으로 분류했습니다. 즉시 대응이 필요한 것은 슬랙 #alert-critical, 확인이 필요한 건 #alert-warning, 참고용은 대시보드에만 표시하는 방식으로 나눴습니다. 슬랙 알람 수가 하루 4건 이하로 줄었고, 그때부터 팀이 알람을 진지하게 보기 시작했습니다.
알람 고도화에서 '어떤 상황에 누가 깨어나야 하는가'를 먼저 정하는 것이 핵심이라는 걸 배웠습니다. 기술보다 운영 시나리오 정의가 먼저라는 것이 지금도 제 기준입니다.
사이드 프로젝트에서 '우리 서비스는 얼마나 안정적인가'를 수치로 말할 수 없는 상황이었습니다. 장애가 나면 '자주 나는 것 같다'고만 느꼈지 얼마나 자주인지 몰랐습니다.
월간 가용성을 측정하기 시작했습니다. 헬스체크 엔드포인트를 1분마다 호출해 성공률을 기록하고, 월 기준 99.5% 목표를 세웠습니다. 첫 달 데이터가 98.1%로 나왔는데, 가장 큰 다운타임이 배포 중 재시작 시간이었습니다.
무중단 배포 방식으로 전환하니 가용성이 99.7%로 올랐습니다. 수치가 없었다면 원인을 찾으러 갈 이유조차 없었을 것입니다. 가시성은 목표 수치를 세우는 것에서 시작한다는 걸 그때 처음 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.