Ребятки, напоминаем, что на этой неделе у нас снова 4 выходных!

С 12-15 не работаем, а 11 в среду сокращенный рабочий день :)

Ну балдёж! 😊

Самое время по-летнему отдохнуть, а может и изучить что-то новое.😉

Хэштэги по полезной инфе в нашем канале: #SQL #Java #Python #инструментыНТ

Сегодня мы отмечаем
😀😃😁🤣🙂🥰🙃🙃! 🇷🇺

Поздравляем всех с праздником!

XSET аккредитованная айти компании РФ желает вам вдохновения, новых технологических свершений и смелых идей, которые помогут развивать IT-сферу и делать наш мир лучше!🚀

📊Продолжение нашей шпаргалки по метрикам⬇️

🗣Сетевые метрики (Network):

🔵Network Throughput (Пропускная способность) – объем данных, передаваемых через сеть за единицу времени.
🔵Network Latency (Задержка сети) – время, которое требуется пакету данных для передачи от источника к получателю.

👤Пользовательские метрики (Application/User Metrics):

🔵Response Time (RT, Время отклика) – время обработки запроса системой.
🔵Requests Per Second (RPS, Запросов в секунду) – количество запросов, обрабатываемых системой за секунду.
🔵Transactions Per Second (TPS, Транзакций в секунду) – количество успешно выполненных транзакций за секунду.
🔵Error Rate (%) – процент запросов, завершившихся с ошибкой.

#советы

Нам интересно ваше мнение🙂👇

Завершаем подборку постов с метриками⬇️

🔋 JVM-метрики:

📊 Heap Memory Usage – объем памяти, используемой в куче JVM.

📊 GC Pause Time – время паузы, вызванной сборщиком мусора (Garbage Collection).

📊 Thread Count – количество потоков, запущенных в JVM.

📊 CPU Time per Thread – процессорное время, затраченное одним потоком в JVM.


🗂 Метрики базы данных:

📊 Query Response Time – время выполнения запроса к базе данных.

📊 Number of Active Connections – количество активных соединений с базой данных.

📊 Deadlocks – количество ситуаций, когда два или более запроса блокируют друг друга, не позволяя продолжить выполнение.


💡 Kafka-метрики:

📊 Messages In Per Second – количество сообщений, поступающих в топики Kafka за секунду.

📊 Lag Per Consumer Group – задержка между продюсером и консьюмером, измеряемая в количестве непрочитанных сообщений.

📊 Consumer Throughput – количество сообщений, обрабатываемых консьюмером в секунду.

📊 Producer Latency – время, затраченное на отправку сообщения в Kafka.

#советы

Апдейт прогресса ребят с 9-ого потока обучения⬇️

За последний месяц ребята подробно ознакомились с одним из самых популярных инструментов нагрузочного тестирования Locust.
Сейчас в процессе освоения SQL, скоро их ждут практические занятия для закрепления знаний. Как говорится «практика наше всё».

💡Напоминаем, что в нашем канале есть полезные лайфхаки по #SQL

“Потестим на проде” — главный антипаттерн в нагрузочном тестировании❌

Представьте: компания запускает новый сервис, но нагрузочное тестирование решили не делать. “Да всё норм будет, прод мощный, выдержит” . Но нагрузка в реальности — это не теория, а суровая практика. И вот что может случиться… 💥

❌Сайт падает на старте рекламной кампании — потому что никто не проверил, сколько пользователей он реально выдержит.
❌Мобильное приложение зависает на экране загрузки — потому что сервер перегружен запросами.
❌Очередь из заказов в e-commerce превращается в хаос — база данных не рассчитана на такой поток.
❌Система бронирования продаёт одно и то же место десяткам людей — конкурентные запросы не обработаны корректно.

Почему нагрузочное тестирование в проде — катастрофа?

1️⃣Это дорого — простой системы = потеря денег и клиентов.
2️⃣Это неконтролируемо — пиковая нагрузка может “уронить” продакшен в самый важный момент.
3️⃣Это риск для бизнеса — реальные пользователи получат негативный опыт, а репутация компании пострадает.

Как избежать этого?

✔️Имитация реальных нагрузок — моделируем поведение пользователей до выхода в прод.
✔️Тестируем на изолированной среде — чтобы ошибки не затронули настоящих клиентов.
✔️Анализируем узкие места — устраняем потенциальные сбои ДО запуска.
✔️Используем метрики и мониторинг — фиксируем, как система ведёт себя под нагрузкой.

Но бывают исключения
В очень редких случаях нагрузочное тестирование может проводиться в продакшене, НО только если:
🔵Невозможно создать аналогичную тестовую среду (например, распределённые системы с высокой нагрузкой).
🔵Задача тестирования — проверить продакшен в реальных условиях (но не сломать его!).
🔵Тест проводится под полным контролем с мониторингом и возможностью мгновенно откатить изменения.
🔵Заранее согласованы риски с командой разработки, DevOps и бизнесом.
‼️Важно! Даже если тест проходит в проде, он должен быть максимально безопасным:
➡️Проводится в часы наименьшей нагрузки.
➡️Запросы ограничены так, чтобы не уронить систему.
➡️Есть чёткий план действий, если что-то пойдёт не так.

⬇️Делитесь своим мнением в комментариях о том какие сложности могут возникнуть при моделировании реальной нагрузки.

#советы

Задачка 💡

⬇️

#проверь_себя

🐜 Как понять, что ваш тест в Locust написан неправильно?

Вы запустили тест в Locust, и всё вроде бы работает... но можно ли доверять этим результатам? 🤔
Разберём топ ошибок, которые могут сделать нагрузочное тестирование бессмысленным (или даже вредным).

🚨1. Фиксированная нагрузка без реалистичного поведения

❌Ошибка: Все виртуальные пользователи отправляют запросы с одинаковым интервалом, без пауз и случайных действий.
✅Как исправить: Настроить случайные задержки между запросами, чтобы имитировать реальное поведение пользователей.

В реальности никто не нажимает кнопку "Купить" каждую секунду без пауз, поэтому в Locust важно учитывать различные паттерны поведения.

🚨 2. Запросы не связаны между собой

❌Ошибка: В реальности пользователь сначала логинится, потом делает покупки, но в тесте запросы идут хаотично.
✅Как исправить: Выстраивать логические последовательности – сначала логин, потом поиск, затем покупка.

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

🚨3. Locust может быть узким местом

❌Ошибка: Тест показывает, что система не справляется, но причина может быть не в сервере, а в самом Locust – он перегружен и работает медленно.
✅Как исправить: Проверить, не ограничивает ли производительность сам тест:

Что делать?
🔹Посмотреть, не перегружен ли сам Locust – высокая загрузка CPU или RAM на стороне тестирующей машины может искажать результаты.
🔹Оптимизировать код теста.

#Locust

Как без тестирования производительности компании теряют миллионы? 💸

🎮 При запуске Cyberpunk 2077 в декабре 2020 года игра столкнулась с серьёзными проблемами производительности:

⭕️ На слабых консолях игра тормозила и зависала, из-за чего Sony убрала её из магазина.
⭕️ Серверы CD Projekt RED не выдержали наплыва игроков, что привело к сбоям в сетевых функциях.

📉 Итог?
- CDPR потеряла миллионы долларов на возвратах.
- Игроки массово требовали возвраты денег, а репутация компании сильно пострадала.
- Акции компании обрушились более чем на 40%.

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

🎮 Diablo III: ошибка «Error 37», ставшая мемом.
В день релиза Diablo III (2012) миллионы игроков не смогли войти в игру, получая знаменитую ошибку «Error 37».

❓Что случилось:

⭕️ Серверы Blizzard не выдержали нагрузки, так как количество одновременных подключений было выше, чем предполагалось.
⭕️ Игроки часами не могли зайти в игру, что вызвало волну критики.

📉 Итог?
- Негативный фон вокруг компании и падение пользовательского рейтинга игры.
- Ошибку «Error 37» до сих пор вспоминают, как один из худших запусков в истории Blizzard.

Причина:
- Не было проведено нагрузочного тестирования серверов перед запуском.
- Механизм масштабирования серверов оказался не готовым к такому количеству игроков.

🎮 GTA Online: неделя хаоса на старте:
Когда GTA Online (2013) вышла, миллионы игроков одновременно попытались войти в игру… и не смогли.

❓Что случилось:

⭕️ Игроки не могли подключиться к серверам в течение нескольких недель.
⭕️ Персонажи и прогресс игроков пропадали из-за сбоев в серверной инфраструктуре.
⭕️ Массовые вылеты и зависания приводили к негативным отзывам.

📉 Итог?
- Rockstar пришлось экстренно увеличивать количество серверов и компенсировать игрокам неудобства.
- Компании пришлось отложить полноценное развитие онлайн-режима на несколько месяцев.

Причина:
- Отсутствие моделирования реального пикового трафика.

Как избежать таких фейлов?

✔️Проводить тестирование производительности — заранее искать узкие места в системе.
✔️Использовать нагрузочные тесты — моделировать работу пользователей при пиковых нагрузках.
✔️Запускать стресс-тесты — проверять, как система ведёт себя при предельных нагрузках.
✔️Тестировать процесс восстановления после перегрузки.

#кейсы

📚🐍Репозиторий в GitHub со шпаргалками по Python на русском языке!

✔️Может пригодиться в любое время в процессе обучения! В них вы найдете:

⏩типы данных;
⏩функции;
⏩различные модули;
⏩декораторы;
⏩итераторы и генераторы;
⏩ООП и многое другое :)

Ссылка: https://github.com/Dv-nn/Cheat-Sheet-Python 

#Python

Отзыв об обучении с нашего текущего потока! ❤️

Всегда рады вашему мнению :)

#отзывы

Кейс 1️⃣: Netflix и предиктивный выбор тестов

❗️Проблема:
Тысячи репозиториев, миллионы тестов. Полный регрессионный прогон занимал вечность, замедляя сборки и демотивируя разработчиков.
💡Решение:
Внедрили инструмент Develocity с функцией Predictive Test Selection. ИИ анализирует изменения в коде и запускает только тесты, которые релевантны этим изменениям.
✔️Результат:
Экономия более 280 000 часов разработчиков в год.Среднее время сборки сократилось с >10 минут до 1-2 минут.Время прогона тестов сократилось на 60%.

Кейс 2️⃣: ДОМ.РФ и внутренний AI-ассистент

❗️Проблема:
Готовые решения на рынке не подходили под внутренние процессы и стек (Jira, Confluence, TestIT) или были слишком дороги.
💡 Решение:
Разработали собственного AI-ассистента, интегрированного с внутренними системами.
✔️Результат:
Время на разработку API-тестов сократилось на 50%.Покрытие автотестами выросло на 20%.Время на подготовку артефактов тестирования сократилось на 30%.

#кейсы

🔥 Топ-5 платформ для поиска удалённой работы QA-инженерам
(и где джунам тоже можно пробовать себя)

Работать в шортах на Бали или в кофейне в Ереване — уже не мечта, а реальность. Ниже — подборка проверенных платформ, где находят проекты и джуны, и мидлы 👇

#поиск_работы

1️⃣Upwork
Международная фриланс-платформа
Часто ищут QA для мануального тестирования мобильных и веб-приложений
Лайфхак: откликайтесь в первые 10–15 минут после публикации

2️⃣Toptal
Для сильных специалистов (но и джуны туда иногда пробиваются)
Нужно пройти серьёзный отбор: тест, интервью, live coding
Высокие ставки, в том числе для QA Automation

3️⃣RemoteOK
Один из крупнейших агрегаторов удалённых вакансий
Найдёшь фильтры: “QA”, “Tester”, “Manual”, “Automation”
Часто публикуются свежие офферы без привязки к локации

4️⃣Lemon.io
Платформа для найма dev и QA команд стартапами
Есть запросы на QA-фриланс, но важно говорить на английском
Подходит для тех, кто быстро адаптируется и готов работать в сжатые сроки (3–6 месяцев)

📌Совет:
Заполняй профиль, как резюме: конкретика, стек, ссылки на проекты, время отклика.

Когда баг-репорт был, но его проигнорили...

👨‍✈️ QA: “Мы всё протестировали. Всё работает идеально.”
🚢 Прод: идёт ко дну с багами в логах

🪲 А где-то в углу JIRA:
[Low Priority] — UI ломается, если нажать 3 раза подряд.
Комментарий PM: “Ну это юзеры так не делают…”

📎Мораль: баг-репортов не бывает неважных. Бывает прод, который всё запомнит.💀

👋 Ребятки, напоминаем о хэштегах с полезной инфой в нашем канале:
#SQL
#Java
#Python
#инструментыНТ
#Locust
#поиск_работы
#кейсы
#проверь_себя
#советы
#Git
#Gatling
#LoadRunner
#JMeter
#k6
#ИИ