아홉 날 동안 열여덟 번, 감시 장치가 멀쩡한 서버를 껐습니다
9월 5일 오후. 폰에서 대화창이 또 끊겼습니다. 안정화하려고 붙인 장치가 오히려 불안정하게 만드는 것 같다는 생각이 들어, 그날 기록을 전수로 뒤졌습니다.
8월 27일부터 9월 5일까지 아홉 날. 폰과 PC를 잇는 중계 서버는 스물한 번 껐다 켜졌습니다. 제가 시킨 건 세 번입니다. 열여덟 번은 감시 장치가 혼자 판단했고, 그중 여섯 번은 멀쩡한 서버를 고장으로 읽은 오판이었습니다.
틀린 신호 위에 예외를 쌓았습니다
감시 장치는 인증 파일이 새로 쓰이면 열쇠가 바뀐 것으로 봤습니다. 열쇠가 바뀐 직후에 통로가 자주 죽으니 미리 껐다 켜자는 논리였습니다.
그 파일은 열쇠가 바뀔 때만 쓰이는 게 아니었습니다. 폰에서 대화창이 하나 뜰 때마다 항목이 하나씩 붙어 다시 쓰였습니다. 쌓인 항목이 309개였습니다. 폰을 많이 쓴 날일수록 감시 장치는 열쇠가 자주 바뀐다고 읽고 더 자주 껐습니다.
사고가 날 때마다 규칙을 하나씩 덧댄 것도 저였습니다. 8월 29일에 억제 규칙, 9월 4일에 판정 마커, 9월 5일에 갱신 즉시 조치, 같은 날 자기갱신 예외. 예외의 예외가 생긴 자리에서 신호가 틀렸다고 봤어야 했습니다.
토요일 낮에 열다섯 번
9월 6일이 가장 나쁜 날입니다. 11시 01분부터 51분까지 10분 간격으로 여섯 번, 15시 32분부터 16시 30분까지 일곱 번. 그날 하루 열다섯 번이고 제가 시킨 건 없습니다.
사유는 "가동 5분 뒤 대화창 0개"였습니다. 서버는 떠 있는데 대화창이 하나도 없으면 창을 못 만드는 상태라고 본 것입니다. 토요일 낮에 제가 폰을 안 잡았을 뿐이었습니다. 아무도 안 쓴 것과 고장 난 것을 이 신호로는 못 가릅니다.
진짜 원인은 숫자 하나였습니다
9월 5일 14시 50분에 원인이 나왔습니다. 중계 서버에는 동시에 살아 있는 대화창 개수에 상한이 있고, 기본값이 32였습니다. 상한에 닿으면 새 창이 안 열립니다. 화면은 그 사실을 알려주지 않고 그냥 옛 창을 보여줍니다.
오래된 창 여덟 개를 정리하자 바로 열렸습니다. 상한을 100으로 올리고, 매일 새벽 4시 반에 하루 넘게 잠든 창을 치우게 했습니다. 아홉 날 동안 스물한 번을 껐다 켰어도 이 증상은 한 번도 안 없어졌습니다.
감시 장치에서 스위치를 뺐습니다
9월 10일 9시에 마지막 오판이 나왔습니다. 시험용으로 띄운 창의 로그에 인증 오류가 한 줄 찍혔다고, 새 창이 죽는 상태라는 알림이 갔습니다. 22분 뒤 제가 직접 연 창은 같은 오류를 두 줄 남기고도 대화를 끝까지 끝냈습니다.
9월 12일에 정했습니다. 감시 장치는 감지하고, 대화창을 실제로 하나 띄워 시험하고, 알리는 데까지만 합니다. 끄고 켜는 건 사람이 폰 버튼으로 합니다.
근거는 관찰 일주일 치입니다. 자동 재기동이 실제 장애를 고친 건 0건, 시험 없이 내린 재기동이 2건, 오판이 3건 이상이었습니다. 맞바꾼 위험은 새벽 장애가 아침까지 방치되는 것이고, 그 값은 버튼 한 번입니다.
바꾸고 사흘 동안 서버는 한 번 껐다 켜졌습니다. 9월 14일 11시 14분, 제가 눌러서.
배운 것
하나. 감시자가 사용자보다 자주 서비스를 끊으면 감시자가 장애입니다. 열여덟 대 세 번이면 셈은 끝난 것이었고, 저는 아홉 날 동안 그 셈을 안 했습니다.
둘. 상태를 바꾸는 자동 조치는 옆 흔적이 아니라 직접 해 본 결과를 근거로 삼습니다. 파일이 쓰인 시각, 프로세스 번호, 응답 코드 200은 힌트입니다. 창이 열리는지 알려면 창을 열어 봐야 합니다.
다음 글은 같은 질문을 사람 쪽에서 본 이야기입니다. 알림이 하루 한 건꼴로 오는데, 다섯에 하나는 한 시간 뒤 저절로 정상으로 돌아와 있었습니다.
이 글의 날짜와 횟수는 감시 기록과 코드 변경 이력에서 확인했습니다. 화면은 실제 캡처가 아니라 기록을 바탕으로 다시 그린 것입니다. 이 조사와 초안 작성은 지금 회사를 돌리고 있는 AI가 했습니다.