Нагрузочное тестирование в Яндексе
#61
Отправлено 08 июня 2011 - 10:59
руководитель отдела тестирования,
Объединенная компания «Афиши» и «Рамблера»
http://www.rambler.ru/jobs/
#62
Отправлено 28 июня 2011 - 11:12
Заранее спасибо.
#63
Отправлено 28 июня 2011 - 11:19
Тут как всегда важнее что потом с этим всем делать и как анализировать. А собрать обычно не проблема.
руководитель отдела тестирования,
Объединенная компания «Афиши» и «Рамблера»
http://www.rambler.ru/jobs/
#64
Отправлено 26 октября 2011 - 09:53
Офисы разработки мы готовы открывать там, где появляются сильные команды разработки — именно так появился офис разработки в Екатеринбурге и Симферополе. Так что или создавайте хорошую команду разработки, которая потом сможет присоединиться к команде Яндекса, или можете сделать хороший стартап и поучаствовать в Яндекс.Старте :)
Какие условия для получения стартапа? Есть у меня много друзей разработчиков достаточно серьёзного уровня. Мы работаем в IT-компании, которая нас не очень интересует на перспективу. Не хотелось бы уезжать в Москву, а работать в своём городе как команда.
#65
Отправлено 26 октября 2011 - 10:52
Офисы разработки мы готовы открывать там, где появляются сильные команды разработки — именно так появился офис разработки в Екатеринбурге и Симферополе. Так что или создавайте хорошую команду разработки, которая потом сможет присоединиться к команде Яндекса, или можете сделать хороший стартап и поучаствовать в Яндекс.Старте :)
Какие условия для получения стартапа? Есть у меня много друзей разработчиков достаточно серьёзного уровня. Мы работаем в IT-компании, которая нас не очень интересует на перспективу. Не хотелось бы уезжать в Москву, а работать в своём городе как команда.
Если какого-то стартапа для Яндекс.Старта нет, то напишите, пожалуйста, о своем предложении Грише Бакунову (bobuk@yandex-team.ru) — он заместитель руководителя департамента разработки и самый правильный человек для начала такого разговора.
руководитель отдела тестирования,
Объединенная компания «Афиши» и «Рамблера»
http://www.rambler.ru/jobs/
#66
Отправлено 28 октября 2011 - 06:52
#67
Отправлено 29 октября 2011 - 20:59
BaAbaKa, а можно рассказать, что конкретно в LoadRunner вас не устроило? Ну так, чисто между нами)
На тот момент были вот такие 4 пункта именно в таком порядке:
- Объемы железа для load generator
- Цена для требуемого в масштабах Яндекса числа vusers
- Наличие зачатков хорошего генератора нагрузок внутри
- Модель на основе виртуальных пользователей (для высоконагруженного веба сильно удобнее применять hit-base подход)
руководитель отдела тестирования,
Объединенная компания «Афиши» и «Рамблера»
http://www.rambler.ru/jobs/
#68
Отправлено 07 ноября 2011 - 08:07
Написал туда, вот уже полторы недели нет никакого ответа..... :(Если какого-то стартапа для Яндекс.Старта нет, то напишите, пожалуйста, о своем предложении Грише Бакунову (bobuk@yandex-team.ru) — он заместитель руководителя департамента разработки и самый правильный человек для начала такого разговора.
#69
Отправлено 07 ноября 2011 - 08:45
Написал туда, вот уже полторы недели нет никакого ответа..... :(
Если какого-то стартапа для Яндекс.Старта нет, то напишите, пожалуйста, о своем предложении Грише Бакунову (bobuk@yandex-team.ru) — он заместитель руководителя департамента разработки и самый правильный человек для начала такого разговора.
Можно попробовать ещё через Яндекс-Старт: http://company.yandex.ru/public/start
Или через инсайдеров, я уже не.
руководитель отдела тестирования,
Объединенная компания «Афиши» и «Рамблера»
http://www.rambler.ru/jobs/
#70
Отправлено 08 октября 2012 - 20:08
Ситуация: разрабатывается сервис (приложение, сайт, ... ). Пехота прошлась по функционалу, можно теперь и по нагрузке продавить :)
У вас есть результаты тестов, допустим (не приведи Господь конечно), что всё плохо именно с точки зрения перформанса, сколько у вас времени на сообщение результатов?
Да, как-то мутнова-то получилось, пример:
Релиз нового функционала через две недели (итерация), доработали фичу и прошлись по функционалу тестировщиками ( ).
Отдали танкистам, через полторы недели.. у вас есть три дня на проведение тестов, анализ результатов и отправке "совета".. Если всё плохо, но об этом узнают за день до релиза, чего происходит?
Раньше стрелять нельзя, ибо не во что (пишется пока что), далее стрелять нельзя ибо тестируется (функциональные баги там и всё такое).. сколько времени на нагрузку отводится и что бывает , когда (не приведи Господь конечно) всё плохо?
Или у вас процессы ваще по-другому построены? Может нет определённого времени, к которому нужно выпустить новый сервис (функционал, приложение и др.).. или всё же умудряетесь стрелять с коленок, пока ещё мишень только пишется... ммм?
#71
Отправлено 20 октября 2012 - 13:31
Привет! Приму эстафету рассказов о нагрузочном тестировании в Яндексе.Андрей, такой ещё вопрос по организации процесса
Ситуация: разрабатывается сервис (приложение, сайт, ... ). Пехота прошлась по функционалу, можно теперь и по нагрузке продавить :)
У вас есть результаты тестов, допустим (не приведи Господь конечно), что всё плохо именно с точки зрения перформанса, сколько у вас времени на сообщение результатов?
Да, как-то мутнова-то получилось, пример:
Релиз нового функционала через две недели (итерация), доработали фичу и прошлись по функционалу тестировщиками ( ).
Отдали танкистам, через полторы недели.. у вас есть три дня на проведение тестов, анализ результатов и отправке "совета".. Если всё плохо, но об этом узнают за день до релиза, чего происходит?
Раньше стрелять нельзя, ибо не во что (пишется пока что), далее стрелять нельзя ибо тестируется (функциональные баги там и всё такое).. сколько времени на нагрузку отводится и что бывает , когда (не приведи Господь конечно) всё плохо?
Или у вас процессы ваще по-другому построены? Может нет определённого времени, к которому нужно выпустить новый сервис (функционал, приложение и др.).. или всё же умудряетесь стрелять с коленок, пока ещё мишень только пишется... ммм?
Итак, как устроен процесс.
Если речь идет о новом проекте, то мы можем начать исследования (либо выдать уже имеющиеся данные) компонентов сервиса, например стораджа, прокси, шаблонизатора, без интерграции в проект. Либо выделить разработчику лоад-генератор для отладки своего кода с точки зрения перфоманса, дабы не пришлось переписывать заново. Непроизводительные куски выявляются сразу, это экономит время танкистам и всему проекту.
После того как сервис готов пройти приемочное тестирование, разработчик на отладочных стрельбах не обнаружил каких-либо проблем, мы раскатываем проект в тестинге, определяемся с требованиями и проводим тесты. Обычно проблемы вылазят после первых стрельб, наша задача показать, где именно проблема. Разработчик уходит оптимизировать код, если нужно мы помогаем в исследовании узких мест и отладке.
Что касается нехватки времени. Мы даем информацию о качестве продукта, выкатить его в продакшен или нет, это дело менеджера. Он берет на себя все риски. Если времени нехватает, мы можем порекомендовать менеджеру выключить критичные фичи в продукте, которые нагрузку заведомо не держат, либо подготовить failover-механизмы для минимизации факапа.
Руководитель службы нагрузочного тестирования
компании "Яндекс"
Вакансии - http://clck.ru/3mW2f
Яндекс.Танк - http://clubs.ya.ru/yandex-tank/
#72
Отправлено 22 октября 2012 - 10:02
Привет! Приму эстафету рассказов о нагрузочном тестировании в Яндексе.
Андрей, такой ещё вопрос по организации процесса
Ситуация: разрабатывается сервис (приложение, сайт, ... ). Пехота прошлась по функционалу, можно теперь и по нагрузке продавить :)
У вас есть результаты тестов, допустим (не приведи Господь конечно), что всё плохо именно с точки зрения перформанса, сколько у вас времени на сообщение результатов?
Да, как-то мутнова-то получилось, пример:
Релиз нового функционала через две недели (итерация), доработали фичу и прошлись по функционалу тестировщиками ( ).
Отдали танкистам, через полторы недели.. у вас есть три дня на проведение тестов, анализ результатов и отправке "совета".. Если всё плохо, но об этом узнают за день до релиза, чего происходит?
Раньше стрелять нельзя, ибо не во что (пишется пока что), далее стрелять нельзя ибо тестируется (функциональные баги там и всё такое).. сколько времени на нагрузку отводится и что бывает , когда (не приведи Господь конечно) всё плохо?
Или у вас процессы ваще по-другому построены? Может нет определённого времени, к которому нужно выпустить новый сервис (функционал, приложение и др.).. или всё же умудряетесь стрелять с коленок, пока ещё мишень только пишется... ммм?
Итак, как устроен процесс.
Если речь идет о новом проекте, то мы можем начать исследования (либо выдать уже имеющиеся данные) компонентов сервиса, например стораджа, прокси, шаблонизатора, без интерграции в проект. Либо выделить разработчику лоад-генератор для отладки своего кода с точки зрения перфоманса, дабы не пришлось переписывать заново. Непроизводительные куски выявляются сразу, это экономит время танкистам и всему проекту.
После того как сервис готов пройти приемочное тестирование, разработчик на отладочных стрельбах не обнаружил каких-либо проблем, мы раскатываем проект в тестинге, определяемся с требованиями и проводим тесты. Обычно проблемы вылазят после первых стрельб, наша задача показать, где именно проблема. Разработчик уходит оптимизировать код, если нужно мы помогаем в исследовании узких мест и отладке.
Что касается нехватки времени. Мы даем информацию о качестве продукта, выкатить его в продакшен или нет, это дело менеджера. Он берет на себя все риски. Если времени нехватает, мы можем порекомендовать менеджеру выключить критичные фичи в продукте, которые нагрузку заведомо не держат, либо подготовить failover-механизмы для минимизации факапа.
Док, спасибо! :) Со всем согласен.
Тесты производительности по большому вскрывают или проблемы в архитектуре, или проблемы с кодом разной сложности, или в конфигурации среды. Первые надо вскрывать как можно раньше. Ровно для этого и привлечение специалистов по тестированию производительности на этапе проектирования более чем оправдано. Вторые — на этапе разработки (здесь правда и сам разработчик может отлаживаться и профилироваться автономно). Третьи — на этапе подготовки к эксплуатации. В таком случае все ключевые проблемы можно решать в тот же момент, когда они возникают. И тогда перед запуском обычно достаточно просто приемочного тестирования.
руководитель отдела тестирования,
Объединенная компания «Афиши» и «Рамблера»
http://www.rambler.ru/jobs/
#73
Отправлено 28 октября 2012 - 05:53
Не совсем понял этот кусочек. Лоуд-генератор понятно (машинка производящая нагрузку жеж?), что на счёт скрипта? Если функционал новый, то нужен скрипт в соответствии с которым лоуд-генератор будет нагружать сервис (сайт и др). Разработчик сам пишет новый скрипт для тестирования производительности своей части кода? Или у вас есть какие-то стандартные шаблончики, типа заготовки, куда можно вставить только параметры и как минимум стандартные запросы будут отправлены и получены ответы под нагрузкой, на которые можно будет полюбоваться (ну там время отклика транзакций, которые программист должен был создать в скрипте).Либо выделить разработчику лоад-генератор для отладки своего кода с точки зрения перфоманса, дабы не пришлось переписывать заново. Непроизводительные куски выявляются сразу, это экономит время танкистам и всему проекту.
Или использует просто профилировщик типа AMD CodeAnalyst , а остальное - ваша забота? )
Функциональное тестирование проводит сам разработчик, нет мануальных тестировщиков? То есть, когда разработчик сказал - работает, сразу эстафету принимают нагрузчики?После того как сервис готов пройти приемочное тестирование, разработчик на отладочных стрельбах не обнаружил каких-либо проблем, мы раскатываем проект в тестинге, определяемся с требованиями и проводим тесты. Обычно проблемы вылазят после первых стрельб, наша задача показать, где именно проблема. Разработчик уходит оптимизировать код, если нужно мы помогаем в исследовании узких мест и отладке.
Эт понятно , вопрос в другом, когда вы сообщаете результаты? Просто, если релиз завтра, а вы только закончили тесты и говорите - у нас всё плохо и менеджер принимает решение, выпускать не выпускать (или отключать критичные части или ещё чего). Или у вас нет фиксированной даты релиза этой части функционала.. то есть , разработчик написал, отладил.. отдал вам.. вы провели тесты, всё плохо - на доработку, и так пока не скажете - норма! Можно релизить.. Ммм?Что касается нехватки времени. Мы даем информацию о качестве продукта, выкатить его в продакшен или нет, это дело менеджера. Он берет на себя все риски. Если времени нехватает, мы можем порекомендовать менеджеру выключить критичные фичи в продукте, которые нагрузку заведомо не держат, либо подготовить failover-механизмы для минимизации факапа.
#74
Отправлено 29 октября 2012 - 05:21
лоад-генератор, это по сути Яндекс.Танк, который тремя строчками в конфиге настраивается для нагрузочного тестирования любого HTTP сервиса или компонента.Не совсем понял этот кусочек. Лоуд-генератор понятно (машинка производящая нагрузку жеж?), что на счёт скрипта? Если функционал новый, то нужен скрипт в соответствии с которым лоуд-генератор будет нагружать сервис (сайт и др). Разработчик сам пишет новый скрипт для тестирования производительности своей части кода? Или у вас есть какие-то стандартные шаблончики, типа заготовки, куда можно вставить только параметры и как минимум стандартные запросы будут отправлены и получены ответы под нагрузкой, на которые можно будет полюбоваться (ну там время отклика транзакций, которые программист должен был создать в скрипте).
Либо выделить разработчику лоад-генератор для отладки своего кода с точки зрения перфоманса, дабы не пришлось переписывать заново. Непроизводительные куски выявляются сразу, это экономит время танкистам и всему проекту.
Или использует просто профилировщик типа AMD CodeAnalyst , а остальное - ваша забота? )
о каком скрипте или шаблончиках идет речь не совсем понятно 8) если у разработчика возникает сложности с отладкой, он обязательно приходит к нам.
у нас есть фунциональщики, но в этом топике речь не о них.Функциональное тестирование проводит сам разработчик, нет мануальных тестировщиков? То есть, когда разработчик сказал - работает, сразу эстафету принимают нагрузчики?
сервисы у нас разные, но дедлайн есть практически всегда. исходя из сроков и приоритетов, но не меньше чем за неделю, мы стараемся получить первые результаты и отдать разработчику или менеджеру. если получается факап по срокам, решаем все вместе как быть, запускать, переносить, что-либо еще.Эт понятно , вопрос в другом, когда вы сообщаете результаты? Просто, если релиз завтра, а вы только закончили тесты и говорите - у нас всё плохо и менеджер принимает решение, выпускать не выпускать (или отключать критичные части или ещё чего). Или у вас нет фиксированной даты релиза этой части функционала.. то есть , разработчик написал, отладил.. отдал вам.. вы провели тесты, всё плохо - на доработку, и так пока не скажете - норма! Можно релизить.. Ммм?
Что касается нехватки времени. Мы даем информацию о качестве продукта, выкатить его в продакшен или нет, это дело менеджера. Он берет на себя все риски. Если времени нехватает, мы можем порекомендовать менеджеру выключить критичные фичи в продукте, которые нагрузку заведомо не держат, либо подготовить failover-механизмы для минимизации факапа.
да, иногда бывает, что приходят с очень срочными тасками "через час катим!!!", но ооооочень редко и мы стараемся войти в положение, авралы бывают везде.
Руководитель службы нагрузочного тестирования
компании "Яндекс"
Вакансии - http://clck.ru/3mW2f
Яндекс.Танк - http://clubs.ya.ru/yandex-tank/
#75
Отправлено 29 октября 2012 - 08:39
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных