Это вы придумали что я ставила  я сказала что не нужно лезть на прод если нет навыков тестировпния на проде тем более с нагрузкой.

Более того, я думаю Ваш опыт работы с prod минимален

Поэтому мнение неавторитетно. Спасибо.

"не нужно лезть писать на джаве если нет навыков написания прода на джаве"

А Вы часто на проде тестируете?

От моего тестирования прод не лежит. Назовем это так и финансовых потерь нет

Так именно на проде часто тестируете?

Господа заканчиваем флудить, абсолютно бессмысленное и токсичное общение

Я не рекомендую никому из этого чата тестировать на прод

У меня первая работа была Программист 1С. А первый заказ - Добавление колонки с расчетом пособия по уходу за ребенком. Было это очень давно. Тестовые стенды для 1С почти никто не держал. И правки надо было делать "на проде". Было очень страшно что-то сломать. Выгрузил конфигурацию, отнес в офис и два дня правил и тестировал ее. А потом выставил счет на 1 час работы. Заказчик удивился - как так 1 час, раньше всегда делали за 8, значит я переплатила в прошлый раз!!! Не буду платить за 1 час.

Вот мне было вообще не важно - заплатят или нет за 1 час. Главное было не сломать в этой бухгалтерии ничего 😊

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

Вам можно

🤔

🤔

Последнее китайское

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

а если вам интересно как это и почему  начните ознакомление с таким подходом, без холиварной критики

Вот хороший доклад от  Миши, где сказано - что и почему - https://www.youtube.com/watch?v=tGZAjr-hnf4&list=PL8761XQAJnrYzcp9a-lVKXwChW21ayPxB&index=4

И интересная мысль была про вычет из зарплаты

Чтобы раскрыть тему, что бывает после инцидента могу посоветовать материал от Дмитрия Химиона
с 8-й встречи общества анонимных тестировщиков
Дмитрий Химион (Авито): Детектирование и оценка сбоев
Доклад посвящен вопросам автоматизации инцидент менеджемента и оценке размера инцидентов и влиянию инцидентов на деятельность компании.

Все видео с митапа тут: https://www.youtube.com/channel/UCMJeh6AL1dmrEj0rDl8jKCw
Запомнил материал потому как сам там выступал с докладом
И в работе именно так и происходило: разбор инцидента, оценка, выводы.
Без штрафов. Внутри команд обсуждают, может более персонально, но вообще инциденты на продуктиве случаются самые разные и не по одному в день

Если поднимать юридическую сторону вопроса, то штрафов быть никаких не может (если только у вас не серая «бонусная» зарплата. Максимум, что можно сделать - через суд списать часть убытков на работника, но размер такого списания очень ограничен, не больше н-процентов от оклада в месяц и не больше н-окладов всего

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

Вот если заниматься показом рекламных баннеров, рассказывал мне об этом Алексей Рагозин, то пользователи сами нагрузят процесс показа баннеров лучше любого инструмента. И если 1% пользователей увидят не тот баннер или не увидят - не критично. И для таких систем статья актуальна. Канареечная выкладка на часть пользователей позволяет протестировать новый релиз в бою.