장애 해결 및 사후 처리

Kenneth·2021년 11월 27일
0

지난달 말, 우리 팀에서 맡은 서비스가 1시간가량 사실상 중단되는 큰 장애가 있었다. 장애 해결 과정에서부터 사후처리까지 굉장히 소중한 경험이었기 때문에 기록으로 남기고자 한다.

경과

장애 발생

다른일로 빠른 퇴근을 준비하던 어느 오후, 모니터링 시스템에서 갑자기 404 알림을 보내기 시작했다. 정상적인 서비스 요청에 404가 대량으로 나가기 시작한 것이다. 장애 직전에도 배포는 없었고, 마지막으로 배포한지도 한참 된 안정적으로 운영되던 서버에서 갑자기 장애가 발생한 것이다.

이 서비스는 다른 서비스의 Proxy 역할이 주인 서비스기 때문에, 자체적인 장애가 발생하는 경우는 드물다. 그렇기에 평소처럼 특정 도메인 피쳐가 문제가 되는지부터 살펴보았고, 전체장애로 의심이 되어 다른 지표들을 보기 시작했다. 그러나 이번 장애의 정확한 원인을 특정할 수 있는 지표가 세팅되어 있지 않았고, 원인 진단을 위해 짚이는데서부터 찾아보기 시작했다.

그와 동시에 War Room이 개설되었다. 줌 채널에 나부터 이쪽의 임원까지, 현장 운영쪽 담당자들부터 그쪽 임원까지, 그 외 PO/PM 등 주요 의사결정자들과 실무자들이 모두 들어와 실무자들 (나와 팀원들)이 문제를 해결하고 영향받는 모든 파트와 커뮤니케이션 할 수 있도록 모였다.

원인 진단에 시간이 걸렸지만 30분만에 문제를 찾는데 성공했고, 적절한 조치로 빠르게 문제를 해결하였다.

장애 직후

가장 직접적인 문제는 발견했다. 어플리케이션 로직 상 데이터에 문제가 생길 수 있는 가능성이 있었고, 이로 인해 데이터가 잘못될 경우 서버가 정상적으로 뜨지 못하는 상황이었다. 일단 임시로 데이터를 수정하는 식으로 급한 불은 껐지만, 재발할 가능성이 존재했다. 밤까지는 모니터링 대시보드를 수시로 확인했고, 다음날 오전 이 문제를 가장 먼저 수정했다.

그러나 이것만으로 요번 인시던트를 전부 설명할 수는 없었다. 놓치고 있는 무언가가 있었다.

목요일 저녁에 문제가 발생했고 자세한 조사 및 후속조치에 대한 미팅이 바로 월요일에 예정되어 있었기에, 주말에 시간을 내서 조사했고, 놓치고 있던 그 무언가를 발견해냈다. 살아있는 서버가 있었는데, 죽은 서버로 요청이 라우팅됐다는 중대한 문제가 있었다.

이에 대해 문서를 정리해서 미팅에서 공유했고, 다른 엔지니어분들 피드백을 받아 문제에 대한 자세한 설명과 후속 조치 항목들을 준비하였다.

그 후

사고 규모가 컸기 때문에 정리된 내용으로 임원 보고가 있었고, 이어서 같은 내용으로 테크조직 내에 한번 더 발표를 진행했다. 공통적인 관심영역에 있는 문제였고, 다른 팀에서도 얼마든지 일어날 수 있는 사고였기 때문에 다른 주제들보다 많은 관심을 받았다.

다른 업무가 많아 일부 중장기 사후조치는 더 뒤로 유보하게 되었다.

배운 점

War Room

문제 해결을 위한 방. 어떤 것들이 문제가 되고 있고, 어떻게 해결을 진행하고 있는지 등등 사건과 관련한 주요 의사소통 및 의사결정이 모두 이 안에서 일어난다.

실무자들이 주도적으로 최대한 빠르게 문제를 해결할 수 있도록 필요한 지원이 즉시 이루어진다. 누군가는 사건 타임라인을 정리하고, 누군가는 협조가 필요한 다른 팀의 담당자를 호출하고, 누군가는 늦게 들어온 누군가가 반복하는 질문에 대신 대답을 해주고, 누군가는 결정이 필요한 부분에 대해 바로 결정해주고, 누군가는 실무자들이 정확한 우선순위로 해결 수순을 밟도록 가이드를 제공한다.

정확한 원인을 파악하고 조치를 취해야 한다

정확한 원인을 발견하지 못한 상태로 장애 상태가 계속되자 무언가 조치를 취해야겠다는 압박감과 혹시나 하는 생각으로 서비스를 전체 재배포하는 조치를 취했다. 나 혼자만의 결정은 아니었지만, 적극 동의했다. 결과적으로 문제를 해결하지도 악화시키지도 않았지만, 오히려 문제 발견에 도움이 되었지만, 자칫 잘못했다면 문제를 악화시킬 수도 있었다.

profile
개발자 + @

0개의 댓글