Summary

  • С 30 июня 2026 года австралийские операторы обязаны вести публичные записи о крупных и значительных локальных сбоях; обычно запись должна появиться не позднее трёх дней после восстановления.
  • Единые поля позволяют сопоставлять отчёты, однако один сетевой инцидент может попасть в несколько журналов с разными идентификаторами и описаниями воздействия.

После восстановления сети оперативное уведомление теряет актуальность. Новый австралийский реестр нужен для другой задачи: сохранить публичную историю уже завершившегося сбоя.

С 30 июня 2026 года операторы, чьи сети используются для услуг конечным пользователям, должны поддерживать такие исторические реестры. Они охватывают квалифицируемые крупные и значительные локальные сбои, устранённые с 31 марта, включая инциденты, начавшиеся раньше этой даты. Записи должны быть заметными, доступными, электронными и выгружаемыми в структурированном формате CSV. Обычно сведения вносят не позднее трёх дней после восстановления услуг. Если оператор узнаёт, что данные устарели или неверны, он также должен исправить их в течение трёх дней. Запись хранится как минимум два года после устранения сбоя.

Речь не идёт о любой краткой потере связи. Значительный локальный сбой должен быть незапланированным, мешать обычному использованию услуги и затронуть не менее 1 000 услуг в региональной Австралии более чем на шесть часов либо 250 услуг в удалённой местности более чем на три часа. Крупные сбои определяются отдельно. Более мелкие события автоматически под это требование не подпадают.

В запись включают присвоенную оператором ссылку, тип сбоя, время начала и восстановления, длительность и затронутые места. Типы и количество услуг указываются, когда это уместно и технически возможно. Причину классифицируют как перебой электропитания, отказ оборудования или системы, повреждение третьей стороной, другую или неизвестную. Оператор может не раскрывать причину, если разумно считает, что публикация угрожает безопасности сети или национальной безопасности.

Главная граница системы связана с тем, кто описывает событие. ACMA отмечает, что обязанность может распространяться и на операторов ниже по цепочке. Поэтому один первичный сбой способен появиться в нескольких реестрах: каждый показывает воздействие на отдельную сеть или набор услуг. Идентификатор присваивает сам оператор. Правила не требуют единого номера регулятора, который связывал бы все записи об одном инциденте. Общая схема CSV упрощает сравнение полей, но не объединяет события.

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

Запись не является персональной историей клиента. Числа ограничены тем, что оператор знает и может технически установить. Реестр сам по себе не доказывает, когда конкретный абонент вновь получил нормальное обслуживание, восстановилась ли обычная производительность и выплачивалась ли компенсация. Обязанности по информированию во время сбоя продолжают действовать отдельно.

Пока эти требования создают основу для последующей проверки, но не подтверждают улучшение надёжности сетей. В отчёте ACMA за апрель—июнь 2026 года упоминается одна завершённая проверка соблюдения более широкого стандарта коммуникаций при сбоях; национальная оценка полноты новых реестров там не приводится. Для выводов о надёжности нужны данные о сроках публикации, исправлениях, пропущенных полях, ссылках и пересечениях между файлами.

Источники: правила ACMA о реестрах сбоев; действующий стандарт, часть 4; объявление о вступлении правил в силу; отраслевые разъяснения; отчёт ACMA за апрель—июнь 2026 года.

Источники