요약

  • RIPE NCC는 10월 28일 CET 20:04에 간헐적 WHOIS 갱신 실패를 조사하기 시작해 20:23에 RIPE Database 구성 요소를 정상으로 돌리고 20:32에 장애를 종료했다.
  • 공개 상태 기록은 서비스 복구 과정을 보여 주지만, 그사이 제출된 각 객체의 처리 결과를 알려 주지는 않는다.

초록불은 다음 수정 요청을 보내는 사람에게 유용하다. 이미 요청을 보낸 사람은 자신의 기록을 다시 들여다봐야 한다. 28일 저녁 RIPE NCC가 WHOIS 갱신 실패 사고를 처리한 뒤 남은 간격이 바로 이것이다.

공개 사고 데이터에 따르면 중앙유럽시간 20시 04분 48초에 조사, 20시 23분 24초에 수정 후 관찰, 20시 32분에 종료가 기록됐다. RIPE Database 구성 요소는 조사 단계에서 일부 중단으로 바뀌었다가 관찰 단계에서 정상으로 돌아왔다. 사고 전체의 영향 등급은 ‘major’다. 원인, 영향을 받은 갱신 경로, 실패한 제출 건수는 기록에 없다. 이 세 시각은 기관의 발표 시각이지 모든 이용자가 실패를 겪은 시작과 끝이 아니다.

RIPE Database의 처리 확인 안내는 다른 시계를 보여 준다. 한 번의 갱신 제출에는 그 안의 객체별 결과를 담은 확인 메시지 하나가 돌아온다. Syncupdates에서 HTTP 200을 받았더라도 개별 객체는 실패했을 수 있어 요약을 읽어야 한다. REST API는 응답 형식이 다르다. 이번 사고가 어느 경로를 건드렸는지는 상태 페이지에 적혀 있지 않다.

연결이 끊겨 답이 없는 경우는 더 성급하게 행동하기 쉽다. 객체 처리 문서에 따르면 같은 메시지 안의 객체도 따로 처리되며, 동기 HTTP 연결이 닫힌 뒤에도 데이터베이스 작업은 끝날 수 있다. 연결에서 확인을 못 받았다는 이유만으로 다시 보내면 이미 처리된 기록을 놓칠 수 있다. 제출 내용과 받은 답을 보관하고, 현재의 권위 있는 객체를 확인한 다음 재전송을 판단해야 한다.

RIPE NCC는 서비스가 복구된 시각을 공개했다. 이제 필요한 것은 갱신 방식별 영향과 응답 없는 제출을 어떻게 대조할지에 관한 설명이다. 상태판의 초록불이 개별 접수증을 대신 서명해 주지는 않는다.