🥇Многочасовой сбой Cloudflare оказался результатом некорректной обработки ошибок

Компания Cloudflare опубликовала разбор одного из крупнейших инцидентов в своей инфраструктуре, из-за которого вчера большая часть сети доставки контента оказалась неработоспособной на протяжении более 3 часов. Сбой произошёл после изменения в структуре БД, размещённой в хранилище ClickHouse, после которого файл с параметрами для системы противодействия ботам в два раза увеличился в размере. В БД были образованы дублирующиеся таблицы, при том, что SQL-запрос для формирования файла просто выводил все данные из всех таблиц по ключу, без отсеивания дубликатов. SELECT name, type FROM system.columns WHERE table = ‘http_requests_features’ order by name;

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

Проблема оказалась в том, что вместо корректной обработки превышения лимита и продолжения использования прошлой версии файла с информированием системы мониторинга о внештатной ситуации, в обработчике срабатывало аварийное завершение, которое блокировало дальнейший проброс трафика. Ошибка была вызвана использованием в коде на языке Rust метода unwrap() с типом Result.

Когда значение Result имеет состояние «Ok», метод unwrap() возвращает связанный с этим состоянием объект, но если результат не является успешным — вызов приводит к аварийному завершению (вызывается макрос «panic!»), . Обычно unwrap() применяется в процессе отладки или при написании тестового кода и не рекомендован для использования в рабочих проектах.