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