한 채널의 긴급 문의 백로그를 세려고 조회했는데 숫자가 서로 안 맞았다. status = 'done'이 수십 건인데 실제 answered_at이 찍힌 것은 몇 건뿐이었다.
Table of contents
Open Table of contents
배경 — 데이터만으로 하는 규명
물어봐도 아무도 이유를 몰랐는데 과거 조치라 기억이 남아 있지 않았다. 남은 데이터만으로 규명해야 하는 상황이었다.
수집기를 먼저 봤는데 레코드를 만들 때 status를 항상 'new'로 넣고 있었다. 그러면 지금 'done'인 행은 누군가 나중에 바꾼 것이 된다.
원인 — 두 컬럼의 불일치
정상 흐름이라면 답변할 때 상태가 바뀌면서 답변 시각도 함께 채워진다. 둘이 같이 가는 구조인데 answered_at이 NULL인데 status만 'done'인 행이 있었다.
두 컬럼의 조합을 축으로 나누니 세 갈래로 깔끔하게 갈렸다. 'done'인데 answered_at이 NULL이면 응답 면제 일괄 조치이고 'new'에 NULL이면 면제에서 누락된 방치분이며 answered_at이 있으면 실제 답변이다.
검증 — 시각 뭉침으로 찾은 시점
일괄 변경이면 같은 시각에 뭉쳐 있을 것이라고 보고 updated_at을 DATE_FORMAT으로 분 단위로 묶어 세어 봤다. 한 분 안에 전부 몰려 있었고 그것으로 조치 시점까지 특정됐다.
일괄 조작은 몇 초 안에 끝나므로 분 단위로 묶으면 한 덩어리로 보이고 정상 처리는 시간에 흩어져 있다. 뭉침 자체가 일괄 조작의 흔적이다.
판단 기준 — 세는 방법이 바꾼 결과
가장 중요한 것은 두 번째 갈래였는데 답도 안 했고 면제도 안 된 진짜 방치분이 몇 건 있었다.
상태값만 세면 면제분이 처리로 세어져 방치분이 가려지고 답변 수만 세면 면제분이 미처리로 부풀려진다. 두 가지 방법이 있었는데 status만으로 세는 것과 status와 answered_at 조합으로 3분할해 세는 것이다. 뒤쪽을 골랐다. 이유는 어느 한 축으로만 세면 둘 다 틀려서다. 대신 백로그 수치 하나가 아니라 세 수치를 함께 보고해야 하는 것을 감수했다. 백로그를 세기 전에 면제분과 방치분과 처리분으로 먼저 3분할해야 했다. 그중 방치분만이 실제로 할 일이다.
교훈 — 데이터가 곧 이력
여기서 다른 데도 쓸 규칙이 하나 나왔다. 상태 컬럼과 그 상태를 뒷받침해야 할 타임스탬프의 불일치는 수동 일괄 조작의 지문이라는 것이다.
정상 흐름은 둘을 같이 바꾸므로 하나만 바뀐 것은 코드가 아니라 사람이 한 것이다. done에 answered_at이 없거나 shipped에 shipped_at이 없는 조합을 보면 과거에 누가 손댔다고 읽는다.
이 조사에서 인상적이었던 것은 아무 기록이 없는데 과거 조치를 재구성했다는 점이다. 무엇을 했는지는 상태값 조합에서 나오고 언제 했는지는 갱신 시각 뭉침에서 나오며 무엇을 놓쳤는지는 그 조건에 안 맞는 것에서 나왔다. 별도 로그가 없어도 데이터 자체가 이력이다.
정리
- 상태와 그 상태를 뒷받침할 타임스탬프의 불일치는 수동 조작의 지문이다
- 정상 흐름은 둘을 같이 바꾸므로 하나만 바뀐 것은 사람이 한 것이다
- 백로그를 세기 전에 면제분과 방치분과 처리분으로 3분할한다
status만 세면 방치분이 가려진다- 처리 수만 세면 방치분이 부풀려진다
updated_at뭉침으로 조치 시점을 역추적할 수 있다- 정상 처리는 시간에 흩어져 있고 일괄 조작은 뭉쳐 있다
- 기록이 없어도 데이터 자체가 이력이다