Найти в Дзене
Dmitrii Shakhov // QA, IT, Tech

Cloudflare и падение 18 ноября. Какие выводы можем сделать?

Во вторник 18 ноября многие из наших любимых сервисов перестали работать. Причиной всему было падение Cloudflare, и об этом они кстати написали достаточно добротный отчет. Однако нас как QA-инженеров (и не только) интересует не столько сам факт падения, сколько выводы, которые мы можем из него сделать: 1. Без нормального observability никуда. Что делали в Cloudflare? Вместо починки бага - отражали несуществующую DDoS-атаку. Казалось бы, перепутать реальный баг и атаку сложно. Но когда метрики и алерты настроены так, что вводят в заблуждение, именно такие ошибки совершаются снова и снова. Запуск любой фичи должен требовать не только проработки пользовательских сценариев, но и тщательного внимания к тому, что остаётся за кадром. Область, о которой часто забывают даже внутри команды разработки - какие метрики собираем, что считаем не нормальным поведением, когда и как должны срабатывать алерты. Сюда же относятся и остальные «невидимые» части продукта: тесты, пайплайны, требования и други

Во вторник 18 ноября многие из наших любимых сервисов перестали работать. Причиной всему было падение Cloudflare, и об этом они кстати написали достаточно добротный отчет.

Однако нас как QA-инженеров (и не только) интересует не столько сам факт падения, сколько выводы, которые мы можем из него сделать:

1. Без нормального observability никуда. Что делали в Cloudflare? Вместо починки бага - отражали несуществующую DDoS-атаку. Казалось бы, перепутать реальный баг и атаку сложно. Но когда метрики и алерты настроены так, что вводят в заблуждение, именно такие ошибки совершаются снова и снова.

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

Сюда же относятся и остальные «невидимые» части продукта: тесты, пайплайны, требования и другие внутренние механизмы. Если не уделять им внимания, система будет сообщать о проблемах тогда, когда пользователи уже всё почувствовали.

2. Важнее, что тесты проверяют, чем просто code coverage. Заложив ограничения на количество одновременных фичей в рантайме BotManagement'а, которое по сути являлось магической "недостижимой" константой, Cloudflare не обеспечили Graceful Degradation на случай, если этот "черный лебедь" прилетит.

Как итог, вместо нормального сообщения в логах ловили панику

thread fl2_worker_thread panicked: called Result::unwrap() on an Err value,

что в том числе навело опытных инженеров на ложный след.

Можно предложить еще массу всего: и не выкатывать изменения сразу на всех, и проводить хаос-тестирование, и многое-многое другое. Но залог успеха - это наличие правильно настроенных мониторингов, а также отсутствие бесполезных тестов, написанных только ради % покрытия.

И казалось бы, что это все и так уже знают. Однако я часто наблюдаю, как на эти фундаментальные для продукта вещи забивают, в угоду TTM и прочих метрик, которые в моменте дадут команде немного быстрого эндорфина, но в долгосрочной перспективе принесут лишь стресс и тоску.