Информация об изменениях

Сообщение Re[71]: Идемпотентность POST - хорошая ли практика? от 13.10.2022 12:53

Изменено 13.10.2022 13:04 Pauel

Re[71]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, ·, Вы писали:

P>>Вы выкатили в прод, значительной часть логов не появляется вовсе. Вот тебе и "QA не нужен".

·>Для наших логов QA не нужен. Для хедеров отправляемых наружу — нужен. Логи такого типа это дело разработчиков и никого больше не касается.

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

P>>У тебя всё на емейл завязано. Вы кинули куда то емейл — там должен сидеть человек, чья работа будет заключаться в первичном сборе сведений, и только потом он должен форвардить реквест той или иной команде...

·>Ровно то, что у тебя происходит на шаге 6 и 7.

6 и 7 это работа L2 конкретной команды. А у тебя эту команду еще разыскать надо методом форварда емейлов и анализом трейсов.

P>>Отфорвардил. И что? А там менеджер ушел в отпуск, и к L2 это не попадёт.- Или ты предлагаешь емейлы слать на всех причастных? Эдак вообще ничего не будет обработано.

·>Чейсить и эскалайтить. Ровно то что должно происходить у тебя на шагах 6 и далее.
·>Проблема в том, что у тебя в твоей схеме обрыв в коммуникации. До того как вам прибегут с прода злые клиенты ты не знаешь что происходит начиная с 4го шага.

Если они прибегают, то мы спрашиваем у них request id и мы можем показать весь процессинг на нашей стороне.

P>>Совсем не то.

·>А что?

При условии добросовестной реализации или использования нашего клиента можно ожидать
1. корректные логи
2. мониторинг прикрученый к этим логам
Отсюда ясно, что информирован будет L2 непосредственно того самого сервиса.
А в твоём случае этого L2 еще найти надо будет перекидыванием тикетов и форвардом емейлов.

P>>Снова какая то магия, ну или неявные предположения, как работает та или иная контора.

·>Расскажи как работает ваша контора.

Зачем? ты делаешь слишком много предположений. В норме нужно предоставлять не только сам ответ, но и диагностику. Обслуживание сервисов стоит чудовищно дорого из за ручного труда. Если подкидываешь с ответом еще и диагностику, то значительную часть таких издержек можно автоматизировать.
Re[71]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, ·, Вы писали:

P>>Вы выкатили в прод, значительной часть логов не появляется вовсе. Вот тебе и "QA не нужен".

·>Для наших логов QA не нужен. Для хедеров отправляемых наружу — нужен. Логи такого типа это дело разработчиков и никого больше не касается.

На ваши логи завязана такая капабилити, как уведомление той стороны о проблемах(SLA). Следовательно, нужен QA который скажет, что логи соответствуют вашим внутренним ожиданиям(предоставить гарантии SLA).

P>>У тебя всё на емейл завязано. Вы кинули куда то емейл — там должен сидеть человек, чья работа будет заключаться в первичном сборе сведений, и только потом он должен форвардить реквест той или иной команде...

·>Ровно то, что у тебя происходит на шаге 6 и 7.

6 и 7 это работа L2 конкретной команды. А у тебя эту команду еще разыскать надо методом форварда емейлов и анализом трейсов.

P>>Отфорвардил. И что? А там менеджер ушел в отпуск, и к L2 это не попадёт.- Или ты предлагаешь емейлы слать на всех причастных? Эдак вообще ничего не будет обработано.

·>Чейсить и эскалайтить. Ровно то что должно происходить у тебя на шагах 6 и далее.
·>Проблема в том, что у тебя в твоей схеме обрыв в коммуникации. До того как вам прибегут с прода злые клиенты ты не знаешь что происходит начиная с 4го шага.

Если они прибегают, то мы спрашиваем у них request id и мы можем показать весь процессинг на нашей стороне.

P>>Совсем не то.

·>А что?

При условии добросовестной реализации или использования нашего клиента можно ожидать
1. корректные логи
2. мониторинг прикрученый к этим логам
Отсюда ясно, что информирован будет L2 непосредственно того самого сервиса.
А в твоём случае этого L2 еще найти надо будет перекидыванием тикетов и форвардом емейлов.

P>>Снова какая то магия, ну или неявные предположения, как работает та или иная контора.

·>Расскажи как работает ваша контора.

Зачем? ты делаешь слишком много предположений. В норме нужно предоставлять не только сам ответ, но и диагностику. Обслуживание сервисов стоит чудовищно дорого из за ручного труда. Если подкидываешь с ответом еще и диагностику, то значительную часть таких издержек можно автоматизировать.