Сообщение 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>>Снова какая то магия, ну или неявные предположения, как работает та или иная контора.
·>Расскажи как работает ваша контора.
Зачем? ты делаешь слишком много предположений. В норме нужно предоставлять не только сам ответ, но и диагностику. Обслуживание сервисов стоит чудовищно дорого из за ручного труда. Если подкидываешь с ответом еще и диагностику, то значительную часть таких издержек можно автоматизировать.
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>>Снова какая то магия, ну или неявные предположения, как работает та или иная контора.
·>Расскажи как работает ваша контора.
Зачем? ты делаешь слишком много предположений. В норме нужно предоставлять не только сам ответ, но и диагностику. Обслуживание сервисов стоит чудовищно дорого из за ручного труда. Если подкидываешь с ответом еще и диагностику, то значительную часть таких издержек можно автоматизировать.
P>>Вы выкатили в прод, значительной часть логов не появляется вовсе. Вот тебе и "QA не нужен".
·>Для наших логов QA не нужен. Для хедеров отправляемых наружу — нужен. Логи такого типа это дело разработчиков и никого больше не касается.
На ваши логи завязана такая капабилити, как уведомление той стороны о проблемах(SLA). Следовательно, нужен QA который скажет, что логи соответствуют вашим внутренним ожиданиям(предоставить гарантии SLA).
P>>У тебя всё на емейл завязано. Вы кинули куда то емейл — там должен сидеть человек, чья работа будет заключаться в первичном сборе сведений, и только потом он должен форвардить реквест той или иной команде...
·>Ровно то, что у тебя происходит на шаге 6 и 7.
6 и 7 это работа L2 конкретной команды. А у тебя эту команду еще разыскать надо методом форварда емейлов и анализом трейсов.
P>>Отфорвардил. И что? А там менеджер ушел в отпуск, и к L2 это не попадёт.- Или ты предлагаешь емейлы слать на всех причастных? Эдак вообще ничего не будет обработано.
·>Чейсить и эскалайтить. Ровно то что должно происходить у тебя на шагах 6 и далее.
·>Проблема в том, что у тебя в твоей схеме обрыв в коммуникации. До того как вам прибегут с прода злые клиенты ты не знаешь что происходит начиная с 4го шага.
Если они прибегают, то мы спрашиваем у них request id и мы можем показать весь процессинг на нашей стороне.
P>>Совсем не то.
·>А что?
При условии добросовестной реализации или использования нашего клиента можно ожидать
1. корректные логи
2. мониторинг прикрученый к этим логам
Отсюда ясно, что информирован будет L2 непосредственно того самого сервиса.
А в твоём случае этого L2 еще найти надо будет перекидыванием тикетов и форвардом емейлов.
P>>Снова какая то магия, ну или неявные предположения, как работает та или иная контора.
·>Расскажи как работает ваша контора.
Зачем? ты делаешь слишком много предположений. В норме нужно предоставлять не только сам ответ, но и диагностику. Обслуживание сервисов стоит чудовищно дорого из за ручного труда. Если подкидываешь с ответом еще и диагностику, то значительную часть таких издержек можно автоматизировать.