Комментарии 42
Мы осознаём, насколько большой ущерб причиняют нашим пользователям подобные инциденты

SLA? Компенсация деньгами?


В общем, еще один аргумент в пользу обязательных фоллбеков.

Во время инцидента задумались ровно о том же, но когда поняли, что и ДНСы лежат там же (думали про вариант переключения А-записи), то понимаешь весь масштаб зависимости и проблемы всех яиц в одной корзине и как-то стало сразу невесело. Решений с фолбеком без отказа от клаудфлер пока приемлемых не нашли(

Смысл защиты клаудфлер в том, что А запись контролируют они, подменяя ее на свои сервера, которые потом редиректят собственно на сервер сайта. То есть и НС-ки их и А запись их, то есть в случае падения их сервисов (в том числе и АПИ) нельзя вообще ничего сделать с ДНС. А отдельно без НС и А в сервисе смысл теряется.


Мы собственно и кинулись сразу менять, как Вы и предложили, но по пути поняли, что не тут-то было(

Несколько я понял, это только для поддоменов подходит, поправьте если я ошибаюсь

Непонятное техническое ограничение, когда сам домен может иметь только A-запись. DNS Cloudflare умеет на лету преобразовывать CNAME в A, чтобы это обойти. Умеет ли ваш DNS, который вы хотите использовать — вопрос к нему. Подозреваю, и через A должно заработать…

Вариант на Business ($200 в месяц) и выше. На более дешёвых страдай.

А на Enterprise, оказывается, в SLA коэффициент отката x25 за даунтайм. Надо запросить подробности у менеджеров…
А почему СЕГОДНЯ? Если это было 02.07.2019. А сегодня это уже 03.07 :)
В таких случаях, обычно, переводчик вставляет примечание в скобках. Особенно в статье, где вообще нет хоть какого-то указания даты события.
Сразу под заголовком:
Автор оригинала: John Graham-Cumming.

Ещё через строку ниже:
Перевод

А дату можно увидеть перейдя к оригиналу. Нажмите на надпись «Автор оригинала John Graham-Cumming». Ну или вот ссылка которая открывается по нажатию этой надписи: blog.cloudflare.com/cloudflare-outage

А почему нужно переходить по ссылке на оригинал для того чтобы понять о чем написано в переводе?

НЛО прилетело и опубликовало эту надпись здесь
Чуть более часа на устранение проблем. Но можно наверное было бы и шустрее.
Не вижу оснований отказываться от сервиса, скорее наоборот, работа над ошибками вполне возможно, улучшит сервис

У нас сайты заработали минут через 20 после начала инцидента, но мы его заметили на 5 минут быстрее чем сам сервис.


А менять конечно смысла нет, я с Вами солидарен, особенно за неимением альтернатив не хуже чем клаудфлер.

На графике ниже показан скачок загрузки CPU на одном из наших PoPs:

Меня всегда радовали графики с нечитаемыми (или отсутствующими) значениями по осям.
Мой преподаватель не принял работу из-за такой ошибки и заставил исправить. Думаю это справедливо, ибо график без обозначения осей это не график вовсе, ведь по нему ничего нельзя понять. Хотя в случае с этим графиком можно догадаться, что по оси X обозначается время, а по оси Y обозначается процент потерянного трафика. То есть по этому графику в промежуток времени с 13:45 до 14:15 потеря трафика составляла около 80%.

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


А на скриншоте просто график с процентом нагрузки на CPU во время инцидента.

Перед графиком есть предложение «На графике ниже показан скачок загрузки CPU на одном из наших PoPs:». Ниже график, где по оси X числа вида 13:45, 14:00, 14:15 — можно сделать вывод, что это время. Ну а по оси Y, как и сказано перед рисунком, загрузка CPU, всегда измерялась в процентах. Строго говоря, конечно, график не соответствует нормам. Но фактически тут как раз тот случай, когда и без подписей все понятно)
Вот так настроил cloudflared и буквально через пару дней поймал 502 по всем логам! бывают же совпадения, а резервного DNS не было.
НЛО прилетело и опубликовало эту надпись здесь
«регулярное выражение, приведшее к скачку загрузки CPU» — регулярное выражение обычно компилируется при первом применении в конечный автомат и дальше работать за линейное время.
Регулярное выражение может быть вида /(A*)*/ и на больших объемах текста вести себя так себе.
После компиляции получится простой конечный автомат.

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

Если использовать классический конечный автомат Томпсона, то да, никаких проблем с производительностью не будет — сложность линейно растет с длиной строки. Но если брать что-то более сложное с поддержкой backreference (например, PCRE), то там уже соответствие с регулярным выражением запросто может приводить к экспоненциальному росту сложности.
Почитайте на досуге про разницу между детерминированными КА и недетерминированными КА.
В регулярках есть буквально пара диалектов с ДКА (что нибудь вроде sed/awk), а то что в языках программирования встроено — все НКА
Недетермерированный КА эквивалентен детерменированному, в котором состояния соответствуют множествам состояний искодного НКА.

Но работают-то они с разной скоростью. Особенно в случаях вида /(A*)*/

Конечный автомат работает со стокростью 1 lookup по таблице на каждый символ анализируемой строки. А для /(A*)*/ КА вообще получится ровно такой же, как и для /A*/., не считая затрат на компиляцию.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.