2016년 3월 17일 목요일

역시 생활 리듬 조절엔 풀 리셋!

3월 13일, 지난 일요일부터 흔히 썸머 타임이라고 부르는 Daylight Saving Time이 시작되었습니다. 단 한시간 차이지만 저는 생활 리듬이 다소 흔들리는 편입니다.
제 평소 기상 시간이 새벽 5시인데, DST가 적용된 이후로는 어제 기준으로는 새벽 4시에 일어나는 꼴이 되다보니 상당한 피로감을 몰고오게 됩니다.

그래서 보통 DST에 완전 적응해서 평소와 같이 아침 5시에 기상하여 아침 밥 먹고, 도시락 싸고, 아침 운동을 할 수 있을 때 까지 적어도 1주일 정도의 시간이 필요한데, 올 해에는 이틀만에 완벽 적응을 해버렸습니다.

단 이틀만에 DST에 완벽 적응을 하게 된 비결은 바로 완전 리셋!

사건 경위는 다음과 같습니다.

13일 일요일 아침. 새벽부터 DST가 시작되는 것을 의식해 토요일 밤 평소보다 일찍 잠을 잤습니다만, 주말이라 그런지 푹... 자다가 아이들 성화에 아침 9시가 넘어서야 일어났습니다.

13일 일요일 저녁, 내일 출근과 새벽 운동을 위해 다시 한 번 일찍 잠을 청했습니다.

14일 월요일 아침, 역시나... 눈을 떠보니 5시가 아니라 6시네요. 반년간 맞춰온 제 신체 알람은 그 시간에 맞춰 일어나게 세팅이 되어있나봅니다.

14일 월요일 오전, 왠일로 매니져가 8시 부터 회사에 왔습니다. 그러더니 급한 일 없으면 customer issue 하나 맡아 달라고 부탁하네요. 요즘 할 일이 마땅히 없어 심심하던 차에 올타쿠나 하며 승낙했습니다.
승낙을 하자마자 메니져가 저를 끌고 간 곳은 VP 오피스네요. VP가 지금 문제 상황에 대해 설명하고, 매 시간마다 고객사-우리회사-단말 제조사 3자간 컨퍼런스 콜을 하는 상황이라고 합니다. 대충 보니 고객사에서 일요일 저녁에 시스템 업그레이드를 감행했고, 그 사이 문제가 발생해서 약 만대 가량의 트럭이 단말기 없이 운행을 해야하는 상황이고, VP와 Tech Support 팀은 이미 새벽 4시부터 회사에 출근해서 일을 하고 있더군요.

약간 똥밟았다 싶었지만, 일이 없는 것 보다는 바쁜 것이 좋기에 열심히 문제 분석에 들어갔습니다.

그리고 오후 4시 경 고객이 설명한 재현 경로와 문제 증상을 기반으로 possible root cause를 찾았습니다. 그리고 100% 문제 재현 가능한 경로도 찾아냈고요. 단말이 켜지자마자 재부팅이 되는 것이기에 실제 문제 단말에서 로그 추출이 불가능하여 제가 찾은 원인이 진짜 문제점이라고 100% 장담은 못하던 상황이였는데, 5시 경 기적적으로 문제 발생 단말 중 한대에서 서버 명령어를 받아들여 디버깅 로그를 추출할 수 있었습니다. 역시나 제가 예상한 문제점과 같은 문제점이더군요.

간단한 버그라면 긴급 릴리즈를 통해 다음 릴리즈 때 수정 하겠다고 하면 그만이지만, 고객사의 비지니스가 제대로 돌아가지 않는 상황이라 Root cause 수정은 뒤로 미룬 채 긴급 해결책을 찾기 시작했습니다.

이런 저런 방법들을 생각하다 그 날 저녁 10시 경, 해결 가능한 방법을 생각해냈고, 우리 서버쪽과 단말 제조사의 부트로더 스크립트 양쪽에서 서로 그 해결 방법을 구현하기 시작했습니다. 그 때만 해도 곧 퇴근을 할 줄 알았죠...

서버쪽 구현을 마치고 이런 저런 테스트를 해보니, 문제가 발생한 단말이 서버에 접속하자마자 자동으로 복구 커맨드를 내려도 단말에서 커맨드를 받고 파싱하기 전에 재부팅이 되버려 이 방법은 쓸모가 없다는 것을 확인했고, 결국 제조사 부트로더 스크립트에 희망을 걸었습니다.

1시간이 조금 지난 후 폰 제조사에서 스크립트를 보내왔고 테스트를 해봤지만, 이게 어찌된 것인지 문제 해결이 안되더군요.
그래서 다시 한참동안 코드를 다시 읽어보고, 제조사 스크립트도 열어서 까보고 하나씩 다 해봐도 안 될 이유를 하나도 찾을 수 없었습니다. 그래서 아껴두고있던 디버깅 로그 추출 가능한 단말을 통해 무었이 문제인지 확인을 해보기로 했습니다.

그런데... 어멋???
스크립트를 통해 분명 파일을 삭제했고, 부팅 직후 파일이 없다는 것을 확인 했는데, 어느 순간 유령처럼 그 파일이 다시 살아나 단말에 떡 하니 자리잡고 있는 것입니다.

매 시간마다 진행되는 컨퍼런스 콜  도중 현재 상황을 말하니 제조사쪽에서는 enterprise로 등록된 앱은 별도의 파일 시스템에 앱 백업을 한다며 enterprise filesystem까지 전부 날리는 스크립트를 다시 만들어 준다고 하더군요. 그렇게 다시 업데이트 된 스크립트를 받으니 이미 시간은 새벽 3시.
이제 곧 퇴근을 할 것 같다는 생각에 VP가 야식 사준다고 하는 것도 거절했지만... 이 스크립트 역시 동작을 안했습니다.

결국 새벽 5시가 다 되어서야 알게된 사실은... 스크립트에서 삭제하려고 하는 파일명 중 하나에 오타가 있었습니다. 업데이트를 위한 zip 형태의 패키징 파일이 있고, 업데이트 시 이 패키징을 언팩하여 각각의 설치 파일이 다시 파일 시스템에 저장이 되는데, 스크립트에서 이 패키징 파일명에 오타가 있어서, 각각 개별 설치파일들은 모두 삭제가 되었지만, 패키징 파일은 계속 시스템에 남아 있었던거죠.
그리고 단말이 재부팅되면서 패키징 파일을 다시 unzip하여 설치 파일들을 풀어놓게 되고 해당 파일들이 설치가 되면서 계속 문제가 생기는 것이고요.
그런데 그 패키징 파일이 저장되는 영역은 blind된 파일 시스템인지라 제가 확인해 볼 방법도 없었고, 다른 파일들은 정상적으로 삭제가 되기에 당연히 삭제가 되었을 것이라고 생각했던 것입니다.

그래서 새벽 6시 경 다시 제조사로부터 오타 수정된 스크립트를 받아들고 실제 고객사에서 사용하는 문제 발생단말들에 이리저리 설치를 해보니, 이제서야 예상대로 문제 수정이 되었습니다.

이제는 퇴근하나 싶었는데... 문제는 이 스크립트를 배포하는 것이 다시 문제였죠.
고객사 필드 환경상 USB 케이블도 없고, 케이블이 있다해도 연결하여 사용 할 컴퓨터도 없고, 트럭 기사용 단말기인지라, 통신 데이터 역시 매우 제한적으로만 사용 가능한 요금제인지라 마땅히 이 스크립트를 보낼 방법이 없더군요.

그래서 다시 장시간 회의... 결국엔 모두 수작업을 통해 설치하는 것으로 결정을 내릴 수 밖에 없었고, 그렇게 회의를 마치고, 문제 수정방법에 대한 문서를 작성해서 보내고 나니 오전 8시... 정확히 출근한지 24시간이 지난 후가 되었더군요.

화요일 아침 8시, 퇴근을 하고 최대한 잠을 안자려고 버티고 버티다 낮잠을 자고, 피곤함에 다시 밤잠을 자고 수요일 아침에 눈을뜨니 5시 반!

이렇게 생활 리듬을 완전히 풀 리셋을 한 번 하고나니 원래 기상시간을 되찾을 수 있었습니다. 양 어깨에 피곤함과 무력감은 덤으로 따라와 아직까지 저에게 붙어있고요 ㅠㅠ
그래도 매니져가 월욜에 철야 근무한 것에 대해 하루 휴가를 내주겠다고 하네요.
올 해 휴가가 많이 남지않아 안그래도 연간 휴가일수 좀 협상을 해보려고 했는데, 일단 하루 벌어서 좋네요.

컴퓨터나 스마트 폰에서 평소와는 다른 동작이 발생했을 때 가장 먼저 하는 것이 재부팅이듯, 생활리듬이 흐트러져 재조정이 필요 할 때에도 역시나 풀 리셋만큼 좋은 방법이 없는 것 같습니다.

댓글 3개:

  1. 섬머타임 때문에 한국 회사들도 힘이 드네요. 평소에는 고객사와 시간 맞추느라 저녁 9시에 하던 미팅을 이제는 11시에 하게 되었습니다. 이럴때야 말로 정말 甲의 힘을 절실히 느낍니다ㅠㅠ 혹시 둥이님(뭐라고 불러 드려야 괜찮을까요) 사시는 지역은 해가 몇시에 뜨고 몇시에 지나요? 여기는 아시다시피 오전 오후 6시 기준으로 해가 뜨고 집니다.

    답글삭제
    답글
    1. 요즘 아침에 해 뜨는 시간은 제가 아침 운동을 마치고 나오면 해가 떠 있으니, 아마 오전 7시 정도에 뜨는 것 같습니다. 해 지는 시간은 오후 7시 조금 넘으면 지는 것 같고요.

      삭제
    2. 요즘 아침에 해 뜨는 시간은 제가 아침 운동을 마치고 나오면 해가 떠 있으니, 아마 오전 7시 정도에 뜨는 것 같습니다. 해 지는 시간은 오후 7시 조금 넘으면 지는 것 같고요.

      삭제