1. 들어가며
개발자들에게 있어서 가장 막막한 상황중 하나는 이슈가 발생헀는데, 해당 이슈와 관련해서 문서가 존재하지 않고 기존 인력의 퇴사로 개발 히스토리를 알 수 없는 상황이 아닐까.
그 건드리면 안될것 같은 지뢰밭을 내가 밟게 되었다.
2. 이슈
2. 1 이슈 발생 계기
잔잔하던 나의 회사생활에 긴장감을 주는 순간이었다..
이번에 개발자분께서 AWS 관련하여 작업한 부분으로 인해 이슈가 발생하였다.
해당 이슈 발생 이후 사태 해결을 위해 작업한 내용에 대해서 원복하였지만 그럼에도 계속해서 이슈가 발생하고 있었다.
2. 1 이슈 설명
현재 다니고 있는 회사는 공유기 기반의 에드테크를 사업을 진행하고 있어 각종 서비스가 공유기와 의존성이 있다.
MQTT , Mosquitto broker 서버 , pub/sub 서버 , 스케줄러등... 진짜 다양한데, 이번에 여기서 이슈가 발생하였다.
3. 트러블 슈팅
3.1 담당자와의 커뮤니케이션
공유기와 관련된 API 및 기능, 서버 / 인프라들은 내가 입사하기 훠어어어얼씬 전에 구성되어 있었고 실제 개발에 참여하여 개발 히스토리를 꿰고 있는 개발자 ( 서버 ) 분은 퇴사를 하셨기 때문에 첫 시작은 되게 막막했다.
우선은 해당 내용을 알만한 개발자 ( 펌웨어 ) 분과 커뮤니케이션 하면서 정보의 구멍을 하나씩 메꿔갔다.
그나마 다행이었던점은 펌웨어 개발자분이 공유기 개발을 진행하시면서 개발자 ( 서버 ) 분과 커뮤니케이션 하는 과정에서 대략적인 흐름은 알고 계셨다는점이었다. ( 하지만, 어느 EC2 인스턴스에 서버/스케줄러/redis/mongoDB 가 배포되어 있는지에 대한 정보와 Github Repo 중 관련되어 있는 Repo 에 대한 내용은 알 수 없었다. )
담당자와 커뮤니케이션한 내용을 기반으로 대략적으로 플로우 차트를 그렸다.
3.2 개봉 들어갑니다. 딴 ~ 따라란
"예림이 그 REPO / EC2 봐봐 사쿠라여?"
"이게 뭐여 꽝이네?"
이슈를 해결한 지금에 와서는 "제비뽑기하는줄 알았다" 라고 말하고 웃어 넘기겠지만, 당시의 착잡한 심정을 이루 말할 수 없다.
정리된 내용이 없다보니 Github Repo / EC2 중에서 이번 이슈와 연관되어 보이는것으로 추측되는것들을
1차적으로 리스트업하고 하나씩 확인해보는 작업을 진행했다.
3.3 삽질, 삽질 그리고 삽질
Notion 정리한 내용이 거의 한바가지기 때문에 다 작성하는것은 무리일것 같다.
일부분만 작성하자면, 아래의 방법들을 시도했었다.
1. Github Action CI/CD workflow 파일 확인
2. redis/mongoDB 도커 컨테이너 배포 인스턴스 확인
3. redis/mongoDB 도커 컨테이너 로그 확인
4. redis/mongoDB 데이터 베이스 및 데이터 확인
5. 어드민에서 호출하는 API 엔드포인트 트랙킹 ( 가비아에서 CName 확인 -> AWS 의 EC2 리스트업 )
6. MQTT Topic Pub/Sub 로그 확인
7. MQTT Topic 을 구독하는 서버 확인
8. EC2 의 Linux Daemon 에서 구동중인 service 상태 및 로그 확인
9. 기타 등등등등
진짜 피가 마른다는거를 실시간으로 체감하였다.
실제 운영중인 서비스에 장애가 발생한것과 마찬가지였기 때문에 더 초조했었다.
3.4 전체적인 서비스 구성은 도대체 어떻게 되어 있는거야?
"3.3 삽질, 삽질 그리고 삽질" 의 과정을 통해 어느정도 파악이된 부분들을 하나씩 정리해나갔다.
우선은 AWS 인프라 아이콘등을 활용하여 대략적인 서비스의 인프라 구성도를 제작하였다.
트러블 슈팅 과정에서 "공유기 -> Mosquitto broker 서버 -> Redis -> 스케줄러 -> RDS" 과정중에 "Redis -> 스케줄러 -> RDS" 에서 문제가 발생한것을 확인하였고, 대응 작업을 진행했다.
다행히도 서비스는 다시 정상적으로 돌아왔다..
4. 마무리글
밤샘의 흔적들..
간혹가다가 맞닦뜨리는 상황이지만 관련 문서가 아무것도 없는것을 알게되면 눈앞이 아찔해진다.
그래도 이제는 짬이 좀 찼는지 이런 상황에서 어떤식으로 문제에 접근하고 시도하고 해결하는지에 대해서
경험치가 쌓인게 확실히 느껴진다.
조금이지만 노하우? 를 공유하자면,
이런 "인수인계 / 문서가 없는 이슈" 들을 맞닦뜨리면 이제는 아래와 같이 대응 할 수 있다.
1. 관련 부서 담당자 커뮤니케이션 ( 이슈중 개발 히스토리를 알고 있는것이 있으신지 질문 드리고 정리 )
2. 커뮤니케이션 내용을 바탕으로 플로우 차트 초안 제작 ( 부족한 부분은 트러블 슈팅 과정에서 파악해가며 수정 )
3. 삽질 ( 이슈 원인으로 추측되는 모든것들을 리스트업하고 하나씩 수행 )
4. 3번의 삽질을 통해 하나씩 파악하게 되는 내용을 정리
5. 3, 4번의 과정을 반복
6. 해결
해당 이슈가 이번 한번만 일어날것이라는 보장은 없기 때문에 다음에 똑같은 이슈를 맞닦뜨리는 사람을 위해
이번에 삽질한 내용과 트러블 슈팅 과정, 해결 방법등을 정리해서 회사 채널의 Notion 에 공유해놓았다.
미래의 내가 될수도 있지만, 개발자들이 이슈 원인 파악을 위한 접근성이 수월해지기를 기대한다.
댓글