예시 답변 1
약 96초
장애 대응 절차·경험 중심으로 푸는 결
인턴 기간에 서비스 응답이 느려지는 장애 상황을 팀과 함께 대응한 경험이 있습니다. 제가 담당한 것은 로그 수집과 상황 공유였습니다. 장애 인지는 모니터링 알림으로 먼저 들어왔고, 담당자들이 Slack에 모여 현상을 공유했습니다. 이후 특정 API 응답 시간이 급격히 늘어난 것을 확인하고, DB 쿼리 실행 시간을 먼저 확인했습니다. 특정 쿼리에서 풀 스캔이 발생하고 있었고, 임시 조치로 트래픽을 줄이는 동시에 해당 쿼리를 수정했습니다. 복구 후에는 동일 원인이 다른 쿼리에서도 발생할 수 있는지 점검하고, 결과를 간략한 사후 보고서로 남겼습니다. 장애 대응에서 중요한 것은 원인보다 현상을 먼저 파악하고 빠르게 공유하는 것이라는 것을 그때 배웠습니다.
이 결의 특징
모니터링 알림으로 인지한 뒤 응답 시간 급증을 확인하고 DB 쿼리 실행 시간을 먼저 짚어 풀 스캔을 찾아낸 순서가 구체적입니다. 원인보다 현상을 먼저 파악해 빠르게 공유하는 것을 핵심으로 삼은 지점에서 실무 감각이 비칩니다.
이 결이 통하는 자리
트래픽 축소라는 임시 조치와 쿼리 수정이라는 근본 조치를 함께 놓고, 동일 원인이 다른 곳에도 있는지 점검한 사후 보고서로 마무리될 때 통합니다. 인지-대응-복구-회고 각 단계가 실제 조치로 채워진 자리에서 면접관의 추가 질문이 줄어드는 결이 보입니다.