서비스 장애, 당신에게도 일어날 수 있어요!
진행 중인 강의 보러 가기 : https://litt.ly/lbyd
PO/PM이다보니 어느 회사를 다니든 장애 프로세스도 주 업무였어요. 14년 정도 되는 근속 기간동안 100억 정도 비용이 날라가는 장애을 비롯해서 기억에 남는 장애는 3번 정도인 것 같네요. 장애가 발생했을 때 우리는 어떻게 해야할까요?
장애는 어디에서나 일어날 수 있다.
장애는 언제든 발생할 수 있어요. 중요한 것은 장애 상황에서의 태도와 준비된 행동입니다. 빠른 판단, 체계적인 대응, 철저한 회고가 장애 반복을 예방하는 핵심이에요.
장애가 발생한다면 어떻게 해야할까요?
1️⃣ 점검 공지 판단
장애가 발생하면 무엇부터 해야할까요? 가장 먼저 해야할 일은 점검 공지 판단이에요. 장애가 발생했다는 것은 우리 메인 서비스에 문제가 발생했다는 것을 의미하기 때문이에요. 장기간 노출되어도 서비스 사용에는 큰 문제가 없는 버그와 순식간에 원인도 모르게 발생하여 서비스를 이용할 수 없는 상태가 되는 장애는 정말 달라요! 그렇기 때문에 장애는 고객의 이탈, 신뢰 하락으로 직결돼요. 장애 상황을 전달받는다면 최대한 빨리 점검 공지를 띄워야 할지 말지 판단을 해야 합니다. 점검 공지는 생각보다 많은 효과를 줘요. 장애를 보는 고객이 느낄 불안감을 해소해주며, 통제되지 않은 사람들이 장애 상황 속에서 행할 행동들을 막아 복구 난이도를 급격히 줄여줍니다.
세줄 요약
- 장애가 발생하면 가장 먼저 점검 공지를 띄울지 판단해야 해요.
- 점검 공지는 고객의 불안감을 줄이고, 복구 난이도를 낮추는 데 효과적이에요.
- 빠른 판단이 고객 신뢰를 유지하고 서비스 이탈을 방지하는 데 중요해요.
2️⃣ 롤백 판단
대부분 장애 상황에서 점검 공지를 띄우고 원인 분석에 들어가는데 제 경험상 원인 분석보다 롤백의 우선 순위를 높이는 것이 장애 시에 더 효과가 컸어요. 대부분 장애 상황에서 제한된 시간 안에 대응부터 원인 분석, 액션플랜까지 도출하는 것만 생각하는 것 같아요. 하지만 그보다 더 중요한 것은 회사의 손실을 빠르게 판단해야 한다는 점이에요. 예를 들어 우리 서비스가 이커머스일 때 3시간동안 멈췄다고 할 때 동일 시간대의 평균 매출 + 장애 복구를 위한 개발 공수가 장애 복구 비용이 됩니다. 그렇기 때문에 무엇보다도 빨리 서비스를 정상적인 상태로 돌려야 장애 복구 비용을 조금이라도 줄일 수 있어요
.
세줄 요약
- 원인 분석보다 서비스 정상화가 우선이에요.
- 장애가 지속되면 회사의 손실이 커지므로 빠른 복구가 핵심입니다.
- 예를 들어, 매출 손실과 복구 공수를 고려해 손실을 최소화해야 합니다.
3️⃣ 원인 분석
롤백이 정상적으로 진행되었고 우리 서비스의 핵심 기능이 정상적으로 동작함을 확인했다면 그 다음 해야할 일은 원인 분석입니다. 롤백을 통해 시스템이 정상화가 되었다 하더라도 정확한 원인을 모르는 상태에서 시스템을 방치하는 것은 또 다른 장애 상황을 불러일으키기 때문이에요. 또한 보통 장애를 분석하기 위해서는 로그 분석이 일반적이기 때문에 장애 발생 후 최대 1시간 안에 로그 분석을 해야 정확한 원인을 발견하기가 용이해요.
세줄 요약
- 롤백 후에는 정확한 원인 분석이 필수입니다.
- 장애 원인을 방치하면 또 다른 장애를 유발할 수 있어요.
- 장애 발생 후 1시간 내에 로그를 분석해 신속히 원인을 파악해야 합니다.
4️⃣ 핫픽스/패치 진행
원인 분석 후 다음에 일어날 상황들을 예방하기 위해 핫픽스나 패치가 진행될 수 있어요. 이러한 핫픽스나 패치를 진행할 때는 지금 당장 진행하는 것이 필요한지 아님 QA 과정까지 다시 거쳐서 진행할지에 대해 실무단의 빠른 판단이 필요합니다. 잘못된 핫픽스나 패치는 또 다른 장애를 불어 일으키기 때문에 신중해야 해요.
두 줄 요약
- 원인 분석 후에는 핫픽스나 패치로 문제를 예방해야 해요.
- QA 과정을 거칠지 바로 진행할지는 상황에 따라 판단하면 됩니다.
5️⃣ 장애 보고서 작성 및 회고
점검, 원인 분석, 핫픽스 진행 등 이 모든 과정을 진행한 후 "아 고생했다", "장애 상황 해결했다" 로 마무리가 되어서는 안돼요. 반드시 장애 회고를 진행해야 합니다. 장애 회고는 일반적인 프로젝트 종료 회고와 달리 반드시 타임라인이 포함된 장애 보고서를 바탕으로 회고가 진행되어야 해요. 장애 회고를 통해 우리가 얻고자 하는 것은 장애 상황은 우리가 의도한 것이 아니기 때문에 다음에 똑같은 장애 상황이 벌어지는 것을 예방하는 것입니다. 그렇기 때문에 단순히 원인만 분석하는 것이 아닌 장애가 지속되는 한정된 시간 동안 내가 한 행동, 우리가 내린 의사결정들도 반드시 같이 회고되어야 해요.
세 줄 요약
- 장애를 해결한 후에는 타임라인이 포함된 보고서를 작성하고 회고를 진행해야 해요.
- 원인 분석뿐만 아니라, 의사결정과 행동 과정도 되돌아보는 것이 중요해요.
- 회고의 목적은 같은 장애가 반복되지 않도록 예방책을 마련하는 데 있어요.
가장 중요한 것은!
무엇보다도 가장 중요한 것은 우리가 장애를 어떻게 바라보냐예요. 장애가 발생하는 것이 두려워 사전에 너무 많은 기술을 넣는 것도, 장애가 발생한 상황에서 남 일처럼 무던한 것도 좋지 않아요. 장애는 언제든 발생할 수 있어요. 내가 장애를 만들었던, 내가 장애를 해결했던, 장애 상황에서 우리가 어떠한 행동을 해야겠다는 생각을 이야기 나누고 예방책을 마련하는 것이 좋은 방향성이에요.
PM/PO/제품 개발에 대한 인사이트를 얻고 싶다면, 오픈채팅방에 참여해 주세요!
https://open.kakao.com/o/g7XO1A5g 참여코드 : til2025
Threads : https://www.threads.net/@lbyd_learning.by.doing
뉴스레터 구독하기 : https://maily.so/marcus.lee
유튜브 구독하기 : www.youtube.com/@LbyD_HJ?sub_confirmation=1
커피챗 및 멘토링 신청하기 : https://inf.run/GRTee
팀 코칭 신청하기 : https://open.kakao.com/o/sh47Hq4g
