Кратко

  • 21 августа в 17:39:20 UTC Cloudflare открыла инцидент xl112dfsfz6q и сообщила о расследовании проблем сетевой производительности в Азиатско-Тихоокеанском регионе. В 17:47:56 UTC компания объявила, что внедрила исправление и наблюдает за результатами.
  • Когда BTW зафиксировала источник в 19:14:34 UTC, запись всё ещё находилась на мониторинге и не была решена. Поле влияния содержало none, а компонент Network оставался рабочим в обеих публикациях.

Публичная шкала точно измеряет только действия поставщика. Между началом расследования и заявлением об исправлении прошло 8 минут 36 секунд. Это не длительность клиентского воздействия: Cloudflare не назвала время первого симптома, затронутые пути или момент восстановления каждого из них.

Минимальный тест закрытия начинается с проверки статуса самого инцидента. В момент среза resolved_at оставался пустым, а мониторинг продолжался уже более 86 минут. Значит, поставщик наблюдал за результатом изменения и ещё не объявил завершение собственного процесса.

Второй шаг — определить границы. Название «Asia Pacific» не является числом пользователей или потоков. Публичная карта Cloudflare перечисляет множество городов в Азии и Океании, но инцидент не указывает город, страну, дата-центр, сеть доступа, ASN или маршрут. Нельзя превращать региональную метку в утверждение об отключении всего региона.

Третий шаг — не добавлять продукты и симптомы. В записи нет CDN, DNS, Workers, Zero Trust, Magic Transit или другого сервиса. Нет данных о задержке, потерях, ошибках, разрывах соединений, колебаниях маршрутов или перегрузке. Причина, инициирующее изменение и механизм исправления тоже не опубликованы.

Структурированные поля не заменяют эти сведения. Оба обновления связывают компонент Network, но показывают переход от рабочего состояния к рабочему; текущее состояние также рабочее. Поле влияния равно none. Одновременно текст говорит о проблеме, её анализе, смягчении и внедрённом исправлении. Это означает, что агрегированные поля не измеряют наблюдение конкретного клиента, а не то, что никакого воздействия быть не могло.

Четвёртый шаг — сверить собственный путь. Документация Cloudflare предлагает сохранить colo обслужившего запрос дата-центра, измерить стадии соединения и использовать traceroute или MTR. Origin Analytics разделяет ответ исходного сервера и ответ края и показывает перцентили времени ответа.

Для каждой подозрительной когорты нужны сеть пользователя, colo, хост, результат края, результат источника и одинаковое окно UTC. Полезна и контрольная когорта без изменения. Если замедлился только источник, региональная запись не доказывает вину Cloudflare. Если несколько сетей изменились на одном входе, это сужает область, но ещё не раскрывает внутреннюю причину.

Пятый шаг — закрыть клиентские операции, а не только оповещение. Нормализация синтетического теста, кодов и перцентилей на затронутом пути должна совпасть с отсутствием новых ошибок в рабочих запросах. Даже будущее resolved будет выводом поставщика о своей системе, а не автоматическим подтверждением каждой клиентской транзакции.

Источники