PO/PM이다보니 어느 회사를 다니든 장애 프로세스도 주 업무였습니다. 11년 정도 되는 근속 기간동안 백억 정도 비용이 날라가는 장애을 비롯해서 기억에 남는 장애는 3번 정도인 것 같습니다. 심지어 이번주에도 장애를 겪었네요. 해서 장애에 대해 글을 작성해보고자 합니다.
장애가 발생한다면 어떻게 해야할까요?
1. 점검 공지 판단
장애가 발생하면 무엇부터 해야할까요? 가장 먼저 해야할 일은 점검 공지 판단입니다. 장애가 발생했다는 것은 우리 메인 서비스에 문제가 발생했다는 것을 의미합니다. 장기간 노출되어도 서비스 사용에는 큰 문제가 아닌 버그와 순식간에 원인도 모르게 발생하여 서비스를 이용할 수 없는 상태가 되는 장애는 정말 다릅니다. 그렇기 때문에 장애는 고객의 이탈, 신뢰 하락으로 직결됩니다. 장애 상황을 전달받는다면 최대한 빨리 점검 공지를 띄워야 할지 말지 판단을 해야 합니다. 점검 공지는 생각보다 많은 효과를 줍니다. 장애를 보는 고객이 느낄 불안감을 해소해주며, 통제되지 않은 사람들이 장애 상황 속에서 행할 행동들을 막아 복구 난이도를 급격히 줄여줍니다.
2. 롤백 판단
대부분 장애 상황에서 점검 공지를 띄우고 원인 분석에 들어가는데 제 경험상 원인 분석보다 롤백의 우선 순위를 높이는 것이 장애 시 더 효과가 컸습니다. 대부분 장애 상황에서 제한된 시간 안에 대응부터 원인 분석, 액션플랜까지 도출하는 것만 생각합니다. 하지만 그보다 더 중요한 것은 회사의 손실을 빠르게 판단해야 한다는 점입니다. 예를 들어 우리 서비스가 이커머스일 때 3시간동안 멈췄다고 할 때 동일 시간대의 평균 매출 + 장애 복구를 위한 개발 공수가 장애 복구 비용이 됩니다. 그렇기 때문에 무엇보다도 빨리 서비스를 정상적인 상태로 돌려야 장애 복구 비용을 조금이라도 줄일 수 있습니다.
3. 원인 분석
롤백이 정상적으로 진행되었고 우리 서비스의 핵심 기능이 정상적으로 동작함을 확인했다면 그 다음 해야할 일은 원인 분석입니다. 롤백을 통해 시스템이 정상화가 되었다 하더라도 정확한 원인을 모르는 상태에서 시스템을 방치하는 것은 또 다른 장애 상황을 불러일으킵니다. 또한 보통 장애를 분석하기 위해서는 로그 분석이 일반적이기 때문에 장애 발생 후 최대 1시간 안에 로그 분석을 해야 정확한 원인을 발견하기가 용이합니다.
4. 핫픽스/패치 진행
원인 분석 후 다음에 일어날 상황들을 예방하기 위해 핫픽스나 패치가 진행될 수 있습니다. 이러한 핫픽스나 패치를 진행할 때는 지금 당장 진행하는 것이 필요한지 아님 QA 과정까지 다시 거쳐서 진행할지에 대해 실무단의 빠른 판단이 요하게 됩니다.
5. 장애 보고서를 통한 회고
점검, 원인 분석, 핫픽스 진행 등등 이 모든 과정을 진행한 후 "아 고생했다" "장애 상황 해결했다" 로 마무리가 되어서는 안됩니다. 반드시 장애 회고를 진행해야 합니다. 장애 회고는 일반적인 프로젝트 종료 회고와 달리 반드시 타임라인이 포함된 장애 보고서를 바탕으로 회고가 진행되어야 합니다. 장애 회고를 통해 우리가 얻고자 하는 것은 장애 상황은 우리가 의도한 것이 아니기 때문에 다음에 똑같은 장애 상황이 벌어지는 것을 예방하는 것입니다. 그렇기 때문에 단순히 원인만 분석하는 것이 아닌 장애가 지속되는 한정된 시간 동안 내가 한 행동, 우리가 내린 의사결정들도 반드시 같이 회고되어야 합니다.
가장 중요한 것은...
무엇보다도 가장 중요한 것은 우리가 장애를 어떻게 바라보냐입니다. 장애가 발생하는 것이 두려워 사전에 너무 많은 기술을 넣는 것도, 장애가 발생한 상황에서 남 일처럼 무던한 것도 좋지 않습니다. 장애는 언제든 발생할 수 있습니다. 내가 장애를 만들었던, 내가 장애를 해결했던, 장애 상황에서 우리가 어떠한 행동을 해야겠다는 생각이 중요합니다.
디스코드 커뮤니티 안내
PM & PO 직군의 취직, 이직, 커리어를 같이 이야기할 디스코드를 운영 중에 있습니다. 그 외 많은 정보가 디스코드에 있으니 많은 관심 부탁드립니다.
