Купер.тех

💔 Что делать, если упала производительность?

Плохой план обычно выглядит так:
посмотреть логи → открыть код → предположить самое очевидное → ошибиться → повторить ещё несколько раз.

Чтобы не тратить много времени на поиск проблемы, в Go есть pprof — встроенный профилировщик, который показывает, где сервис действительно тратит ресурсы.

В карточках инженер-разработчик на Go Артём Юзюк рассказывает, как с его помощью искать утечки горутин, проблемы с памятью и горячие точки в коде.

CodeFest всё! Насыщенные вышли выходные 🚀

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

Спасибо всем, кто был с нами! И Новосибирску за теплый прием. Вы супер, CodeFest в сердечке, а общение бесценно. ❤️

🔥 Передаём привет от нашей команды с CodeFest!
Мы тут со стендом, хорошим настроением и инженерными разговорами — заглядывай, пока конференция в самом разгаре.

🎉 Хабру исполняется 20 лет!

А значит, самое время вспомнить, как всё начиналось!
Собрали ретро-карточки, в которых вспоминаем ранний Хабр и рассказываем, когда там появился Купер.тех.

И раз уж сегодня говорим про Хабр, есть ещё один приятный повод.
Сразу три наших статьи попали в шорт-лист премии «Технотекст»:

✨«Как запускать проекты без команды? Главное о кросс-командном проджект-менеджменте» — Марина Гончарова

✨«LLM‑разметка в поиске: от эксперимента к инструменту» — Александр Баранов

✨«Три мушкетера из мира DevSecOps. Внедряем инструменты для развития AppSec-процессов» — Максим Коровенков

Гордимся ребятами! ❤️

⚡️Новосибирск, мы едем!

30–31 мая будем со стендом на конференции CodeFest, где можно будет пообщаться с нашими экспертами, задать вопросы, поучаствовать в активностях и просто провести время по-соседски, как мы любим.

Если планируете быть на CodeFest, заглядывайте к нам. Будем рады познакомиться или увидеться снова.❤️

🌍Тестировать нельзя надеяться

В Купер.тех много микросервисов, интеграций и сценариев, которые завязаны друг на друга. Поэтому тестирование здесь редко ограничивается проверкой одной фичи: важно понимать, как изменение поведёт себя в системе целиком и что будет под нагрузкой.

В мини-интервью Арсений Лагутин, руководитель обеспечения качества тестирования, рассказал, как в большом e-commerce-продукте подходят к QA:

👉 Проверяете ли вы отдельные сервисы изолированно или чаще тестируете пользовательский путь целиком?

Основной объем нашей системы представляют собой микросервисы. Подход и уровни тестов зависят от задачи, модулей системы, которые она затрагивает или влиянию на пользовательский путь. Новую реализованную фичу в ветке стараемся проверять на изолированном окружении для сохранения гигиены master. Здесь же запускаем изолированные функциональные и интеграционные автотесты. Далее, при необходимости, проводится ручное интеграционное тестирование и Е2Е, а также приемочное на production или stage окружениях.

👉 Какие инструменты и подходы используете для автоматизации тестирования?

Тут у нас «сборная солянка». Для автоматизации используем Golang, Python, JS (Detox) и TS (Playwright). Определяем уровни автоматизации под потребности системы и команды, а зону ответственности делим между QA и разработчиком. Автоматизируем в рамках своей предметной области и стараемся запускать прогоны на каждое новое изменение сервиса. Автоматизацией занимается QA в продуктовой команде, а не отдельный департамент. За счет глубокого знания тестируемой области повышаем эффективность автотестов и стараемся привлекать разработку для разбора упавших автотестов в рамках создаваемых ими изменений.

👉 Как вы понимаете, что система готова к высоким нагрузкам и «переживёт» сезонный пик?

Ориентируемся на цели бизнеса прежде всего. Основным фактором для нас является ожидаемое число заказов. В компании имеется инструменты для проведения нагрузочного тестирования как на stage, так и на production окружениях изолированно для сервисов и Е2Е (в связке) на отдельных тестовых сущностях. Нагрузочное тестирование проводим на регулярной основе и в рамках валидации крупных изменений. Успехом является соответствие ожидаемой выдерживаемой нагрузки относительно бизнес-целей и реальной, полученной на production-окружении. В случае отклонений анализируем, проводим оптимизации и повторяем, пока всё не будет хорошо работать.

👉 Насколько QA вовлечён в продуктовые решения?

QA подключаем к ранним этапам SDLC. Для нас это окончание Discovery, когда продукт сформировал свое видение задачи и оформил по нему ожидания. Из-за отсутствия формализации требований не проводим классического анализа, а вместе с командой разбираемся, как задача должна работать технически, какие есть риски и какой подход выбрать.
Так удаётся заранее заметить, где ожидания продукта могут расходиться с техническими ограничениями или логикой системы. В итоге часть ошибок мы ловим ещё до разработки, а значит быстрее и дешевле доводим задачу до релиза.

👀 Иногда случайно узнаёшь прошлую специализацию коллеги —
и потом уже невозможно смотреть на него как раньше.

Собрали истории ребят из нашей команды о том, как они меняли профессии, учились с нуля, писали OpenSource-проекты, строили дороги, переводили с японского и в какой-то момент поняли, что хотят заниматься технологиями. Сейчас все они работают в Купер.тех и развивают наши продукты.

🏃Если у вас тоже есть такая история — делитесь в комментариях!