서비스 장애가 발생했을 때 PM은 뭘 해야 할까
장애 대응을 겪으며 온몸으로 배운 것들
1.
IT 서비스에서 일하다 보면 피할 수 없는 것들이 있다. 그중에 하나가 바로 서비스 장애 대응이다. 서비스 장애나 상용 환경에서의 이슈가 없다면 좋겠지만 이건 현실적으로 불가능하다. IT 서비스를 만드는 사람들이 모든 경우의 수를 다 고려해서 프로덕트를 만들 수도 없는 노릇이고, 또 유저들이 사용하는 실제 상용 환경에서는 어떤 일이 발생할지 아무도 모른다. 서비스 장애, 상용 환경에서의 이슈는 작은 조직 혹은 프로덕트에서만 일어나는 것도 아니고, 네카라쿠배당토라고 하는 큰 서비스들에서도 생긴다.
2.
그래서 테크 기업들의 기술 블로그 혹은 개발자들의 개인 블로그를 보면 장애 대응 회고 관련 아티클을 많이 볼 수 있다. 아마 상용 환경에서의 서비스 장애 혹은 이슈를 가장 직접적으로 해결하는 직군이기 때문이다. 다만 PM 입장에서 장애 혹은 이슈가 발생했을 때 어떻게 대응해야 하는지에 대한 글은 생각보다 많이 없다. 그래서 지금 회사에서 겪은 장애 대응 경험들을 바탕으로 PM은 장애가 발생하면 뭘 해야 하는지에 대해서 좀 써보려고 한다.
3.
서비스 장애는 보통 유저의 문의로부터 알아차리는 경우가 많다. 예를 들어 '결제가 돼서 돈이 빠져나갔는데, 아이템은 들어오지 않아요', '결제를 시도하는 데 자꾸 안 돼요' 등의 문의가 들어오는 것으로 시작된다. 서비스 장애가 발생했다면 가장 먼저 해야 할 일은 전사적으로 장애가 발생했다는 것을 공유하고, 긴급 상황으로 장애 대응 모드에 돌입해야 한다는 것을 알려야 한다.
4.
우선 유저 대응을 하는 팀에는 장애를 좀 더 정확하게 파악하기 위해서 유저에게 더 상세한 이슈 현상을 보내달라고 요청한다. 보통 유저들은 이슈를 상세하게 전달하지 않기 때문에, 날 것의 유저 문의로는 어느 부분에 대해서 정확히 어떤 장애인지 파악하기 힘들다. 정확한 현상을 알 수 없다면 원인 파악도 어렵고, 결국 문제 해결에 더 오랜 시간과 노력이 들 수밖에 없다. 그래서 보통 이 때는 스크린샷 혹은 영상, 사용하는 기기의 기종 및 OS 버전, 프로덕트 버전을 함께 요청하는 게 좋다. 그래야 어떤 상황에서 해당 문제가 발생했는지를 좀 더 정확하게 확인할 수 있다.
5.
이와 동시에 개발팀에게는 유저들의 문의를 정리해서 공유하며, 장애 현황에 대해 공유하며 이와 동시에 다른 유저들이 동일한 장애를 겪지 않게 하기 위해서 어떤 방법이 필요한지를 물어본다. 서비스 장애를 겪은 유저들이 많으면 많을수록, 장애 대응 이후 운영 대응의 업무가 엄청나게 늘어나기 때문이다. 또한 해당 이슈를 해결하기 위해 긴급 대응 요청을 한다.
6.
보통 상용 환경에서의 서비스 장애의 경우 새로운 기능이나 코드를 배포한 이후에 발생한다. 그래서 동일한 장애를 다른 유저들이 겪지 않게 하기 위해서는 해당 기능을 이용하지 않게 공지를 올리거나, 해당 기능을 사용하지 못하도록 막거나, 롤백을 해서 이전 문제없는 버전으로 돌려야 한다. 정말 최악의 경우에는 서비스를 잠시 중단을 해야 할 경우도 있다.
7.
긴급 대응 요청을 할 때 중요한 것은, 특정 시간마다 주기적으로 상황에 대해서 공유하고 현황을 업데이트하기로 약속하는 것이다. PM은 해당 이슈가 어떤 부분에서 발생했고, 또 언제 해결될지, 어떤 것을 해야 해결할 수 있을지 개발자만큼 정확하게 알 수 없다. 따라서 개발자에게 이슈 대응에 대한 현황을 공유받고, 전사적으로 해당 내용을 업데이트해야 한다.
8.
그래서 상용 환경에서의 서비스 장애가 발생했을 때는 모두가 볼 수 있는 화이트보드에 이슈 대응 현황을 적어놓는 것이 좋다. 상용 환경에서의 장애 대응은 긴급한 상황인 만큼 빠르게 대응이 필요하기 때문이다. 긴급한 상황에서 슬랙을 항상 보기도 어렵고, 슬랙을 본다고 하더라도 너무 많은 슬랙들에 의해서 빠르게 휘발될 수도 있기 때문이다. 그래서 모두가 볼 수 있는 화이트보드에 현황과 현황 파악 시간을 적는 게 좋다.
9.
개발자들이 한창 장애를 대응하고 이슈에 대한 원인을 찾을 때, PM은 이후의 대응 시나리오를 세워야 한다. 예를 들어서 특정 시간까지 문제가 해결되지 않으면 어떻게 유저 대응을 할 것인가, 고객사가 있는 경우 어떻게 고객사와의 대응을 할 것인가 등을 비즈니스 팀과 함께 논의해야 한다. 물론 이슈를 빠르게 찾고 핫픽스를 하는 것이 가장 최선이지만, 항상 그렇게 되라는 법은 없으니 이후 플랜에 대해서 고민해야 한다.
10.
그리고 사전에 개발자와 약속한 특정 시간마다 현황을 공유해야 한다. PM은 개발자에게 유저 및 외부 현황에 대해서 말해줘야 하고, 개발자는 PM에게 이슈 해결에 대한 현황을 공유해야 한다. 상용에서의 서비스 장애가 발생했을 때, 개발자들은 이슈 찾는데 몰두했기 때문에 사전에 약속한 시간을 잊어버릴 수도 있다. 이때는 그냥 직접 찾아가서 물어봐야 한다.
11.
개인적으로 처음에는 한창 이슈를 찾는 개발자들에게 현황에 대해서 물어보러 가기 위해서 엄청난 마음의 준비가 필요했다. 괜히 내가 집중하고 있는데 흐름 끊고 방해하는 것 아닐까 하는 생각 때문이다. 그런데 이런 생각 말고 그냥 물어봐야 한다. 정확한 현황을 물어보지 않으면, 아무도 현황에 대해서 정확히 알 수 없고, 현황에 대해서 정확히 알 수 없는 시간이 길어지면 각 파트의 불안감이 크게 올라오기 때문이다. 특히 유저 혹은 고객사 대응을 직접적으로 하는 팀의 경우 정확한 현황을 알지 못하는 경우 '죄송합니다, 파악 중입니다. 해결되는 대로 말씀드리겠습니다' 말고는 할 수 있는 말이 없다.
12.
이슈 대응을 할 때는 개발자, PM, 비즈니스 상관없이 다들 긴장감이 올라와 있고 예민한 상태이다. 따라서 현황 공유 등을 할 때는 감정적인 싸움으로 변질되지 않게 특히 더 주의를 기울여야 한다. 그리고 혹여나 감정적인 대화로 변질된다는 느낌이 들면, 당장의 문제를 해결할 수 있도록 다시 대화를 이끌어야 한다. 개발적으로 서비스 장애 해결의 실마리가 잡히기 전까지는 상황 업데이트와 계획 수립, 대기의 연속이다. 이 과정에서 장애 대응을 하느라 고생하는 사람들에게 음료수나 혹은 작은 간식을 돌리는 것도 긴장된 분위기를 완화하는 데 꽤 도움이 된다. 법카를 쓸 수 있는지 확인해 보자.
13.
서비스 장애 해결의 실마리가 잡혔을 경우, 즉 문제를 어떻게 해결해야 할지 파악이 됐다면 핫픽스 준비를 해야 한다. 빠르게 해결해야 하는 이슈라고 해서, 바로 상용에서 배포를 진행하면 예상치 못한 문제가 또 발생할 수도 있다. 그래서 아무리 급하더라도 스테이징 환경에서 최소한의 테스트를 해보고 핫픽스를 진행해야 한다. 스테이징 환경에서 테스트를 진행하고 성공했다면, 바로 상용에서 핫픽스를 진행한다. 핫픽스 진행 이후 다시 상용 환경에서도 한번 더 테스트를 진행해봐야 한다. 아무리 스테이징에서 문제가 없는 것이 검증이 됐다고 하더라도, 상용 환경에서 문제가 발생했기 때문에 한번 더 꼼꼼히 확인해야 한다.
14.
핫픽스를 통해서 상용 서비스 장애가 해결됐다면, 해결된 내용을 다시 전사적으로 공유해야 한다. 이후 바로 서비스 장애를 겪은 유저들에 대한 대응을 비즈니스 팀과 함께 진행한다. 서비스 장애를 겪은 유저들에 대한 대처가 완전히 끝나기 전까지는 장애 대응이 끝난 것이 아니다. 특히 결제와 관련한 경우에는 결제 취소 및 환불에 대한 운영 처리가 뒤따르는데, 혹시라도 잘못 환불을 하지 않도록 서로 다른 두 사람이 내역을 검증해 가면서 환불 운영 처리를 진행해야 한다.
15.
운영 대응까지 끝나면, 비로소 서비스 장애 대응이 끝났다고 볼 수 있다. 서비스 장애 대응이 끝난 이후에는 장애 대응 회고를 진행해야 한다. 어떤 이유로 인해서 서비스 장애가 발생했는지, 사전에 막을 방법은 없었는지, 나중에 동일하거나 비슷한 장애가 발생하지 않도록 하기 위해서 뭘 해야 하는지, 장애 대응에 빠르게 대처할 수 있도록 평소에 어떤 작업들을 해놔야 하는지 등을 회고해야 한다. 또한 장애 대응으로 인해서 밀린 일정이나 태스크들을 정리해서 다시 전체적인 계획을 세워야 한다.
16.
상용에서의 서비스 장애는 피하고 싶다고 피할 수 있는 게 아니다. 언제 어떻게 닥칠지 모르는 사고와 같은 것이다. 서비스 장애를 마주했을 때의 최선의 마음가짐은 이전에 뭘 놓쳤는지 후회하거나 감상에 젖어들지 말고, 지금 당장 문제를 해결하기 위해서 뭘 해야 하는지 집중하는 것이다.
17.
참고로 맨 처음 서비스 장애를 경험했을 때는 정말 말 그대로 머리가 하얘졌다. 그리고 그 이후 발생한 서비스 장애를 발생할 때는 처음보다는 아주 조금이나마 침착한 구석이 생겼다. 그때나 지금이나 서비스 장애를 대응하는 건 상당히 고통스러운 일이다. 실제 유저들이 문제를 겪고 있고, 또 이것이 비즈니스에 악영향을 줄 수 있기 때문에 짧은 시간 안에 많은 긴장과 함께 문제를 정확하게 해결해야 하기 때문이다.
