증상
스케줄러 데몬이 하루에 두 번 차단됐다. 3시간, 그리고 50분.
우리가 지목한 원인들
① 항목 개수 → ② 시간당 발생량 → ③ 동시 실행 수 → ④ (실제) 최소 실행 간격공유호스팅은 스케줄 항목의 최소 간격을 15분으로 제한한다. */5, */6, */10은 지원되지 않고, 쓰면 데몬이 차단된다. 우리가 세 번에 걸쳐 세운 지표는 전부 결과였다.
★★★ 왜 세 번 다 "맞는 것처럼" 보였나 — 네 축이 서로 상관돼 있다
*/5 항목은 동시에 개수가 많고, 발생량이 높고, 동시 실행이 많고, 간격이 짧다. 어느 것을 원인으로 골라도 데이터가 설명된다.
★★★ 상관된 후보들 중에서는 관측 데이터로 고를 수 없다. 필요한 것은 한 축만 움직이는 개입이거나 문서다.
★★★ 그런데 우리가 한 개입(전체 감축)은 네 축을 같이 내렸다. 그래서 좋아져도 어느 것 덕분인지 여전히 몰랐다. 구별하려면 발생량은 그대로 두고 간격만 벌리는 식의 개입이어야 했다.
★★★ 후보들이 상관돼 있으면 "증거가 쌓인다"는 느낌이 오히려 오진을 강화한다. 매번 조정할 때마다 증상이 나아졌고, 그것이 매번 잘못된 가설을 확인해 줬다.
★★★ 그리고 결정적으로 — 우리가 센 셋은 전부 "우리가 측정할 수 있는 것"이었다
개수·발생량·동시 실행 수는 우리 시스템을 들여다보면 나오는 값이다. 최소 간격은 상대가 정한 규칙이고, 우리 시스템 안에는 그 규칙의 흔적이 없다.
★★★ 측정 가능한 축에서만 원인을 찾으면, 상대가 정한 규칙은 영영 보이지 않는다. → "우리 관측"과 "상대 문서"는 다른 종류의 증거다. 관측을 아무리 쌓아도 문서를 대신하지 못한다.
★★ 이 컬렉션에는 우리 기본값을 플랫폼 제약으로 오인한 사례가 넷 있다. 이것은 그 반대 방향의 두 번째 사례 — 진짜 제약을 찾지 않고 자체 지표로 추론만 했다. 두 방향 다 같은 비용을 치른다.
⚠️ ★★ 위반의 신호가 에러가 아니라 차단이었다
지원되지 않는 간격을 쓰면 에러가 나지 않는다. 나중에 조용히 차단된다. ★★★ 에러는 즉시 알려주고 차단은 알려주지 않는다. 그래서 원인과 증상 사이에 시간 간격이 생기고, 그 사이에 한 다른 변경이 범인으로 보인다.
⚠️ ★★★ 고친 뒤에도 즉시 복구되지 않는다
간격을 규정대로 바꿨는데 바로 풀리지 않았다. 벌칙성 차단은 원인 제거와 해제가 분리돼 있다.
★★ 이 컬렉션의 "원인을 없애도 증상은 남는다"보다 나쁘다 — 저기는 이미 뜬 작업이 끝나기를 기다리는 것이었고, 여기는 상대가 풀어줄 때까지다. 그 사이에 "안 고쳐졌다"고 판단해 더 손대면 악화된다. ★ 재시도가 아니라 대기가 답인 구간이 있다.
⚠️ ★★ 비상 대체 수단이 다음 사고의 원인이 된다
차단 동안 셸 루프로 대체했다(조건: 프로세스 수가 임계 미만일 때만 실행). 잘 동작하지만 둘을 놓치기 쉽다.
★ 그리고 정상 복구 후 그것을 끄는 절차를 같이 정해 둬라. 비상 수단이 상시 수단이 되면 그 자체가 다음 사고의 원인이 된다.
검증 방법
★ 지원되는 최소 간격·최대 항목 수·동시 프로세스 한계를 호스팅 문서에서 찾아 한 파일에 적고, 스케줄을 바꿀 때마다 그 파일과 대조하라. 우리는 두 번 차단되고 나서야 그 문서를 읽었다.