Боевые стрельбы в ночи, или Почему нагружать прод — не страшно

[sergeymasle]

Не пугайтесь, если всё делать аккуратно, ничего плохого не случится.

а если случиться, сколько ресурсов будет привлечено для устранения «плохого» и кто будет ответственен за даунтайм?

При исследованиях на проде вы будете использовать те же БД, что и реальные юзеры, ту же сеть, то же окружение.

и те же учетные записи реальных пользователей с реальными транзакциями?

Проведение подобного тестирования на проде требует привлечения большого количества ресурсов и работ на покрытие множества рисков, вопрос: стоят ли полученные данные такой цены?

[Busla]

Вы никогда полностью не сымитируете прод на тестовом стенде. И у вас всё равно когда-то произойдёт такая ситуация на проде.

Это как с бэкапами — их надо не только делать, но и проверять.

[vinceremo]

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

Для экспериментов на проде мы используем выделенный пул пользователей, которые по всем свойствам — как живые.
И мы уверены, что ценность полученных данных перекрывает все риски. Как сказали в соседнем комментарии, реальную систему тоже нужно проверять, потому что на тестовых стендах все потенциальные проблемы увидеть невозможно.

[nad_oby]

В одном из мест где я работал кроме стенда, использовался изолированный кластер из прода.
Обычная схема была — в каждом гео сегменте несколько кластеров (3-6). И в сегменте по дизайну потеря одного из кластеров не приводит к насыщению больше 80% при пиковой нагрузке.
Это позволяло делать деплой кластера целиком, а также забирать один из них для стресс-тестов.
Для обстрела используется реплей запросов пользователей. Файлы по 5-10GB и з них случайно выбираются запросы.
Так что возможность делать стрессы относительно безболезненно можно учесть ещё при дизайне системы.