발생 가능한 에러/대응방안 문서화 및 공유가장 문제가 되었던 원격대응 불가/서비스 이용불가 이슈원인 분석 & 개선TC 테스트 케이스모니터링Amplitude슬랙 연동Appsync + DynamoDB / Kibana결론결과
발생 가능한 에러/대응방안 문서화 및 공유
물리 기기와 작은 제형이 만나다보니 제형이 끼인다던지, 필요한 보틀이 장착되어 있지 않거나, 토출 도중에 제형이 소진되거나, 토출 도중에 보틀간의 접촉이 떨어지는 경우, 토출중인 영양제 카운팅을 제대로 하지 못해 과하게 토출되는 경우 등 다양한 이슈들에 대한 판단방법과 대응방법에 대해서도 협의하여 반영하였습니다.
가장 문제가 되었던 원격대응 불가/서비스 이용불가 이슈
외부 고객사에 나가있는 대부분의 엔진에서 펌웨어 업데이트가 잘못 이루어지며 펌웨어가 먹통이 되어버린 사태가 있었습니다. 유저는 이후 서비스를 이용할 수 없었습니다.
이슈 문의전화가 쇄도했으며, 주요 고객사에선 “이러한 리스크 부담을 안고 향후 현재와 같은 방향으로 서비스를 운영하는 것은 무리한 것으로 보입니다”라는 메일까지 받게 됐습니다.
펌웨어 업데이트 뿐만 아니라 대부분의 기능들이 일정에 치우쳐 엣지 케이스들은 미처 다 고려하지 못한 채 기능이 나가고 있던 것이 문제로, 특히 펌웨어 업데이트와 토출로직 관련해서는 더 꼼꼼하게 모든 케이스를 고려해서 완성도 있게 만들었어야 했는데 그러지 못했습니다.
늦게나마 펌웨어 업데이트 로직의 모든 엣지케이스를 정의하고 검증하며 안정화 시키는 작업이 진행되었습니다.
[Feature/#845] 2차엔진 펌웨어 업데이트
[hotfix/#1162] 앱만 재실행 시켰을 때 펌웨어 업데이트가 진행되지 않음
[Feature/#1170] 펌웨어 업데이트 로직 재설계/안정화
[Bug/#1282] USB 연결이 끊긴 상태에서 펌웨어 업데이트가 동작하는 현상
원인 분석 & 개선
많은 고객사 엔진의 펌웨어 업데이트 도중 이상한 펌웨어를 덮어쓰게 되어 대규모 대응이 필요했던 케이스 대응
연관된 이슈들 리스트업 및 원인파악하고, 이와 유사한 또는 발생할 수 있는 모든 엣지 케이스들을 고려하고 대응안을 마련하였습니다.
TC 테스트 케이스
모든 경우의 수와 모든 엣지 케이스를 다 다루는 안정화 작업이 되었으면 하여, 발생할 수 있는 모든 케이스들에 대해 정의하고 검증하였습니다.
모든 테스트 케이스는
문제, 원인, 해결, 검증 방법, 기대 결과 틀에 맞춰 작성하여, 모든 테스터가 동일한 테스트와 기준으로 판단하도록 하였습니다.
모니터링
[Feature/#1060] 펌웨어 업데이트 시도 이력 기록
주요기능들이 완성된 이후에는
UX개선과 이슈대응, 비지니스 개선을 위해 모니터링이 중요해졌습니다.특히 이슈대응 관련하여
사용자의 행동, 엔진의 상태, 서버의 상태, 펌웨어와의 통신문제 등 오류가 발생할 수 있는 곳이 너무 많았기 때문에 에러를 분석하기 위한 모니터링 세팅이 가장 중요했습니다.Amplitude
가장 먼저 도입했던 건 앰플리튜드 입니다.
- 기본적으로
사용자의 행동 플로우를 참조하기 위해 화면 진입 관련 기본적인 이벤트 로깅이 추가 되었고,
- 저는 여기에 사용자가 진입한 화면별 이슈가 될 수 있는 부분들은
디버그 이벤트,에러 이벤트로 구체적인 상황을 이해할 수 있도록 로깅을 추가 하였습니다.
- 앰플리튜드는 이벤트가 발생한 그 순간을 남기는 것이 기본입니다. 하지만 우리는 일련의 과정을 통틀어서 하나의 이벤트로 봐야하는 순간들도 있었으나 그러한 방식은 앰플리튜드에서 지원하지 않아서, 저는 일련의 이벤트를 쌓아놓고 하나의 이벤트로 처리할 수 있도록
커스텀 클래스를 만들어 해결했습니다.
앰플리튜드는 유저의 행위를 추적하는 것이 목적이므로, 유저 중심으로 로그가 관리됩니다.
개발자와 CX 파트에서 확인해야 하는 주요 이벤트 추적과 관련된 대시보드들을 주로 제가 만들어서 공유했습니다.
대표적으로는 회사에서 가장 큰 문제가 됐었던 이슈 중 하나인 펌웨어 업데이트가 잘못되어 엔진이 망가지는 경우와 관련된 것으로, 이벤트 시퀀스를 이용하여 전체 다운로드 시도 중에 몇 건이 정체중인지를 파악하고 추적 관찰 할 수 있도록 하였습니다.
슬랙 연동
계절이 바뀌면서 온도변화에 따라
결로 현상이 생겨 엔진에서 굉음이 나는 등 문제가 되었습니다.원인을 찾아야 했고, 온도와 관련될 거라는 추측이 있어서 급하게 모니터링이 되어야 했습니다.
앰플리튜드는 사용자별 행동 추적 용도이므로, 유저가 아닌 기기별 냉장상태를 지속적으로 관찰하는 것에는 적합하지 않았고, 장기적으로는
appsync를 통해 엔진에 대한 실시간 로그를 DynamoDB에 쌓고 Kibana로 시각화 하기로 했지만, 아직 구현방안이 구체화 되지 않았던 시점에서 임시 대책으로 기기별 냉장과 관련된 것들을 슬랙을 이용한 실시간 모니터링을 구현하였습니다.
냉장온도, 펠티어 온도, 외내부 팬 동작 유무와 결로 발생여부를 관찰하며 상관관계를 찾아내고, 하드웨어 파트에서 결로 대안을 마련할 수 있었습니다. 엔진별 실시간 모니터링 체계가 확립되기 전 적절한 조치였다고 생각합니다.Appsync + DynamoDB / Kibana
사용자별 로그 추적 뿐만 아니라 엔진별 모니터링의 필요성도 느껴서 대안을 마련하게 됩니다.
데이터 파트에서 위 그림과 같은 아키텍처로 로그를 모으고 시각화 하기로 하였고, 저는 맞춰서 대응할 수 있도록 펌웨어 개발자와 협의하여 엔진의 실시간 모니터링에 필요한 정보들을 주기적으로 확인하고 전송할 수 있도록 구성하였습니다.
결과로 엔진별 기록을 바탕으로 통계를 낼 수 있어,
기기별 토출횟수 및 토출 시간대, 보틀 소진 주기 등을 시각화 하여 대시보드를 만들 수 있었습니다.
수많은 엔진 정보가 실시간으로 모니터링 되고 있는 모습입니다.
앰플리튜드는 사용자별 로그를 볼 수 있었다면, appsync를 통해 엔진별 로그를 볼 수 있게 되었습니다.
특정엔진에서 이슈가 발생한 경우 엔진 시리얼로 필터를 걸어 오류 발생 전후 상태 변화 등을 확인할 수 있습니다.
예시로 위 그림은
토출 오류가 발생한 상황에서 확인해보니 7번 슬롯의 오메가3 보틀의 제형이 소진되어 맞춤용량을 온전히 다 토출하지 못했다는 사실을 확인할 수 있습니다.결론
이로써 오류 발생 시의
사용자 행동과, 엔진의 상태변화를 각각 구체적으로 확인할 수 있게 되었고, 구체적인 상황 정보를 바탕으로 버그픽스와 적절한 CX 대응이 가능하게 되었습니다.결과
단순히 주어진 기능만을 구현하는 것이 아니라,
- 문제가 발생한 것을 어떻게 인지할 수 있고,
- 사용자에게 어떻게 알릴 것이고,
- 어떻게 해결해 볼 수 있을 지에 대해
하드웨어 파트와 CX 파트와도 긴밀히 협의하였고, 에러코드 정의 및 문서화도 진행하여 여러 파트들과 문제에 대한 이해수준을 맞추고 유저에게 일관된 대응이 가능하도록 하였습니다.