Главное:
у каждой задачи на разработку есть либо стадия тестирования, либо (в нашем случае) у эпика есть сабтаск на тестирование. Пока он не выполнен, в прод ничего не идёт.

В целом краеугольное: без моего согласия ничего не заливается на прод.

Перед тем, как что-то будет выложено, всех оповещают об этом по почте, присылая табличку со стадиями продукта вида:
-----
Релизная ветка бэка создана (такая-то, тогда-то)
Релизная ветка фронта создана (такая-то, тогда-то)

Тестировщик: (решение)
Продакт менеджер: (решение)

Девопс (предварительные работы по релизу сделаны)
Релиз (дата)
Вмерджено в мастер - бэк и фронт (дата)
----

Пока в этой таблице от меня не будет согласия, релиза не будет.

Как правило я по каждому релизу ещё список багов собираю в отдельной задаче, и они разбираются потом с продактом и разрабами, что критично, что нет.

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

Можно считать это подвидом моего отчёта о тестировании.

Спасибо за подробный ответ.

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

У нас заббикс, в принципе, могу сравнивать графики и показатели с помощью него. Просто я не могу выяснить зависимости некоторые, к примеру: почему при линейно-возрастающей нагрузке в 2 минуты до 1500 rps сервер спокойно выдерживает такую эксплуатацию, а если я сразу подам эти 1500 rps с константой в те же 2 минуты, то время ответа увеличивается чуть ли не в 50 раз.

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

в любом случае попроси своих девопсов вывести тебе графики по CPU, RAM, I/O (включая сеть), по ним смотри что происходит на старте

Охх, пойду читать про работу балансера и работу нод, иначе совсем грустно

Также чекай аналогичные парамтеры для бд, бд это очень и очень часто ботлнек

и не потому что бд медленная (современный постгрес куда быстрее 90% кривых сервисов на фласке или спрингбуте), а потому что многие разрабы даже в индексы и архитектуру бд не могут

а разве я могу получить время ответа от бд?

ты - нет. Прометеус - изи. У него есть специальный постгресс_экспортер, умеющий собирать от постгресса кучу метрик. для других популярных бд тоже есть аналогичный экспортеры. С заббиксов по моему они тоже интегрируются норм, но я на прометеус + графана давно перешл уже

но ты и не должен настраивать это все, пинай своего девопса

потому что если у вас в мониторинге все это не отслеживается - вашего девопса надо пинать. возможно ногами

Хорошо, понялпринял. Спасибо большое за инфу!

Я обычно теорию не спрашиваю. Говорю есть ручка, делает то-то возвращает такой то json. Придумай 3 бизнес кейса, потом задачи по python и дальше по SQL, если все ок тогда к тимлиду

Ну и в процессе общие вопросы про статус коды, микросервисы. Но для меня критичны навык  SQL и python

Я думаю, нужно файлом

Подгон джунам, у которых спрашивают про модель сети OSI (можете сопоставить описание из интернета и увидеть на картинке, что конкретно происходит на каждом уровне):