문제를 겪을 때마다 원인과 조치를 기록해 왔고 몇 년 쌓이니 양이 꽤 됐다. 한 번은 그것을 개별 사건이 아니라 전체로 읽으면서 같은 원인이 몇 번 나오는지를 세어 봤다.
Table of contents
Open Table of contents
결과 — 세어 보니 드러난 반복
인덱스 없는 컬럼으로 큰 테이블을 조회한 것이 대여섯 번이었고 BOM 인코딩 표식 누락이 그만큼이었다. 200 응답인데 실제로는 처리가 안 된 건도 대여섯 번이었다.
NFC와 NFD 이름 정규화 형태 차이로 비교가 실패한 것이 서너 번이고 status만으로 사고 범위를 정한 것과 배포 설정이 재생성된 이름을 못 따라간 것이 각각 두어 번이었다. 매번 처음 만난 것처럼 조사했는데 결론은 매번 같았다.
원인 — 기록에 도달하지 못한 이유
기록은 있었는데 다음번에 그것을 찾아내지 못한 이유를 정리했다. 문제를 만났을 때 아는 것은 증상뿐인데 기록은 cause:로 적혀 있어서 grep 검색어가 안 맞았다.
프로젝트별 incidents/에 흩어져 있어서 다른 데서 겪은 것이 안 보인다는 것도 있었다. 개별 조치만 적혀 있으면 다른 파일에서 같은 것을 만났을 때 연결이 되지 않았다.
주의 — 반복될수록 얕아지는 조사
이 검토에서 가장 흥미로운 것이 여기였다. 같은 원인의 기록을 시간순으로 놓고 보니 뒤로 갈수록 내용이 짧아졌다.
첫 기록에는 원인 분석과 그 자리에서 발견한 다른 문제까지 적혀 있는데 마지막 기록에는 조치 한 줄만 있었다. 아는 원인이라고 판단하는 순간 아는 것만 고치게 되고 그 자리의 다른 문제는 안 보이므로 처음 만났을 때가 오히려 깊게 판다.
판단 기준 — 세 갈래로 나눈 대책
원인들을 성격으로 묶으니 셋이었다. BOM 표식이나 EXPLAIN 확인처럼 처음부터 그렇게 만들면 안 겪는 것은 두 가지 방법이 있었는데 체크리스트로 두는 것과 .editorconfig와 CI 검사에 넣는 것이다. 뒤쪽을 골랐다. 이유는 체크리스트는 반복될수록 안 보게 되는 것이 이 검토에서 드러나서다. 대신 검사 하나를 더 유지하는 비용을 감수했다.
조용한 실패나 상태값으로 범위를 정하는 것은 조심하자는 규칙으로는 안 막히므로 실패가 드러나는 구조로 바꿔야 한다. 외부가 응답 형식이나 정책을 바꾸는 것은 못 막으므로 빨리 감지하는 쪽으로 간다. 셋을 구분하고 나니 어디에 힘을 쓸지가 정해졌고 못 막는 것에 규칙을 만들려던 노력을 그만뒀다.
조치 — 기록 방식의 변경
그래서 기록하는 방식을 바꿨다. symptom:에 그 문제를 만났을 때 검색할 단어를 함께 적고 이전 기록이 있으면 see-also:로 연결해서 몇 번째인지를 센다.
한 곳에서 발견하면 같은 패턴이 어디 또 있는지 grep -ril로 전체에서 검색하는 것도 넣었는데 대개 여러 곳에 있다. 아는 원인이어도 그 자리에서 본 것을 다 적기로 한 것이 앞의 경향에 대한 대책이다.
아직 못 한 것도 있다. 시간대별 분포를 보려면 기록에 시각이 일정하게 들어가야 하는데 그러지 못했고 해결까지 걸린 시간도 안 적어서 어떤 유형이 오래 걸리는지를 모른다.
정리
- 개별 사건으로 보면 안 보이던 것이 전체로 세어 보면 보인다
- 반복 횟수가 근본 대책의 우선순위다
- 증상으로 찾게 되는데
cause:만 적혀 있으면 도달하지 못한다 - 반복해서 만나면 조사가 얕아진다
- 아는 것만 고치고 그 자리의 다른 문제는 놓친다
- 원인을 규약과 설계와 감지 셋으로 나눈다
- 못 막는 것에 규칙을 만들려고 애쓰지 않는다
- 기록에
symptom:검색어와 반복 횟수를 함께 적는다