실패한 것만 보면 안 보이는 것

장비 일부에서 오류가 났다. 오류 난 것들을 모아서 공통점을 찾았다.

전부 같은 슬롯 구간에 있다
전부 같은 시기에 들어온 장비다
전부 특정 펌웨어 버전이다

셋 다 그럴듯했고 특히 펌웨어가 유력해 보였다.

Table of contents

정상인 것도 봤다

확인차 정상 동작하는 장비의 펌웨어 판을 세어 봤다.

오류 난 것 중에 A 가 많은 것은 맞았는데 A 인데 정상인 것도 8대 있었다.

펌웨어가 원인이면 A 는 전부 오류여야 한다. 8대가 멀쩡하니 설명이 안 된다.

슬롯 구간도 마찬가지여서 오류가 몰려 있지만 같은 구간에 정상인 것도 있었다.

오류 난 것만 봤을 때 강해 보이던 단서가 정상 쪽을 세는 순간 약해졌다.

원인 — 분모 없는 조사

오류 난 것만 세면 분자만 있고 분모가 없다. 오류 12건이 전부 펌웨어 A 라는 사실은 그 자체로는 아무것도 안 알려 준다.

A 가 전체의 80%면 당연한 결과이므로 COUNT(*) 를 비율로 바꿔 다시 봤다.

이제 차이가 보이는데 A 가 확실히 높지만 60%라 전부는 아니다.

A 인데 정상인 8대가 있으니 다른 조건이 함께 있어야 오류가 난다는 뜻이다.

교차해서 봤다

한 축으로 안 갈리니 두 축을 교차했다.

펌웨어 A 이면서 슬롯 앞쪽일 때 오류가 몰려 있었고 둘 다여야 나는 것이었다.

앞쪽 슬롯은 급기구에서 먼 자리라 온도가 높은 자리와 특정 펌웨어의 조합이었다.

펌웨어 A 가 온도에 민감한 설정을 갖고 있었고 한 축만 봤으면 못 찾았을 것이다.

각각으로는 안 보이던 것이 교차에서야 드러났다. 한 축씩 보고 끝냈으면 못 왔다.

전체 흐름 — 조사 순서

이 일 이후로 순서를 이렇게 잡았다.

1. 문제가 난 표본의 공통점을 찾는다
2. 그 공통점을 가진 정상 표본을 센다
3. 비율로 본다 — 절대 수는 분포에 좌우된다
4. 두 축을 교차한다 — 한 축으로 안 갈리면 조합일 수 있다

둘째가 핵심인데 이것을 빼면 오류 난 것들의 공통점이 곧 원인처럼 보인다.

실제로는 그냥 흔한 속성일 수 있다. 전체의 절반이 그 시기에 들어왔다면 오류 난 것이 그 시기라는 사실은 정보가 아니다.

표본을 어떻게 뽑나

정상 표본을 볼 때도 주의할 것이 있었다. 처음에는 ORDER BY 최신순으로 뽑았다.

그런데 최근 들어온 장비는 대부분 새 펌웨어라 비교가 안 돼서 전 기간에 고르게 뽑아야 했다.

SELECT * FROM (
  SELECT *, ROW_NUMBER() OVER (ORDER BY installed_at) AS rn,
            COUNT(*) OVER () AS total
  FROM devices WHERE status = 'ok'
) t
WHERE rn % GREATEST(total / 20, 1) = 0

ROW_NUMBER() 로 installed_at 순 번호를 매기고 일정 간격으로 골라내면 전 기간이 고르게 들어온다.

표본이 한쪽으로 쏠려 있으면 비교가 안 된다. 쉽게 뽑히는 것이 대표는 아니었다.

판단 기준 — 결론을 넓히기 전에

원인을 찾은 뒤 펌웨어 A 를 전부 올리자는 쪽으로 가려다 멈췄다. A 인데 정상인 8대가 있다.

그것들은 뒤쪽 슬롯에 있어 지금은 문제가 없고 굳이 올려야 하는지가 바로 안 정해졌다.

올리는 것이 맞기는 한데 그 근거가 위험하니까이지 지금 문제니까가 아니다. 둘을 구분해서 적었다.

작업 우선순위가 그 구분으로 갈리는데 지금 문제인 것이 먼저고 예방은 그다음이다.

정리

• 오류 난 표본의 공통점은 원인일 수도 그냥 흔한 속성일 수도 있다
• 그 공통점을 가진 정상 표본을 세면 단서의 세기가 갈린다
• 오류 난 것만 세는 것은 분자만 있고 분모가 없는 조사다
• 절대 수가 아니라 비율로 봐야 차이가 드러난다
• 비율이 60%라면 그 조건만으로는 설명이 안 된다
• 한 축으로 안 갈리면 두 축을 교차해 조합을 본다
• 비교용 표본은 전 기간에 고르게 뽑는다
• 쉽게 뽑히는 것이 대표성 있는 것은 아니다
• 결론을 넓힐 때 지금 문제인 것과 위험해 보이는 것을 갈라 적는다
• 그 구분이 작업 우선순위를 정한다