인과관계를 배제하는 세 단계

같은 날 배포가 있었고 그날 처리 안 된 건 몇 개가 보고됐다. 오늘 배포한 것 때문이냐는 물음이 왔다.

Open Table of contents

상황 — 답하기 어려운 물음

아니라고 하려면 근거가 있어야 한다. 시간이 겹친다는 것만으로는 원인이라고도 아니라고도 할 수 없다. 같은 날 일어났다는 사실은 우연으로도 설명된다.

그렇다고 답하면 되돌릴 준비를 해야 하고 아니라고 답하면 다른 곳을 봐야 하므로 어느 쪽이든 근거 없이 말하면 다음 단계가 통째로 어긋난다.

시간이 겹친다는 것 말고 확정적으로 배제할 수 있는 방법이 필요했다.

git diff --name-only 로 그 배포의 변경 파일 목록부터 뽑았다.

git diff --name-only <배포 전>..<배포 후>

config/<설정 파일>
<클라이언트 클래스> 20개

config/ 의 설정 하나와 클라이언트 클래스 스물이었다.

문제가 난 건이 지나가는 코드 경로는 클레임 저장 로직이었는데 git diff --name-only 목록에 그 경로가 없었다. 배포한 것이 문제 경로에 닿지 않는다는 뜻이다.

여기까지가 첫 배제이고 다만 이것만으로는 config/ 변경이 다른 데 간접 영향을 줬을 가능성이 남는다.

이 배포는 바뀐 클라이언트 클래스가 맡는 일부 대상에만 영향을 준다.

SELECT channel, COUNT(*) FROM ... WHERE <증상 조건> GROUP BY 1;

GROUP BY channel 로 보면 증상도 그 대상에만 몰려야 맞다.

우리가 안 건드린 channel 에서도 같은 증상이 같은 비율로 나오고 있었다. 분포가 배포 범위와 안 맞으니 두 번째 배제가 선다.

분포가 고르다는 사실이 간접 영향 가능성까지 함께 막았는데 config/ 변경이 무언가에 영향을 줬다면 그 영향도 특정 쪽에 몰려야 한다.

증상이 언제부터인지는 MIN(created_at) 한 줄이면 나온다.

SELECT MIN(created_at) FROM ... WHERE <증상 조건>;

MIN 값 하나만 있으면 배포 시각과의 선후가 갈린다.

MIN(created_at) 이 배포 시각보다 앞섰고 원인이 배포라면 그 이후에만 나타나야 하는데 전부터 있던 것이다.

셋 중 가장 단순하면서도 가장 강한 배제였고 조회 한 번으로 시간 순서가 확정된다.

세 가지가 왜 다 필요한지는 각각이 막는 반론을 보면 드러난다.

① 변경 범위와 문제 경로가 안 겹친다
② 안 건드린 경로에서도 같은 증상
③ 시작 시점이 배포보다 앞선다

첫째만 하면 config/ 변경의 간접 영향일 수도 있다는 반론이 남는다.

둘째만 하면 다른 원인이 겹쳤을 수도 있다는 반론이 남는다. 셋째만 하면 전부터 있던 것이 배포로 악화됐을 수도 있다는 반론이 남는다.

셋이 다 배제를 가리키면 남는 반론이 없는데 하나만 들고 답하면 반론이 돌아오고 그때 다시 조사하게 된다.

이런 물음은 배포할 때마다 나오므로 이 셋을 순서로 적어 뒀고 매번 처음부터 생각할 것이 아니었다.

배제로 끝내지 않고 어느 계층을 봐야 하는지도 함께 남겼다.

저장 계층   →  클레임을 대기 상태로 저장한다 (여기까지는 정상)
전달 계층   →  별도 워커가 실제로 보낸다

정체된 건들이 저장 계층 의 대기 상태에 머물러 있었으니 전달 계층 이 안 소비하고 있다는 뜻이다.

다만 그것은 확인한 것이 아니라 좁힌 것이라 회신에 워커 쪽으로 좁혀졌다고 적으면서 추정이며 미확정이라고 함께 적었다.

배제됐다는 것은 확정이고 저쪽일 것이라는 것은 추정인데 두 강도를 나눠 적지 않으면 추정이 결론처럼 읽힌다.

이 조사의 결과는 우리 때문이 아니라는 것이었고 문제 자체는 안 고쳤다.

[배제 없이]  배포를 되돌린다  →  문제는 그대로, 배포 이득만 사라짐
[배제 후]    다른 데를 본다   →  진짜 원인을 찾는다

틀린 방향을 막는 것도 진전이다. 특히 되돌리는 작업은 비싸서 잘못 되돌리면 그 배포의 이득이 사라지고 다시 배포해야 한다.