[2023.01.30 기록] 나의 첫 서비스 장애 대응

오늘 내가 다니던 회사의 앱에서 서비스 장애가 발생했다. 주식의 매매나 상품의 거래와 같은 중요한 서비스에서 발생한 장애는 아니었지만, 내가 담당하는 서비스였기 때문에 마음이 굉장히 무거웠다. 

 

ㄴr는 가끔 눈물을 흘린ㄷr.

알고보니 해당 서비스에 사용되는 데이터가 1월 19일 부터 약 11일 동안 적재가 되지 않았다. 앱 화면에서 조회되는 데이터는 매일 새롭게 갱신이 되고, 만약 최신 데이터가 없다면, 최대 10일 전 까지의 과거 데이터를 가져오고 있다. 그런데 내가 데이터가 적재되고 있는지 확인을 하지 못했고, 11일 째 되던 오늘 서비스 장애가 난 것이다.

대충 이런느낌

 

사고의 원인은 단순했다. 설 연휴 동안 한국거래소가 진행한 '차세대 시장 시스템(Exture 3.0)' 업데이트의 여파로 회사에서 관리하는 테이블의 일부가 새로운 명칭으로 재적재 되거나 스키마 및 구조가 변경이 되었다. 내가 담당한 서비스의 데이터도 영향을 받았지만 따로 대응을 하지 않았기 때문에 문제가 발생했다. 

 

내가 사전에 대응을 하지 못한데는 수많은 이유가 있다. 회사에서는 차마 할 수 없었으니 대나무숲 마냥 이곳에 적는다.

나의 변명은 다음과 같다:

• 내가 짠 코드와 배치가 아니다
• 약 1년 간 타부서에서 운영된 프로젝트를 나는 올해 1월 3일에 약식으로 인수인계 받았다
• 1월 21일 ~ 1월 24일은 연휴였다
• 1월 25일 ~ 1월 27일까지 나는 감기몸살로 정상 컨디션이 아니었다
• KRX거래소 업종코드가 변경되었지만 관련 정보를 1월 26일 저녁에 부분적으로 전달 받았다
• 데이터를 만드는데 필요한 원천테이블 데이터가 변경 되었고 심지어 적재되고 있는 상태도 아니었다
• 데이터를 가져가는 서버 쪽 담당자들도 미리 눈치를 챘어야 한다

하루종일 회사에서 이 문제로 골치가 아팠다. 해야할 일이 산더미인데 생각하지도 못한 곳에서 대형 사고가 터졌고, 이를 수습하느라 다른 프로젝트의 진행에 차질이 생겼다. 

 

대형 사고가 일어나기 전까지는 수많은 경미한 사고들과 전조 증상이 존재한다
-하인리히의 법칙-

 

산업 재해를 통계적으로 분석하여 도출한 결과인 하인리히의 법칙에 따르면 1명의 중상자가 발생하기 전에는 같은 원인으로 29명의 경상자가 발생하며, 300명의 부상을 당할 뻔한 잠재적 부상자가 있었다고 한다. 즉, 다시 말하자면 대형 사고는 어느 정도 예방이 가능하다는 뜻이 된다. 이번에 발생한 서비스 장애는 산업 재해와는 규모나 피해 면에서 거리가 멀다.

하지만 사실은 예방이 가능했을 것이라고 생각한다.

 

가장 큰 원인은 사실 내 자신인 것 같다. 그리고 위에 나열한 수많은 변명 중에서도 유일하게 바꿀 수 있는 것도 "나"다.

 

인수인계를 받는 시점 부터 주체적으로 행동했어야한다. 코드를 뜯어보고, 배치도 확인하고, 알림이 가도록 사전에 코드를 수정하는 등 미리미리 작업을 했어야 한다. 전조 증상도 몇 번 있었던 것 같다. 작년 12월에 휴가를 내고 해외로 놀러가기 직전에 다른 프로젝트의 배치에서 오류가 생긴적이 있다. 그 때는 내가 작성한 코드였기 때문에 장애가 나기전에 빠르게 대처가 가능했었다. 그 경험을 교훈으로 삼았다면, 반대로 내가 짜지 않은 코드는 더더욱 신경을 써서 봤어야 했다.

 

두 번째로, 내가 인수인계 받은 프로젝트에서 문제가 생긴게 처음은 아니다. 작년 초, 입사를 하자마자 인수인계를 받은 프로젝트가 너무 하기 싫어서 코드를 살펴보고 체화시키는 것을 게을리했다. 다른 업무에 더 신경을 썼고, 그 결과 사수에게 혼이 났었다.

 

결국 나는 같은 실수를 반복한 셈이다. 인간은 어리석고 같은 실수를 반복한다고 하던데... 정신차려야겠다.

 

기분이 썩 좋지 않지만 느슨해진 회사생활에 긴장감을 주는 이벤트였다고 위안을 해본다.

 

오늘의 일기 끝.