Дмитрий МухАндрей Панфиловпропущено...
А в чем вы противоречие нашли-то? Давайте в аналогии поиграем чтоли... Вот я езжу на машине, подливать бензин и следить чтобы двигатель не перегревался - это моя область отвественности как эксплуатанта, а ремонтировать поломки - это уже ответственность сервис центра (ну или дяди Васи из соседнего гаража - тут уж каждый сам принимает решение как вертеться). Я довольно слабо представляю каким образом эксплуатант может самостоятельно решать проблемы производительности кроме как заводить CR с правильным описанием проблемы, ну вот если очевидно что проблема в коде, то каким образом эксплуатант сможет исправить поведение? Декомпилировать классы, разворачивать среду сборки, слетать с поддержки, так чтоли? Более того, я реально встречался с ситуацией, когда эксплуатант по наитию APM (Grid Control оракловый) налепил в системе индексов и фиксированных планов запросов, так вот первым же шагом оптимизации было удалить все левые индексы (на самом деле не все, а только половину, а остальную половину переделать в "другую" сторону) и кривые планы.
Я не ищу противоречия, а хочу уточнить определённые моменты.

Вернёмся к вопросу ТС, используя ваши термины: эксплуатанты обнаружили, что внезапно тормозит определённая операция в REST API, при чём проблема точно не в БД.
Соответсвенно они решили обратиться к вам как к разработчику данного REST API.

Что вы будете делать в такой ситуации?
То что эксплуатанты обнаружили не имеет никакого значения. Могут выкинуть в ведро или подтереться.
Пока не будет заведена JIRA с приоритизацией - можно ничего не делать. Кому нужна эта рест-операция? Business -value?
Может она нахер не нужна? Может клиент без нее работать? Может она считает число лайков?

Андрей ПанфиловmaytonТо что эксплуатанты обнаружили не имеет никакого значения. Могут выкинуть в ведро или подтереться.
Пока не будет заведена JIRA с приоритизацией - можно ничего не делать. Кому нужна эта рест-операция? Business -value?
Может она нахер не нужна? Может клиент без нее работать? Может она считает число лайков?Это больше про то, что существующие системы багтрэгинга (incident management и пр., как вам будет угодно называть) ничего общего с реальностью не имеют, по науке (тут я приминаю как должное что не все книжки по специальности читали) приоритет в багтрэкинге - это суперпозиция влияния на бизнес и критичности, а по факту получается так, что приоритеты в багтрэкинге ставят от балды, в результате не выходе получается то что получается.
Человек опытный в эксплуатации обычно правильно приоритезирует. Но если он поставит блокер
а у вас есть какие-то другие задачи - то это лишний повод поговорить о том кто чем занят.
Это полезно и проясняет статус-кво.