TL;DR Чем ближе к реальности ваши тестовые данные, тем лучше. Попробуйте Gor — автоматическое перенаправление production трафика на тестовую площадку в реальном времени.
Здесь в Granify мы обрабатываем огромное количество генерируемых пользователями данных, наш бизнес построен на этом. Мы должны быть уверены что данные собираются и обрабатываются правильно.
Вы даже не представляете насколько странными могут быть данные пришедшие от пользователей. Источником могут быть прокси-серверы, браузеры о которых вы никогда не слышали, ошибки на клиентской стороне, и так далее.
Более того, мы может просто все сломать при обновлении версии, даже если все тесты прошли. На моей практике это случается постоянно.
Есть целый класс ошибок которые очень непросто найти автоматизированным и ручным тестирование: concurrency, ошибки в настройке серверов, ошибки которые проявляются при вызове команд только в определенном порядке, и многое другое.
Но мы можешь сделать несколько вещей что бы упростить поиск таких багов и улучшить стабильность системы:
Наличие Staging среды обязательно, и она должна быть идентична production. Использование таких средств как Puppet или Chef сильно облегчает задачу.
Вы должны требовать что бы разработчики всегда в ручную тестировали свой код на staging. Это помогает найти самые очевидные ошибки, но это все еще очень далеко от того что может случится на production трафике.
Есть несколько техник для позволяющих протестировать ваш код на реальных данных (я рекомендую использоваться обе):
1. Обновлять только 1 из production серверов, таким образом часть ваших пользователей будет обрабатываться новым кодом. Эта техника имеет несколько минусов: часть ваших пользователей может увидеть ошибки, и вам возможно придется использоваться "липкие" сессии. Это довольно похоже на A/B тестирование.
2. Воспроизведение production трафика (log replay)
Илья Григорик написал замечательную статью про нагрузочное тестирование используя log replay технику.
Все статьи что я читал на эту тему упоминают log replay как средство для нагрузочного тестирования используя реальные данные. Я же хочу показать как использовать эту технику для ежедневного тестирования и нахождения ошибок.
Такие программы как jMeter, httperf or Tsung имеют поддержку log replay, но она либо в зачаточном состоянии либо сфокусированная на нагрузочном тестировании а не эмуляции реальных пользователей. Чувствуете разницу? Реальные пользователе это не только набор запросов, очень важно правильный порядок и время между запросами, различные HTTP заголовки и так далее. Для нагрузочного тестирования это порой не важно, но для поиска ошибок это критично. К тому же эти средства сложны в настройке и автоматизации.
Я написал простую программу Gor
Gor — позволяет автоматические воспроизводить production трафик на staging в реальном времени, 24 часа в сутки, с минимальными затратами. Таким образом ваша staging среда всегда получает порцию реально трафика.
Gor состоит из 2-ух частей: Listener и Replay сервера. Listener устанавливается на production веб серверы, а дублирует весь трафик на Replay сервер на отдельной машине, который уже направляет его на нужные адрес. Принцип работы показан на диаграмме ниже:
Gor поддерживает ограничение количества запросов. Это очень важная настройка, так как staging как правильно использует меньше машин чем production, и вы может выставить максимальное кол-во запросов в секунду которое может выдержать ваша staging среда.
Вы можете найти подробную документацию на странице проекта.
Так как Gor написан на Go, для запуска мы можете просто использовать уже скомпилированный дистрибутив Downloads
В Granify, мы используем Gor в production в течении некоторого времени, и очень довольны результатами.
Удачного тестирования!
Здесь в Granify мы обрабатываем огромное количество генерируемых пользователями данных, наш бизнес построен на этом. Мы должны быть уверены что данные собираются и обрабатываются правильно.
Вы даже не представляете насколько странными могут быть данные пришедшие от пользователей. Источником могут быть прокси-серверы, браузеры о которых вы никогда не слышали, ошибки на клиентской стороне, и так далее.
Не важно сколько у вас тестов и фикстур, они просто не могут покрыть все случаи. Трафик с production всегда будет отличаться от ожидаемого.
Более того, мы может просто все сломать при обновлении версии, даже если все тесты прошли. На моей практике это случается постоянно.
Есть целый класс ошибок которые очень непросто найти автоматизированным и ручным тестирование: concurrency, ошибки в настройке серверов, ошибки которые проявляются при вызове команд только в определенном порядке, и многое другое.
Но мы можешь сделать несколько вещей что бы упростить поиск таких багов и улучшить стабильность системы:
Всегда тестируем на staging
Наличие Staging среды обязательно, и она должна быть идентична production. Использование таких средств как Puppet или Chef сильно облегчает задачу.
Вы должны требовать что бы разработчики всегда в ручную тестировали свой код на staging. Это помогает найти самые очевидные ошибки, но это все еще очень далеко от того что может случится на production трафике.
Тестируем на реальных данных
Есть несколько техник для позволяющих протестировать ваш код на реальных данных (я рекомендую использоваться обе):
1. Обновлять только 1 из production серверов, таким образом часть ваших пользователей будет обрабатываться новым кодом. Эта техника имеет несколько минусов: часть ваших пользователей может увидеть ошибки, и вам возможно придется использоваться "липкие" сессии. Это довольно похоже на A/B тестирование.
2. Воспроизведение production трафика (log replay)
Илья Григорик написал замечательную статью про нагрузочное тестирование используя log replay технику.
Все статьи что я читал на эту тему упоминают log replay как средство для нагрузочного тестирования используя реальные данные. Я же хочу показать как использовать эту технику для ежедневного тестирования и нахождения ошибок.
Такие программы как jMeter, httperf or Tsung имеют поддержку log replay, но она либо в зачаточном состоянии либо сфокусированная на нагрузочном тестировании а не эмуляции реальных пользователей. Чувствуете разницу? Реальные пользователе это не только набор запросов, очень важно правильный порядок и время между запросами, различные HTTP заголовки и так далее. Для нагрузочного тестирования это порой не важно, но для поиска ошибок это критично. К тому же эти средства сложны в настройке и автоматизации.
Разработчики очень ленивы. Если вы хотите что бы ваши разработчики использоватли какую либо программу/сервис, он должен быть максимально автоматизирован, а еще лучше что бы оно работало так что никто ничего не заметил.
Воспроизводим production трафик в автоматическом режиме
Я написал простую программу Gor
Gor — позволяет автоматические воспроизводить production трафик на staging в реальном времени, 24 часа в сутки, с минимальными затратами. Таким образом ваша staging среда всегда получает порцию реально трафика.
Gor состоит из 2-ух частей: Listener и Replay сервера. Listener устанавливается на production веб серверы, а дублирует весь трафик на Replay сервер на отдельной машине, который уже направляет его на нужные адрес. Принцип работы показан на диаграмме ниже:
Gor поддерживает ограничение количества запросов. Это очень важная настройка, так как staging как правильно использует меньше машин чем production, и вы может выставить максимальное кол-во запросов в секунду которое может выдержать ваша staging среда.
Вы можете найти подробную документацию на странице проекта.
Так как Gor написан на Go, для запуска мы можете просто использовать уже скомпилированный дистрибутив Downloads
В Granify, мы используем Gor в production в течении некоторого времени, и очень довольны результатами.
Удачного тестирования!
