푸시 발송을 FCM 레거시 API로 발송하고 있어서, 최신 SDK를 이용해서 푸시가 발송되도록 코드를 수정했다. 페이로드 형태가 약간 변했는데, 호환될것 같은 형태로 코드를 수정했다. 당시 가지고 있던 아이폰으로 발송 테스트는 잘 했다. 그러나 배포 다음날 대량 푸시발송을 했을 때, 안드로이드폰의 지표가 이상한것을 확인했다. 확인해보니 푸시는 발송되었지만, 푸시 랜딩과 푸시를 수신했다고 하는 로그를 저장하는 기능이 동작하지 않았다. 안드로이드 개발자의 도움을 받아 원인은 파악했다. 원인은 페이로드 형태가 이전과 호환되지 않는 것이었고 호환되도록 수정해서 바로 배포했다. 이 오류로 안드로이드로 발송된 푸시가 정상동작하지 않았고, 고객은 특정 메시지의 푸시를 눌렀지만 앱만 켜지고 아무것도 안하는 경험을 했다..
돈(금원)과 관련된 기능은 중요하다. 문제가 발생했을 때, 금전적 손실을 일으킬 수 있다. 만약 작은 회사라면 금전적 손실이 회사 전체의 리스크가 될 수 있다. 돈과 관련된 기능을 다룸에 있어서 다른 여타 기능들 보다 더 면밀하게 살필 필요가 있다. 돈과 관련된 기능을 어떻게 다뤄야할 지 동료들과 회고한 내용을 좀 적어두려고 한다. 1. 이상 상황을 곧바로 탐지할 수 있는 장치가 있어야한다. 문제는 언제든 발생할 수 있다. 문제를 빨리 감지하는 것이 중요하다. 간단하게 비즈니스 메트릭을 구축하고 임계치가 벗어났을 때 알람을 주게 한다던지, 특정 에러상황에서 에러 알림이 오게 한다던지, 이상 탐지 장치를 꼭 구축해야한다. 2. 이상 상황의 문제를 빠르게 식별하고 차단 및 해결할 수 있는 장치가 있어야한다...
휴일에 버그를 발견했다. 한동안 존재하던 버그였다. 발견하자 마자 바로 고쳤다. 바로 공유할까 하다가 휴일 끝나고 공유해야지 라고 생각하고 휴일을 보냈다. 그리고 평일에 까먹었다. 다른 동료가 데이터를 보던 도중에 그 버그가 있었다는 것을 발견했다. 다음 부터는 문제가 있으면 바로 공유해달라는 피드백을 받았다. --- 개발자가 자의적으로 어떤 버그는 큰 영향이 없는 버그라고 판단하고 공유를 하지 않을 수도 있다. 그러나 데이터를 기반으로 의사결정하는 경우에 (공유받지 못한) 그 이벤트를 통해서 영향받은 데이터가 팀의 의사결정이 올바르지 않은 방향으로 가도록 할 수 있다. 버그가 있었고 그 버그가 데이터를 왜곡했고 팀은 왜곡된 데이터로 잘못된 의사결정을 할 수 있다는 뜻이다. 공유를 하지 않은 개발자의 판..
보호되어 있는 글입니다.
- Total
- Today
- Yesterday
- Bali
- 도커
- 한달살기
- 웹을 지탱하는 기술
- spring boot
- sanur
- 발리
- ES6
- Clean code
- 웹
- 실수노트
- rest
- AWSKRUG
- container
- 회고
- ChatGPT
- 사누르
- spring
- 독후감
- 컨테이너
- hands-on
- 객체지향
- S68
- Docker
- 개발자
- html
- AWS
- springboot
- javascript
- ecma6
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |