서비스 사고는 배움의 기회 - 심리적 안전감

5년전 작은 스타트업 다닐 때 있던 일이다. 페이스북에 알람이 떠서 다시 한번 읽어보았는데 그때 "심리적 안전감"이란 말로 표현을 하지는 않았지만 실패의 종류에 따라 실패가 아니란 점은 분명히 알고 있었다 :)

-----

When it rains, it pours. 지금 하는 일이 그다지 고생이 없는 일인데 어제 서버 사고에 이어 오늘은 billing logging 관련해서 이슈가 생겼다. Subscription 서비스라 Active User의 정의에 맞춰 인보이스를 해야하는데 스타트업이다 보니 이 정의도 자주 바뀌고 그래서 자동화를 아직 하지는 못했다. 그런데 기억력이 예전같지 않아서 매달초에 인보이스를 내려면 항상 처음부터 다시 생각을 해야했고 문서화를 한다고 했는데 그것도 별 도움이 안된다. 믿거나 말거나 오프라인으로 일이 엮이는 스타트업들은 거의다 billing 관계된 이슈들이 있다.

오전에 churned user 리포트에 데이터가 없어서 뭔가 잘못되었다고 생각(too good to be true)하고 여기저기 뒤지기 시작했는데 백엔드 엔지니어가 로그 테이블의 특정 필드 값의 semantics를 바꿔버려서 생긴 문제였다. 그전까지는 NULL로 들어오다가 갑자기 0으로 들어오기 시작한 것. 아직 작은 팀인데 이 모양이니 나중에 숫자가 늘면 큰 문제다 싶어 관련해서 이야기를 좀 하고 (혹시 페친 중에 이런 문제를 잘 해결할 방법 아시는 분 있으면 여기 답장 달아주세요!) 중요 로깅 데이터에 안 보이던 값들이 들어오면 슬랙으로 alert 보내게 해두었다. 그리고나서 점심 먹으러 가려고 했는데 클라이언트 회사에서 지난달 인보이스 데이터를 놓고 overcharge되었다고 클레임을 걸어서 오후 내내 주니어 개발자 하나랑 그거 보느라 다 썼다. 결과는 overcharge가 아니고 undercharge했다는 것을 발견 ㅋ 액수가 크지는 않지만 좋은 뉴스인지 나쁜 뉴스인지 혼동스럽다. 더 달라고 해야되나 ㅋ

관련해서 다음 주초에 관련한 사람들끼리 모여서 incident report쓰고 post mortem 미팅하기로 했고 관련 incident report 템플릿도 공유했다. 누가 잘못했는지 알아내려는 것이 아니고 이런 문제를 같이 논의함으로써 좋은 해결책을 만들어내고 같거나 비슷한 이슈가 또 생기는 것을 막기 위함이다. 또한 이런 버릇을 들어야 주니어 개발자들도 나중에 코딩 관련 사고를 쳐도 쫄지 않고 대처할 수 있기 때문에 그런 목적도 있고. 적극적인 개발자들이 사실 사고를 더 친다.

중요한 점은 이를 통해 배우고 비슷한 사고를 반복하지 않는 것이며 리더의 책임은 배움이 있다면 사고를 쳐도 괜찮은 그런 환경을 만들어주는 것이다.

-----
기술적인 사족 1: 데이터를 다룰 때 테이블의 스키마를 바꾸거나 필드 값의 정의를 마음대로 바꾸면 사고가 쉽게 터진다. 특히 후자는 파악하는데 오랜 시간이 걸리게 되며 그래서 데이터 리니지(Lineage)를 파악하고 뭔가 바뀌면 경보를 발생시키는 프로세스 구성이 필수적이다. 이런 이유로 Data Catalog가 필요해진다.