목차
- 인시던트란?
- 인시던트 정책을 수립하게 된 배경이 무엇인가요?
- 인시던트 정책을 수립하기 위해서 무엇을 하였나요?
- 인시던트 발생 시 어떻게 진행되나요?
- 인시던트 처리 후에는 어떻게 하고 있나요?
인시던트란?
인시던트(Incident)란 일반적으로 예기치 못한 사건, 사고, 문제, 또는 이슈를 나타내는 용어로 예기치 못한 서비스 또는 기능이 오작동 하거나 매출 손실을 발생시키는 것을 의미합니다.
인시던트 정책을 수립하게 된 배경이 무엇인가요?
누구라도 온라인몰을 이용하다 보면 장애를 마주할 수 있습니다.
내부 직원이 장애를 마주했을 때 어떻게 공유해야 할지 모르겠거나 이게 인시던트인가? 싶으셨을 때가 많았을 것입니다.
공유하지 못해서 인시던트 처리가 늦어진다면 손실은 점점 늘어나겠죠? 🫠
그래서 조금이라도 빨리 인시던트 장애에 대응하기 위해서 누구라도 부담 없이 인시던트 선언을 할 수 있도록 인시던트 정책을 수립하게 되었습니다.
인시던트 정책을 수립하기 위해서 무엇을 하였나요?
-
[전체 USECASE 작성]
현재 올리브영 시스템에 대한 모든 Usecase가 존재하지 않아 기능별 연관도, CSP를 파악하기 위해서 전체 Usecase를 작성하였습니다.
(복잡한 Usecase) -
[주요 기능 정의]
Usecase를 바탕으로 CSP(Critical Serving Path)를 도입하여 올리브영 전체 시스템의 주요 기능들에 대해 정의하였습니다.
- CSP를 정의함으로써 중요한 장애와 아닌 장애를 구분하여 인시던트 대응의 피로도를 낮출 수 있었습니다.
-
[인시던트 레벨 정의]
인시던트는 매출의 손실과 연결될 수 있습니다. 매출에 얼마나 영향이 발생했는지, 고객에게 얼마나 영향이 갔는지를 판단하여 레벨을 정의하였습니다.
-
인시던트 레벨의 경우 디지털사업본부뿐만 아니라 여러 본부(MD, 영업, 마케팅, SCM)와 협의하여 진행하였습니다.
(이해관계자 협의 진행) -
올리브영은 1분에 XXX만원을 파는 회사!! 이것을 기준으로 매출 영향도, 고객 영향도를 계산하였습니다
-
-
[인시던트 보고, 공유 체계 정의]
인시던트가 발생하였다면 관련 부서에 공유 및 레벨에 따라 윗선 보고가 필요합니다.
- 인시던트가 발생했는지 디지털사업본부 내에서만 알게 된다면 CX, 영업 등과 같이 고객 안내가 필요한 경우 안내를 제때 하지 못하게 됩니다. 그렇기 때문에 빠른 전파 체계를 갖는 것도 중요합니다.
- 기존에 올리브영은 2개의 메신저를 사용하다 보니 공유를 여러 번 해야 하는 번거로움이 존재했습니다. 이 부분을 슬랙으로 일원화하였습니다.
- 누가 알림을 받을지 알림 수신 대상자를 정의하였습니다.
-
[인시던트 가이드 문서 작성]
누구나 쉽게 인시던트를 선언하기 위해서는 어떻게 선언하면 되는지 가이드 문서가 있으면 좋겠죠?
(feat. kkj)
인시던트 발생 시 어떻게 진행되나요?
인시던트를 발견하는 케이스는 크게 두 가지가 있습니다.
- 내부 직원이 사용하다가 발견하는 경우
- Datadog, 모니터링 자동화에서 알림이 오는 경우
알림으로 인해서 인시던트가 발생했다는 것을 인지하면 저희는 슬랙에 /으악 을 외쳐줍니다.
그러면 인시던트 슬랙 채널을 생성할 수 있도록 프로세스가 진행되어 장애 채널이 생성됩니다.
장애 채널이 생성되면 각 팀장님들 핸드폰에 자동 알림 전화가 오게 됩니다.
장애 채널이 생성되면 어떠한 문제가 있는지, 분업하여 장애를 처리하고 어떻게 처리되고 있는지 실시간으로 상황을 기록합니다.
정의했던 인시던트 레벨 기준에 따라서 인시던트 레벨도 선언합니다.
위 기능들은 AWS lambda에 구축되어 있으며 추후에 이 이야기도 블로그에 해보겠습니다.
인시던트 처리 후 활동은 왜 해야 하나요?
인시던트가 발생했을 때에 상황만 해결한다고 끝나는 것이 아닙니다. 인시던트 발생 후 다시 같은 이슈가 발생하지 않도록 관리하는 것이 중요합니다.
그러기 위해서는 정확한 원인 파악, 재발 방지 대책을 세우고 실 작업이 되어야 다시 발생하지 않을 수 있습니다.
인시던트 처리 후 활동은 무엇을 하고 있나요?
-
[인시던트 보고서 작성]
인시던트 상황이 종료되면 그때부터 인시던트 보고서를 작성합니다. 인시던트 리포트는 누구나 문제를 이해할 수 있게 작성하도록 가이드가 되고 있습니다.
인시던트 리포트에는 발생 현상, 비즈니스 영향, 원인, 처리 내용, 재발 방지 대책이 포함되어있습니다. 그중 리포트에는 5 Why Questions 방식을 이용하여 근본 원인 (Root Cause)을 도출하도록 하고 있습니다.
-
[인시던트 보고]
리포트 작성이 완료되면 보고가 이루어지는데 보고 체계는 인시던트의 레벨에 따라서 달라집니다. 인시던트 레벨이 높으면 당연히 더 상향 보고가 되고 초기 장애 보고서를 작성하도록 되어있습니다.
-
[인시던트 리뷰 미팅]
인시던트 보고서가 작성이 완료되면 매달 인시던트 회의를 진행하여 왜 발생했고 어떻게 해야 앞으로 발생하지 않을 수 있는지, 원인을 맞게 파악했는지 서로의 의견을 공유하는 자리를 가져 같은 문제가 재발하지 않도록 하고 있습니다.
인시던트 회의 시 가장 중요한 것은 누구의 책임을 묻기보다는 제대로 된 원인을 확인 후 재발하지 않을 수 있는 대책을 마련하는 분위기로 조성하는 것이 중요합니다.
-
[재발 방지 대책 관리]
짧은 시간에 할 수 있는 업무와 조금 시간을 두고 처리해야 할 업무를 나눠 Short-term, Mid-term, Long-term 3가지 종류의 재발 방지 대책을 관리하고 있습니다.
(우리가 그동안 대응했던 인시던트들)
마치며
올리브영 QA Enginner로 일하고 싶다면 지원하러 가기
