요즘 이상하게 글이 잘 안써진다. 옛날에는 글을 쓰면서 생각을 정리하고 그러다가 의외의 답을 찾아가는 그런 경험들을 했었는데, 요즘은 머리속으로 충분히 생각을 하는 것만으로도 어느정도 결론이 도출되니 글로 옮기는 과정이 좀 지루하게 느껴지는 것 같다.
진짜 문제가 무엇이냐
•
지난주 특정 확장자에서 배경제거가 되지 않는 이슈가 있었다.
◦
20시쯤 PM, QA가 모두 퇴근한 뒤 프로덕션 서버 배포가 이루어졌고
◦
해당 배포 건에 jpg 이미지로 배경제거시 결과 이미지를 webp로 반환하는 코드가 포함되었고 이는 서비스에서 지원하지 않는 확장자여서 오류메시지가 노출되는 상황이었다.
◦
배경제거를 시도하는 많은 이미지들은 jpg 확장자를 가지고 있어서 고객 영향범위가 넓었고
◦
저녁 배포때문에 장애 시간이 16시간정도로 길어지게 되었다.
•
사실 위의 내용은 문제라기보다는 이미 벌어진 사건이자 현상이다. 그렇다면 진짜 문제는 무엇일까?
◦
정해진 배포일이 아니라 비정기적으로 임의 배포를 진행한다.
◦
장애 상황을 빠르게 확인할 수 없는 늦은 시간 배포가 이루어졌다.
◦
스테이징 환경에서 충분히 QA를 거치지 않고 프로덕션 배포가 이루어졌다.
◦
스테이징, 프로덕션 배포 시점을 PM, QA가 정확하게 알 수 없다.
•
단순 해결책을 생각하면 사실 하나다.
◦
한 팀의 예외없이 정기배포일을 지켜서 배포를 하면 된다.
•
그런데 만약 이게 불가능한 경우라면? 그 팀이 이 규칙을 따르고 싶지 않아한다면?
•
그렇다면 우리는 해당 팀이 비정기적으로 QA를 거치지 않고 배포를 해도 안정적으로 서비스를 운영할 수 있는 방법을 찾아야 한다.
◦
모니터링 자동화 툴을 이용하여 실서버를 30분 간격으로 체크한다.
▪
-> 장애를 막지 못한다면 최대한 빠르게 캐치할 수 있도록 한다.
◦
웬만큼 급하지 않다면, 저녁 배포는 하지 않는다. –> 10시 ~ 16시 사이에 배포를 진행한다.
◦
배포 시점을 PM, QA가 알 수 있도록 한다 –> github-slack 연결을 통해 배포 알림이 자동 전송되도록 한다.
◦
스테이징에서 충분히 QA를 진행한 뒤 배포될 수 있도록 한다.
남겨진 질문들
•
처음에는 전체 규칙을 따르지 않는 한 명의 개발자로 인해 함께 일하는 PM, QA가 함께 책임을 져야한다는 것이 부당하다는 생각이 들었는데 개발 리드분, QA분이랑 함께 이야기를 나눠보면서 조금씩은 그 분들을 이해할 수 있게 되었다. 개발 리드분이 말씀하신 것처럼 어쩌면 비정기배포가 앞으로 나아가야할 방향이고, 내가 전통적인 방법에 갇혀있었던 것은 아닐까.
•
스쿼드에 계속 있으면서 실제로 그 분이 뾰족하고 어려운 이슈들을 해결하는 과정을 보면서 정말 실력으로 입증을 해낸다면, 다른 것은 다 눈감아줄 수도 있겠구나-싶은 생각이 들었다. 뾰족한 하나의 강점을 가진 사람이 이래서 필요하구나, 사람의 강점에 집중하는 것이 중요하겠구나- 깨닫게 되는 계기가 되었다. (점점 스며들고 있는건가…)