Неудачное развертывание ПО привело к сбою в работе сервиса Cloudflare

Автор оригинала: John Graham-Cumming.
  • Перевод

Это небольшая временная статья, на месте которой впоследствии окажется полный анализ и исчерпывающая информация о том, что сегодня произошло.


Сегодня на протяжении примерно 30 минут посетители сайтов Cloudflare могли видеть ошибку 502, вызванную резким скачком загрузки CPU нашей сети. Это произошло по причине неудачного развертывания программного обеспечения. Мы провели откат изменений, и сейчас сервис функционирует в обычном режиме, как и прежде, а все домены, использующие Cloudflare, вернулись к нормальному уровню трафика.


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


Добавлено в 20:09 по UTC:


Сегодня в 13:42 по UTC был обнаружен сбой в нашей сети, в результате которого посетители доменов Cloudflare видели ошибку 502 ("Bad Gateway"). Причиной этого сбоя послужило развёртывание неверно сконфигурированного правила в Cloudflare Web Application Firewall (WAF) во время стандартного процесса развёртывания новых управляемых правил Cloudflare WAF.


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


К сожалению, одно из этих правил содержало регулярное выражение, приведшее к скачку загрузки CPU до 100% на наших компьютерах повсеместно. Именно из-за этого скачка пользователи нашего сервиса были свидетелями ошибки 502, а трафик упал до 82%.


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



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


Мы постоянно проводим развёртывание ПО в нашей сети и уже разработали автоматизированные системы для запуска тестов и процедуру поэтапного развёртывания в целях предотвращения неприятных ситуаций. К сожалению, глобальное развертывание правил WAF было осуществлено в одно действие, что и вызвало сегодняшний сбой.


В 14:02 по UTC мы осознали, что произошло и приняли решение полностью отключить наборы правил WAF, что сразу же нормализовало загрузку CPU и восстановило трафик. Мы сделали это в 14:09 по UTC.


После этого мы проанализировали проблемный pull request, откатили изменения в соответствующих правилах, протестировали свои действия, чтобы быть уверенными на 100%, что ошибка найдена верно, а затем восстановили наборы правил WAF в 14:52.


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

Комментарии 42

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

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


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

      0

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

        0

        Унести DNS с CloudFlare — не вариант?

          0

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


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

            0
              0

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

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

                  Благодарю за подсказку, будем думать

            0

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

          0

          SLA с 100% uptime есть на тарифе Business и выше.

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

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

                  +1

                  А дата-то где?

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

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

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

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


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

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

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

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


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

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

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

                                0

                                Это если оно компилировалось...

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

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

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

                                            Для НКА оба утверждения неверны.

                                              0
                                              НКА после компиляции превращается в ДКА.
                                                0

                                                Это если его вообще кто-то компилирует.

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

                              Самое читаемое