Современные реалии таковы, что не каждый бизнес может себе позволить сайт, особенно стартующий бизнес. Поэтому выгодно воспользоваться конструктором сайтов, например filandor.com . Запуск сайта через несколько минут.
В течение многих лет, когда у Cloudflare был сбой, который затронул наших клиентов, мы очень быстро писали в блогах о том, что произошло, почему и что мы делаем для устранения причин сбоя. Сегодняшний пост немного другой. Речь идет о веб-сайте одного клиента, который не работает должным образом из-за неправильных действий, предпринятых Cloudflare.
Хотя клиент никоим образом не был забанен в Cloudflare или потерял доступ к своей учетной записи, его веб-сайт не работал. И это не сработало, потому что Cloudflare ограничила пропускную способность между нами и исходным сервером. В результате сайт стал непригодным для использования.
Из-за этого необычного дросселя у нашей службы поддержки возникла некоторая внутренняя путаница по поводу того, что произошло. Они ошибочно полагали, что клиент был ограничен из-за нарушения раздела 2.8 нашего Соглашения о подписке на самообслуживание, которое запрещает использование нашей CDN самообслуживания для обслуживания избыточного контента, отличного от HTML, такого как изображения и видео, без платный план, который включает в себя эти услуги (это, например, предназначено для предотвращения того, чтобы кто-то создавал службу хостинга изображений на Cloudflare и потреблял огромную пропускную способность; для такого случая использования у нас есть платные планы изображений и видео).
Однако этот клиент не нарушал раздел 2.8, и он был как платным клиентом, так и платным клиентом Cloudflare Workers, через которые проходил регулируемый трафик. Этого дросселя не должно было быть. Кроме того, у клиента не было необходимости переходить на какой-либо другой уровень плана.
Этот инцидент запустил ряд рабочих потоков внутри Cloudflare, чтобы обеспечить лучшую связь между командами, предотвратить возникновение такого инцидента и сделать общение между Cloudflare и нашими клиентами намного более четким.
Прежде чем мы объясним нашу собственную ошибку и то, как она возникла, мы хотели бы извиниться перед клиентом. Мы понимаем, какое серьезное влияние это оказало и как мы не оправдали ожиданий. В этом сообщении блога мы хотим объяснить, что произошло, и, что более важно, что мы собираемся изменить, чтобы это больше не повторилось.
Фон
2 февраля дежурный сетевой инженер получил предупреждение о перегруженном интерфейсе с Equinix IX в нашем центре обработки данных Ashburn. Хотя это не необычное предупреждение, оно имело место по двум причинам. Во-первых, это происходит уже второй день подряд, а во-вторых, пробка возникла из-за внезапного и резкого всплеска трафика.
Ответственный инженер определил домен клиента, tardis.dev, как ответственный за этот внезапный всплеск трафика между Cloudflare и их исходной сетью, поставщиком хранилища. Поскольку эта перегрузка происходит на физическом интерфейсе, подключенном к внешним одноранговым узлам, это сразу же сказалось на многих наших клиентах и одноранговых узлах. Перегрузка порта, подобная этой, обычно приводит к потере пакетов, низкой пропускной способности и более высокой, чем обычно, задержке. Несмотря на то, что у нас есть автоматическое смягчение последствий перегрузки интерфейсов, в данном случае оно не смогло полностью устранить воздействие.
Трафик от этого клиента внезапно вырос с 1500 запросов в секунду и полезной нагрузки 0,5 МБ на запрос до 3000 запросов в секунду (2x) и более 12 МБ полезной нагрузки на запрос (25x).
Перегрузка произошла между Cloudflare и исходной сетью. Кэширования не произошло, потому что все запросы представляли собой уникальные URL-адреса, идущие к источнику, и поэтому у нас не было возможности обслуживать из кеша.
Инженер Cloudflare решил применить механизм дросселирования, чтобы зона не вытягивала так много трафика из своего источника. Давайте проясним это действие: у Cloudflare нет установленного процесса для ограничения клиентов, которые потребляют большие объемы трафика, и не собирается его иметь. Это исправление было ошибкой, оно не было санкционировано, и мы глубоко сожалеем об этом.
Мы подняли дроссель через внутреннюю эскалацию через 12 часов и 53 минуты после его настройки.
Что дальше
Чтобы не допустить повторения подобных инцидентов, мы устанавливаем четкие правила для смягчения последствий подобных инцидентов. Любое действие, предпринятое в отношении домена клиента, независимо от того, платит оно или нет, потребует утверждения на нескольких уровнях и четкого информирования клиента. Наш инструментарий будет улучшен, чтобы отразить это. У нас есть много способов формирования трафика в ситуациях, когда огромный всплеск трафика влияет на ссылку, и в этом случае можно было бы применить другое смягчение.
Мы находимся в процессе переписывания наших условий обслуживания, чтобы лучше отразить тип услуг, которые наши клиенты предоставляют сегодня на нашей платформе. Мы также стремимся объяснить нашим пользователям простым языком, что разрешено в рамках планов самообслуживания. Как компания, ориентированная на разработчиков, одним из основных принципов которой является прозрачность, мы знаем, что здесь мы можем добиться большего. Позже мы опубликуем запись в блоге, посвященную этим изменениям.
Еще раз приносим извинения клиенту за это действие и за путаницу, которую оно создало для других клиентов Cloudflare.
