【比推】18 ноября Cloudflare вылетел, это дело стало довольно громким — CDN, услуги безопасности, Workers KV, Turnstile, Access и множество других продуктов все упали, они сами говорят, что это самое серьезное падение с 2019 года.
Сначала команда думала, что произошло DDoS-атака, но после долгих проверок обнаружила, что это была ошибка внутри команды: права доступа к базе данных были изменены, в результате чего сгенерированный конфигурационный файл имел ошибку и привел к сбою основной системы прокси. В конечном итоге, благодаря откату на старую конфигурацию, система полностью восстановилась только 19 числа в 1:06 по пекинскому времени.
Официальный отчет блога написан довольно искренне, прямо признается, что это “неприемлемо”, и говорится о необходимости ускорить преобразование системной устойчивости. Для нас, кто использует их услуги для реализации проектов, такой уровень сбоя инфраструктуры действительно следует запомнить — даже самый крутой поставщик может потерпеть неудачу из-за внутренних ошибок, поэтому многократное развертывание и аварийные планы все равно нужно готовить заранее.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Обзор самого серьезного сбоя в истории Cloudflare: это не была атака, а ошибка в изменении конфигурации.
【比推】18 ноября Cloudflare вылетел, это дело стало довольно громким — CDN, услуги безопасности, Workers KV, Turnstile, Access и множество других продуктов все упали, они сами говорят, что это самое серьезное падение с 2019 года.
Сначала команда думала, что произошло DDoS-атака, но после долгих проверок обнаружила, что это была ошибка внутри команды: права доступа к базе данных были изменены, в результате чего сгенерированный конфигурационный файл имел ошибку и привел к сбою основной системы прокси. В конечном итоге, благодаря откату на старую конфигурацию, система полностью восстановилась только 19 числа в 1:06 по пекинскому времени.
Официальный отчет блога написан довольно искренне, прямо признается, что это “неприемлемо”, и говорится о необходимости ускорить преобразование системной устойчивости. Для нас, кто использует их услуги для реализации проектов, такой уровень сбоя инфраструктуры действительно следует запомнить — даже самый крутой поставщик может потерпеть неудачу из-за внутренних ошибок, поэтому многократное развертывание и аварийные планы все равно нужно готовить заранее.