Кратко

  • RIPE NCC сообщил о расследовании перебоев доступа к ресурсным сведениям в LIR Portal 3 ноября в 15:55:39 по центральноевропейскому времени, а в 16:50:45 отметил устранение инцидента. Около 55 минут разделяют публикации, а не измеряют простой каждого участника.
  • В разборе, опубликованном в 17:17, организация указала на переключение балансировщика нагрузки и устаревшие соединения приложений с базой данных. Временным решением стала очистка соединений; конфигурацию пула и мониторинг их использования обещано пересмотреть.

У резервного маршрута есть забавное свойство: он не помогает, пока приложение продолжает звонить по старому номеру. Именно это описывает первичный отчет RIPE NCC. Переключение балансировщика повлияло на приложения, использовавшие базу данных. После очистки устаревших соединений оператор закрыл проблему доступа к сведениям о ресурсах. В сообщении есть технический предмет разговора, а не привычное облако под названием «неполадки».

API инцидента фиксирует расследование в 15:55:39.649 и устранение в 16:50:45.437 CET. Между этими записями 55 минут и почти шесть секунд. Оператор не опубликовал поминутный перечень неудачных запросов. Поэтому время между записями следует читать как публичный интервал реагирования, а не как измеренное время недоступности для каждого члена организации. Затронутым компонентом в записи назван LIR Portal.

За словом «портал» скрыта вполне материальная работа. Член RIPE NCC сверяет там свои IPv4 и IPv6 ресурсы и номера автономных систем. Октябрьское описание проекта My Resources перечисляет то, что должна помочь увидеть обновляемая страница: иерархию выделений, регистрационные сведения, использование, объекты базы RIPE и данные маршрутизации. Дерево и автоматические проверки тогда еще разрабатывались и готовились к испытанию с членами. Но потребность видеть собственные записи в действующем портале уже существовала.

Реестр отвечает не только за сохранность записи. Ему нужно обеспечить рабочий путь от записи к человеку, который ею управляет. В этом происшествии отчет объясняет, где путь разошелся: инфраструктурное переключение состоялось, приложения не отпустили прежние соединения. Никакого вывода о потере адресов или изменении прав из этого сообщения не следует; предметом инцидента был доступ к информации. Институциональный вопрос поэтому проверяемый: сколько времени после переключения проходит до успешного запроса ресурса с пользовательской стороны?

Два обещанных направления работы нельзя свести к слову «улучшить». Проверка конфигурации пула соединений касается поведения приложения после смены пути. Улучшение мониторинга использования соединений касается способности увидеть, что приложение цепляется за мертвую сессию. Первое исправляет механизм, второе позволяет заметить его сбой. Отчет не сообщает, что вызвало переключение, сколько участников и запросов пострадали и когда будут готовы изменения. Эти данные и проверка следующего переключения через портал определили бы масштаб и результат ремонта.

На сегодняшний день доказан конкретный исход: RIPE NCC очистил старые соединения и отметил решение проблемы. Будущую устойчивость подтвердит не факт переключения балансировщика, а завершенный запрос участника после него.

Оригинальные материалы RIPE NCC