Здравствуйте, Pauel, Вы писали:

P>>>Вы выкатили в прод, значительной часть логов не появляется вовсе. Вот тебе и "QA не нужен".
P>·>Для наших логов QA не нужен. Для хедеров отправляемых наружу — нужен. Логи такого типа это дело разработчиков и никого больше не касается.
P>На ваши логи завязана такая капабилити, как уведомление той стороны о проблемах(SLA). Следовательно, нужен QA который скажет, что логи соответствуют вашим внутренним ожиданиям(предоставить гарантии SLA).
Не очень что ты конкретно имеешь в виду, что именно завязано? Скажем, в рассматриваемом примере deprecated api, нам не нужны логи, мы и так уже знаем, что некий наш API мы решили сделать deprecated.
Формально мы по логам можем ответить на вопрос, мол, сколько в данный момент запросов мы получаем на deprecated api, но это не слишком полезное знание. Ибо наличие/отсутствие реальных запросов ни о чём не говорит. Важно получить подверждение от всех клиентов, что они переписали свои приложения на новый API, успешно всё задеплоили и не собираются делать rollback. Вот только такое явное подтверждение может дать более менее сильную гарантию, что нам не побегут с прода несущие убытки злые клиенты. Наличие варнингов, хедеров, мониторинга — ни о чём. Ибо, повторюсь, проблема административная, требующая коммуникации, _двухсторонней_, между людьми, а не между приложениями.

P>>>У тебя всё на емейл завязано. Вы кинули куда то емейл — там должен сидеть человек, чья работа будет заключаться в первичном сборе сведений, и только потом он должен форвардить реквест той или иной команде...
P>·>Ровно то, что у тебя происходит на шаге 6 и 7.
P>6 и 7 это работа L2 конкретной команды. А у тебя эту команду еще разыскать надо методом форварда емейлов и анализом трейсов.
У тебя ровно то же: А вот через транспорт однозначно известно, что происходит — нажали кнопку "показать трейсы" и сразу нашли, что вон тот сервис принадлежит команде ххх.
Или ты в прыжке переобуваешься?

P>>>Отфорвардил. И что? А там менеджер ушел в отпуск, и к L2 это не попадёт.- Или ты предлагаешь емейлы слать на всех причастных? Эдак вообще ничего не будет обработано.
P>·>Чейсить и эскалайтить. Ровно то что должно происходить у тебя на шагах 6 и далее.
P>·>Проблема в том, что у тебя в твоей схеме обрыв в коммуникации. До того как вам прибегут с прода злые клиенты ты не знаешь что происходит начиная с 4го шага.
P>Если они прибегают, то мы спрашиваем у них request id и мы можем показать весь процессинг на нашей стороне.
Вот именно. Т.е. хедер не особо то и нужен.

P>>>Совсем не то.
P>·>А что?
P>При условии добросовестной реализации или использования нашего клиента можно ожидать
Это слишком невероятное условие. Практически наверняка невыполнимое для тысяч консьюмеров.

P>Отсюда ясно, что информирован будет L2 непосредственно того самого сервиса.
Проблема не в том, кто информирован, а в том, что коммуникация односторонняя. А следовательно non-guarateed message delivery.

P>А в твоём случае этого L2 еще найти надо будет перекидыванием тикетов и форвардом емейлов.
Или трейсом по request-id. Техническая реализация не так важна.

P>>>Снова какая то магия, ну или неявные предположения, как работает та или иная контора.
P>·>Расскажи как работает ваша контора.
P> Зачем? ты делаешь слишком много предположений. В норме нужно предоставлять не только сам ответ, но и диагностику. Обслуживание сервисов стоит чудовищно дорого из за ручного труда. Если подкидываешь с ответом еще и диагностику, то значительную часть таких издержек можно автоматизировать.
Верно. Но совершенно необязательно диагностику прокидывать по тому же каналу.
Более того, это не всегда технически возможно использовать тот же канал. Ты так и не предложил как это делать в отличных от REST request-response случаях Т.е. решение, как минимум, не универсальное, а значит всё равно понадобится другое решение.