1318
Чат DevTools Party и Я.Субботника по разработке инфраструктуры.
Всякое случалось - конкретный пример не могу привести.
Читать полностью…
Влияет. Какие то сервисы могут быть перегружены - у них срабатывают алерты - и все стопаются; На разборе выясняется что оба сервиса одновременно ходят в 3 на тесте и создают повышенную нагрузку. В случае обычных тестов на сервис - мы рекомендуем разьезжаться по времени этим тестам.
А в случае центрального Стресс-Теста - это норма - и означает что сервису в котором перегруз - пока что-то с этим делать.
Не до конца понял о чем ты - поясни пожалуйста свой вопрсо
Читать полностью…
Тут надо с умом подходить. Пищущий трафик требует повышенного внимания. И такие кейсы рассматривают в каждой команде самостоятельно. У любого теста есть цель. Стрельба по проду это процедура ответственная - так что к ней в любом случае стоит подходить обдумано. Профиль состоит из патронов - патроны либо генерируются либо создаются сборщиком - в котором владельцы настраивают фильтры. Чтобы ненужные пищущие запросы не прошли. В случае с микросервисами - редко когда у 1 сервиса есть больше 5-6 ручек - так что за этим моментом вполне реально уследить.
Читать полностью…
Это топик в Кафке- его заказывают владельцы сервиса.
Читать полностью…
Есть общие рекомендации - как с ними работать - но это зона ответственности владельцев сервиса.
Читать полностью…
Топик со статистикой живет в Kafka - если отвалится - пушка переподключится - и выгрузит то что недогрузила ранее.
Читать полностью…
Там передается хедер - для такого отсчения. Тут конечно зависит от честности обработки таких запросов.
Читать полностью…
Зависит от проекта. История с авто-масштабирование она не очень надежна - потому что тут надо учитывать - из-за чего всплеск - можно ли такое делать безболезненно.
Тут все зависит от проекта. Чаще всего народ ручками в системе управления инфраструктурой крутит ReplicaFactor туда и обратно.
Больно - у нас огромное расписание - мы его двигаем тудя сюда. Но вообще у нас есть концепт центрального стресс-теста и мы пока живем в парадигме - что мы должны мочь обеспечить массовый старт всех тестов по проду одновременно. Из этого считается капасити сервиса на будущий год и требования по ресурсам/железу и так далее.
Читать полностью…
Привет! Прямо таки любому инженеру? Насколько это безопасно? Как организованы столь масштабные стрельбы на ПРОДе, чтобы исключить влияние тестов друг на друга?
Читать полностью…
У нас есть стримовые пушки - которые ответы забирают из GRPC стрима - для тех сервисов, которые ивентами плюются. Там практически нет валидации. Любая валидация - это процессорное время генераторов. При НТ - редко кто валидирует содержимое ответов - так как это задача функционального тестирования. При наших объемах и ресурсах - мы не можем себе это позволить. Простые валидации - на коды ответов, на net коды итд - настраиваются в тесте и обеспечиваются танком. Есть еще вариант кастомных пушек - там народ пишет какие то свои валидаторы под конкретные проекты.
Читать полностью…
Этот кэмп называется "стажировка" или "буткемп" =)
Читать полностью…
Захотелось поделиться: есть такой жанр, когда google или booking, например, рассказываю как у них что-то внутри устроено. Потрогать это руками обычно тоже нельзя. Я понимаю, что у меня в этот раз было "по верхам", но рассматривайте это как поиск более глубоких тем, к которым есть интерес для будущих докладов.
Читать полностью…
У нас несколько кубер-нод - по ~100 ядер и терабайт озу каждая; Это если навскидку
Читать полностью…
В контексте танков или кафка-пушки?
Читать полностью…
Нет - как я говорил ранее - это концепт который пока внедряем. Тех кто им пользуется - пока все устраивает. Плюс кафка очень хорошо масштабируется - так что в данном случае - если слишком большая нагрузка будет на статистику - просто надо будет увеличить количество партиций.
Читать полностью…
OpenTracing тоже есть в Озон. В данном конкретном случае оно не надо было.
Читать полностью…
Как я и сказал есть Огромное количество алертов и метрик- если 911 дежурные увдят алерт из-за криво-настроенного теста - они остановят все нагрузочные тесты кнопкой. Плюс мы глазами ревьювим - такие тесты на корректность настроек и работы с рисками.
Читать полностью…
Т.е. каждый сервис сам у себя решает, как ему работать с ошибками? Повторная обработка или /dev/null?
Читать полностью…
Инфа по интенсивностям есть в мониторинге. Плюс у нас есть контур автоматического сбора патронов. Он эту задачу решает.
Читать полностью…
По разному бывает - все зависит от прострела конекретных сервисов.
Читать полностью…
Kafka большая - на проде 45 серверов. В озоне всего около 5000. Приблизительно оценить можно. Про потроха нашей кафки лучше у Виктора Корейши спросить - если увидите его на каком ни будь Митапе - он тоже часто выступает - он более профессионально на этот вопрос сможет ответить.
Читать полностью…
Если тест павильно настроен- то да. В нем сработает авто-стоп по grpc/net кодам или quantilям - или сработает авто-стоп по алертам. Собственно сработавший авто-стоп - это уже признак наличия этой точки.
Читать полностью…
Нагрузка - это то проходит в SLA по Throadput сервиса. Стресс - то что этот SLA пересекает.
Читать полностью…
Кто Как. Есть и по расписанию - можно и в CI встроить. У нас разработаны консольные утилиты - которые позволяют запускать нагрузочные тесты любому инженеру в ОЗОН из терминала или CI. Либо вообще через UI.
Читать полностью…
Хотелось бы какой нибудь кэмп, чтобы была возможность "потрогать ручками", а для вас это будет доп ос на улучшения😁
Читать полностью…
@Serge_Preis у меня математика немного не сходится:
Подскажи пожалуйста, а это у вас такой хитрый ход, сделать презентацию инструмента сборки, который на данный момент нельзя "потрогать руками" или просто захотелось поделиться решением?