Комментарии
42
Мы осознаём, насколько большой ущерб причиняют нашим пользователям подобные инциденты
SLA? Компенсация деньгами?
В общем, еще один аргумент в пользу обязательных фоллбеков.
Во время инцидента задумались ровно о том же, но когда поняли, что и ДНСы лежат там же (думали про вариант переключения А-записи), то понимаешь весь масштаб зависимости и проблемы всех яиц в одной корзине и как-то стало сразу невесело. Решений с фолбеком без отказа от клаудфлер пока приемлемых не нашли(
Унести DNS с CloudFlare — не вариант?
Смысл защиты клаудфлер в том, что А запись контролируют они, подменяя ее на свои сервера, которые потом редиректят собственно на сервер сайта. То есть и НС-ки их и А запись их, то есть в случае падения их сервисов (в том числе и АПИ) нельзя вообще ничего сделать с ДНС. А отдельно без НС и А в сервисе смысл теряется.
Мы собственно и кинулись сразу менять, как Вы и предложили, но по пути поняли, что не тут-то было(
«CNAME setup»? support.cloudflare.com/hc/en-us/articles/360020348832
Несколько я понял, это только для поддоменов подходит, поправьте если я ошибаюсь
Непонятное техническое ограничение, когда сам домен может иметь только A-запись. DNS Cloudflare умеет на лету преобразовывать CNAME в A, чтобы это обойти. Умеет ли ваш DNS, который вы хотите использовать — вопрос к нему. Подозреваю, и через A должно заработать…
Благодарю за подсказку, будем думать
Вариант на Business ($200 в месяц) и выше. На более дешёвых страдай.
SLA с 100% uptime есть на тарифе Business и выше.
А на 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), а то что в языках программирования встроено — все НКА
В регулярках есть буквально пара диалектов с ДКА (что нибудь вроде sed/awk), а то что в языках программирования встроено — все НКА
Недетермерированный КА эквивалентен детерменированному, в котором состояния соответствуют множествам состояний искодного НКА.
Но работают-то они с разной скоростью. Особенно в случаях вида /(A*)*/
Конечный автомат работает со стокростью 1 lookup по таблице на каждый символ анализируемой строки. А для /(A*)*/ КА вообще получится ровно такой же, как и для /A*/., не считая затрат на компиляцию.
Для НКА оба утверждения неверны.
НКА после компиляции превращается в ДКА.
Это если его вообще кто-то компилирует.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Неудачное развертывание ПО привело к сбою в работе сервиса Cloudflare