Сообщение Re[65]: Идемпотентность POST - хорошая ли практика? от 12.10.2022 8:55
Изменено 12.10.2022 14:42 Pauel
Re[65]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, ·, Вы писали:
P>>Ты заменил их на емейлы, которые ненадежны по своей природе. То есть, надо ждать регулярных фейлов.
·>Я не заменил, а предложил использовать тот же коммуникационный механизм, который у тебя уже существует на 7-8 шагах. Емейл — это лишь наиболее частый случай.
Кому ты емейлы слать будешь? На той стороне вполне себе возможна ситуация что N консумеров-клиентов-подразделений и чуть не все пользуются одними и теми же идентификаторами client,product,и тд.
С чего ты взял, что у них там идеальный порядок?
Итого — кому емейл слать, в чью джиру репортать?
А вот через транспорт однозначно известно, что происходит — нажали кнопку "показать трейсы" и сразу нашли, что вон тот сервис принадлежит команде ххх. И на той стороне всё находится мгновенно, достаточно прикрутить мониторинг.
P>>·>Что же твой код делает? Монетку подбрасывает?
P>>Это уже не важно. Главное, что ассерты и тесты это немного разные классы задач, которые всего лишь пересекаются.
·>Важно для того чтобы "в логах появилась нужная мне инфа".
Абсолютно не важно. Ассертам без разницы, что делает вызывающий код, они вызываются всегда, в том их бенефит.
P>>Неверно. Речь о проблемах во входных данных. Ровно как с компилятором — подкидываешь ему код, а он кидает тебе результат + варнинги.
·>Это плохая аналогия. Ибо с компилятором нет административной проблемы, которую мы обсуждаем.
Ну ок.
Вот пришел тебе в хидерах x-сaller: client=client-v-1245;product=2455a29;api-key=xxx-yyy-zzz + x-request-id:234234523k4j5kjh534 + x-forwarded установлен
Предложи надежное решение, что бы оперативно сообщить той самой команде о проблеме, желательно минуя человечечский фактор.
Разумеется, порядка на той стороне ждать не нужно — у тебя из той сети/подсети идут запросы миллионами, и id клиента/продукта просто копипастили, ибо "а так работает", api-key выдан один раз на всю контору, ибо так чудовищно дешевле.
P>>Не стоит валять дурака — здесь была речь о том, что ты не в курсе ассертов. И я показал как это искать ассертами.
·>Я не просил рассказывать ничего про ассерты. И в чём я в курсе или нет, ты не знаешь. Разговор идёт про хедер.
Ты спросил — откуда возьмется варнинг. Я тебе сказал — из ассертов. Потом ты начал валять дурака и делать вид, что не в курсе ассертов. Хотя, может ты и не валял ничего, а просто не в курсе ассертов — сколько мы с тобой ни говорим, у тебя с ассертами какие то сложности.
·>Хм, интересное определение. а если if + LOG.info или if + LOG.trace — это тоже ассерт?
Тоже. Ассерт это шорткат для таких вещей. Ассертами это делается как вариант вот так
И разумеется всё это можно включать-выключать.
>А вот такой код: if(condition){LOG.info("X"); doX();} else {LOG.warn("Y"); doY();}? Это лог или уже ассерт?!
Это условный вызов doX и doY + логирование.
P>>Ассерты при правильном применении детектят определенные классы проблем, которые не обнаруживаются тестами.
·>Круто, конечно. Но я тебя спрашивал о хедере.
Ты спрашивал в т.ч. откуда появится соответствующее сообщение в хидере.
·>Это не мой кругозор, а очередное твоё уникальное понимание терминологии. Вот общепринятое понятие:
·>
Какое незамутнённое враньё
Глянем фрагмент чуть больше, тот самый, который ты старательно вырезал:
И по твоей же ссылке указано, что это далеко не единственное предназанчение ассертов. Вобщем, даже с такой ссылкой ты всё равно отказываешься узнать, а что же за зверь такой, эти ассерты.
Например, где то в дебрях БЛ мы помечаем Deprecate.assert(condition, message) — на тот случай, если код таки будет вызван из старого апи. В этом случае варнинг появится не просто при вызове старого апи, а только если это старое апи тригерит кое какую функциональность.
P>>Да тебе похоже ясно только как емейлы слать, которые не то читают, не то нет
·>Не только емейлы, а только не хедеры. Перечитай что ещё обсуждалось, если с памятью проблемы.
На счет твоего понимания емейлов есть сомнения, т.к ты не объяснил, куда именно ты будешь слать емейлы и какой предлагается флоу, end-2-end.
P>>"разработчики уже заняты чем то другим, а может и уволились"
·>И что? Кто полезет в код, чтобы разобраться что означает данный хедер и его значение? Тоже команда эксплуатации?!
А это и не надо делать. Хидер это старндартная капабилити в апи. Готовый клиент при наличии этого хидера сам залогирует всё, что необходимо.
гатевей тоже сможет сделать такое, и залогировать.
То есть, в код даже смотреть не надо, а сообщение оперативно получат именно те, кто ответственны за эксплуатацию конкретного сервиса на той стороне
P>>Т.е. все ложится на команду эксплуатации. Им что, следить за всеми анонсами всех сервисов? Эдак придется штат раз в десять раздуть.
·>За анонсами, ясен пень, следить надо. Примеров других анонсов, не относящихся к deprectated я уже приводил несколько.
Я слабо представляю, что бы команда эксплуатации следила за всеми такими анонсами. У них обычно дел по самые нидерланды.
P>>Не ясно, что конкретно ты предлагаешь, какой флоу и что делать, если емейл опоздал, затерялся, итд
·>Емейл — это сообщение. Попробуй поизучать вопросы как организовывать надёжную коммуникацию в системах обмена сообщениями.
Ты никак не можешь рассказать про весь цикл коммуникации, ограничиваешься общими утверждениями. Какой в этом смысл?
У нас простая задача — у нас случилось нечто, и надо оперативно дать знать той самой команде на той стороне. И проблема в том, что на той стороне под конкретным client/product id может сидеть сколько угодно сервисов/продуктов/команд и тд.
·>В том то и дело, что хедеры работают только если
·>1 если их читают все кому нужно
автоматизируется
·>2 вовремя
автоматизируется
·>3 и после чтения хедера точно известны последствия конкретно в твоем продукте
сообщение получат именно те люди, которые в курсе таких дел.
P>>Если п1 еще можно как то гарантировать, то 2 случается не так уж часто, а 3 это вообще какая то магия.
·>А с хедерами п1 даже невозможно гарантировать.
Наоборот.
·>Мы анализируем свои логи и видим какие к нам приходят запросы. Если мы хотим что-то поменять в логике обработки этих запросов, мы исследуем импакт для всех вариаций реальных запросов.
А степень последствий для вызывающего кода какие? Останов сервиса, убытки, итд, вот это как вы анализируете?
P>>Каким образом анализируя ваши логи/мониторинг вы узнаете, что у него случится denial of service ?
·>Я не понял сценарий. Расскажи детальнее, может с каким-нибудь внятным примером.
Элементарно — ошибка то на их стороне, которая приводит к dos. Раз ты в респонсе не сообщаешь нужной инфы, то выйти из dos они могут только в том случае, когда спустя слои переписок всё дойдет до конкретного L2, и тот перестартует сервис.
P>>Что фиксить? Проблема на вызывающей стороне, у них ожидания не соответствуют вашему апи. Начнешь перепиливать апи, что бы угодить всем?
·>твой хедер можно послать только на основе запроса. Если мы упустили какой-то precondition по структуре запроса и стали возвращать неожиданный результат, то это наша проблема, нам и фиксить.
Ну то есть, если тебя ктото продолжит называть по девичьей фамилии, ты заведешь второй паспорт, так что ли?
На нашей стороне все в порядке — небольшая функция в старом апи депрекейтнулась, и вызывается в дебрях БЛ. Заранее узнать, будет ли такой вызов, или нет, не представляется возможным.
P>>Технически — ничем. Главное, что бы ихний мониторинг сработал. Варнинг — это дополнительная фича АПИ, когда мы передаем информацию о качестве результата.
·>Нет. Мы выяснили, что главное, чтобы не мониторинг сработал (это лишь средство), а чтобы они предприняли некие действия и изменили их код (а вот это цель).
В том то и дело, что выяснить ответсвенное лицо бывает крайне сложно, например, потому что client-id, product-id, api-key одни и те же на всех.
P>>Предлагаешь на миллион запросов создавать миллион тикетов в джыре? Или писать AI который будет фильтровать, тот ли это баг или не тот?
·>Так в этом и суть, что не надо посылать миллион. Надо послать ровно один. А вот хедеров посылается миллион.
В какой из 1000 команды ты создашь джыра тикет? С т.з. твоего сервиса это один клиент/консумер/итд. C их т.з. таких целая тыща.
P>>ну да, ты то без багов пишешь, я помню — у тебя баги на прод не попадают.
·>Да, попадают. И да, это эпик фейл.
Слава богу. А то в прошлый раз ты на полном серьезе утверждал, что такого у вас быть не может.
·>Верно. Но технические средства нужно выбирать адекватно. Выбирать между одним емейлом (джирой, етс) и хедером в миллионах респонзов — надо на основе технических параметров. А вы выбрали лишь потому что у вас так принято, а с емейлами справиться не смогли, из-за административных проблем.
Неверное предположение. Что бы справиться с емейлами, нужно наладить коммуникацию со всеми из консумеров, что намного сложнее чем с одним. И надо понавводить целую кучу требований, ограничения именно для той стороны, и добиться что бы они этому следовали. Без этого емейлы работать не будут.
P>>Единственное, что делает менеджмент, это принятие решений, как именно будет решаться та, или иная проблема. Скажет решать емейлами — будет решаться емейлами.
P>>Скажет, что чрез транспорт реквеста — будет решаться через хидеры.
·>Т.е. у вас менеджемент решает технические вопросы? Мде. Тогда ясно.
Менеджер принимает решение. Например, архитектор — это менеджерская позиция. А у вас что, архитектор это разновидность девелоперов?
P>>·>Технически емейл от хедера в данном отличается лишь протоколом, smtp vs http. У хедеров ровно те же административные проблемы.
P>>Не только. хедер лежит вместе с респонзом, request-id и прочими вещами, не надо никаких приседаний, что бы начать инвестигейт.
·>В емейл можно положить и это, и гораздо больше.
И как он дойдет до ответсвенного лица? Полагаю так — шлете CEO, он форвардит подчиненным, те — своим подчиненным, и так пока не дойдет до того самого L2.
P>>Проблема на их части продакшна, что очевидно. Вот и нужно максимально быстро сигнализировать именно на той части.
·>Т.е. благодаря хедеру вы принесли убытки своему клиенту. Молодцы, чё.
Наоборот.
P>>Вот-вот. Ты то хвастался, что impact analysis делаешь, а однако никаких средств у тебя на то нет
·>Читаешь невнимательно. На нашей стороне — есть.
А надо бы и на той стороне глянуть. Какой юзкейс БЛ завязан на конкретный реквест ты не в курсе, а это самое важное.
P>>Емейл как стандарт работает плохо — майлбоксы у ключевых людей как правило переполнены.
·> Но хедеры они читают!!
Хидеры читают технические средства, а дальше все проблемы видны на мониторинге. Ты или юродствуешь, или вообще не в курсе, про что пишешь.
P>>Джира получше, только создавать тикет надо не в твоей джире, а на той стороне, куда у тебя доступа нет
·>Это опять же административная проблема, и фиксится за минуту.
Ну расскажи, в какой джире надо создать тикет, и когда именно, если все запросы исходят будто бы от одного сервиса на той стороне, а на самом деле там сотни команд/продуктов/сервисов со своими трекерами.
P>>Ты заменил их на емейлы, которые ненадежны по своей природе. То есть, надо ждать регулярных фейлов.
·>Я не заменил, а предложил использовать тот же коммуникационный механизм, который у тебя уже существует на 7-8 шагах. Емейл — это лишь наиболее частый случай.
Кому ты емейлы слать будешь? На той стороне вполне себе возможна ситуация что N консумеров-клиентов-подразделений и чуть не все пользуются одними и теми же идентификаторами client,product,и тд.
С чего ты взял, что у них там идеальный порядок?
Итого — кому емейл слать, в чью джиру репортать?
А вот через транспорт однозначно известно, что происходит — нажали кнопку "показать трейсы" и сразу нашли, что вон тот сервис принадлежит команде ххх. И на той стороне всё находится мгновенно, достаточно прикрутить мониторинг.
P>>·>Что же твой код делает? Монетку подбрасывает?
P>>Это уже не важно. Главное, что ассерты и тесты это немного разные классы задач, которые всего лишь пересекаются.
·>Важно для того чтобы "в логах появилась нужная мне инфа".
Абсолютно не важно. Ассертам без разницы, что делает вызывающий код, они вызываются всегда, в том их бенефит.
P>>Неверно. Речь о проблемах во входных данных. Ровно как с компилятором — подкидываешь ему код, а он кидает тебе результат + варнинги.
·>Это плохая аналогия. Ибо с компилятором нет административной проблемы, которую мы обсуждаем.
Ну ок.
Вот пришел тебе в хидерах x-сaller: client=client-v-1245;product=2455a29;api-key=xxx-yyy-zzz + x-request-id:234234523k4j5kjh534 + x-forwarded установлен
Предложи надежное решение, что бы оперативно сообщить той самой команде о проблеме, желательно минуя человечечский фактор.
Разумеется, порядка на той стороне ждать не нужно — у тебя из той сети/подсети идут запросы миллионами, и id клиента/продукта просто копипастили, ибо "а так работает", api-key выдан один раз на всю контору, ибо так чудовищно дешевле.
P>>Не стоит валять дурака — здесь была речь о том, что ты не в курсе ассертов. И я показал как это искать ассертами.
·>Я не просил рассказывать ничего про ассерты. И в чём я в курсе или нет, ты не знаешь. Разговор идёт про хедер.
Ты спросил — откуда возьмется варнинг. Я тебе сказал — из ассертов. Потом ты начал валять дурака и делать вид, что не в курсе ассертов. Хотя, может ты и не валял ничего, а просто не в курсе ассертов — сколько мы с тобой ни говорим, у тебя с ассертами какие то сложности.
·>Хм, интересное определение. а если if + LOG.info или if + LOG.trace — это тоже ассерт?
Тоже. Ассерт это шорткат для таких вещей. Ассертами это делается как вариант вот так
Trace.assert(condition, message)
Info.assert(condition, message)
Warning.assert(condition, message)
Error.assert(condition, message)И разумеется всё это можно включать-выключать.
>А вот такой код: if(condition){LOG.info("X"); doX();} else {LOG.warn("Y"); doY();}? Это лог или уже ассерт?!
Это условный вызов doX и doY + логирование.
P>>Ассерты при правильном применении детектят определенные классы проблем, которые не обнаруживаются тестами.
·>Круто, конечно. Но я тебя спрашивал о хедере.
Ты спрашивал в т.ч. откуда появится соответствующее сообщение в хидере.
·>Это не мой кругозор, а очередное твоё уникальное понимание терминологии. Вот общепринятое понятие:
·>
an assertion failure – the program considers itself to be broken and typically deliberately crashes or throws an assertion failure exception.
Какое незамутнённое враньё
Глянем фрагмент чуть больше, тот самый, который ты старательно вырезал:То есть — если предназначение ассерта это детект собственных ошибок, то надо крешит или бросать исключение.Assertions can help a programmer read the code, help a compiler compile it , or help the program detect its own defects.
For the latter, some programs check assertions by actually evaluating the predicate as they run. Then, if it is not in fact true – an assertion failure – the program considers itself to be broken and typically deliberately crashes or throws an assertion failure exception.
И по твоей же ссылке указано, что это далеко не единственное предназанчение ассертов. Вобщем, даже с такой ссылкой ты всё равно отказываешься узнать, а что же за зверь такой, эти ассерты.
Например, где то в дебрях БЛ мы помечаем Deprecate.assert(condition, message) — на тот случай, если код таки будет вызван из старого апи. В этом случае варнинг появится не просто при вызове старого апи, а только если это старое апи тригерит кое какую функциональность.
P>>Да тебе похоже ясно только как емейлы слать, которые не то читают, не то нет
·>Не только емейлы, а только не хедеры. Перечитай что ещё обсуждалось, если с памятью проблемы.
На счет твоего понимания емейлов есть сомнения, т.к ты не объяснил, куда именно ты будешь слать емейлы и какой предлагается флоу, end-2-end.
P>>"разработчики уже заняты чем то другим, а может и уволились"
·>И что? Кто полезет в код, чтобы разобраться что означает данный хедер и его значение? Тоже команда эксплуатации?!
А это и не надо делать. Хидер это старндартная капабилити в апи. Готовый клиент при наличии этого хидера сам залогирует всё, что необходимо.
гатевей тоже сможет сделать такое, и залогировать.
То есть, в код даже смотреть не надо, а сообщение оперативно получат именно те, кто ответственны за эксплуатацию конкретного сервиса на той стороне
P>>Т.е. все ложится на команду эксплуатации. Им что, следить за всеми анонсами всех сервисов? Эдак придется штат раз в десять раздуть.
·>За анонсами, ясен пень, следить надо. Примеров других анонсов, не относящихся к deprectated я уже приводил несколько.
Я слабо представляю, что бы команда эксплуатации следила за всеми такими анонсами. У них обычно дел по самые нидерланды.
P>>Не ясно, что конкретно ты предлагаешь, какой флоу и что делать, если емейл опоздал, затерялся, итд
·>Емейл — это сообщение. Попробуй поизучать вопросы как организовывать надёжную коммуникацию в системах обмена сообщениями.
Ты никак не можешь рассказать про весь цикл коммуникации, ограничиваешься общими утверждениями. Какой в этом смысл?
У нас простая задача — у нас случилось нечто, и надо оперативно дать знать той самой команде на той стороне. И проблема в том, что на той стороне под конкретным client/product id может сидеть сколько угодно сервисов/продуктов/команд и тд.
·>В том то и дело, что хедеры работают только если
·>1 если их читают все кому нужно
автоматизируется
·>2 вовремя
автоматизируется
·>3 и после чтения хедера точно известны последствия конкретно в твоем продукте
сообщение получат именно те люди, которые в курсе таких дел.
P>>Если п1 еще можно как то гарантировать, то 2 случается не так уж часто, а 3 это вообще какая то магия.
·>А с хедерами п1 даже невозможно гарантировать.
Наоборот.
·>Мы анализируем свои логи и видим какие к нам приходят запросы. Если мы хотим что-то поменять в логике обработки этих запросов, мы исследуем импакт для всех вариаций реальных запросов.
А степень последствий для вызывающего кода какие? Останов сервиса, убытки, итд, вот это как вы анализируете?P>>Каким образом анализируя ваши логи/мониторинг вы узнаете, что у него случится denial of service ?
·>Я не понял сценарий. Расскажи детальнее, может с каким-нибудь внятным примером.
Элементарно — ошибка то на их стороне, которая приводит к dos. Раз ты в респонсе не сообщаешь нужной инфы, то выйти из dos они могут только в том случае, когда спустя слои переписок всё дойдет до конкретного L2, и тот перестартует сервис.
P>>Что фиксить? Проблема на вызывающей стороне, у них ожидания не соответствуют вашему апи. Начнешь перепиливать апи, что бы угодить всем?
·>твой хедер можно послать только на основе запроса. Если мы упустили какой-то precondition по структуре запроса и стали возвращать неожиданный результат, то это наша проблема, нам и фиксить.
Ну то есть, если тебя ктото продолжит называть по девичьей фамилии, ты заведешь второй паспорт, так что ли?
На нашей стороне все в порядке — небольшая функция в старом апи депрекейтнулась, и вызывается в дебрях БЛ. Заранее узнать, будет ли такой вызов, или нет, не представляется возможным.
P>>Технически — ничем. Главное, что бы ихний мониторинг сработал. Варнинг — это дополнительная фича АПИ, когда мы передаем информацию о качестве результата.
·>Нет. Мы выяснили, что главное, чтобы не мониторинг сработал (это лишь средство), а чтобы они предприняли некие действия и изменили их код (а вот это цель).
В том то и дело, что выяснить ответсвенное лицо бывает крайне сложно, например, потому что client-id, product-id, api-key одни и те же на всех.
P>>Предлагаешь на миллион запросов создавать миллион тикетов в джыре? Или писать AI который будет фильтровать, тот ли это баг или не тот?
·>Так в этом и суть, что не надо посылать миллион. Надо послать ровно один. А вот хедеров посылается миллион.
В какой из 1000 команды ты создашь джыра тикет? С т.з. твоего сервиса это один клиент/консумер/итд. C их т.з. таких целая тыща.
P>>ну да, ты то без багов пишешь, я помню — у тебя баги на прод не попадают.
·>Да, попадают. И да, это эпик фейл.
Слава богу. А то в прошлый раз ты на полном серьезе утверждал, что такого у вас быть не может.
·>Верно. Но технические средства нужно выбирать адекватно. Выбирать между одним емейлом (джирой, етс) и хедером в миллионах респонзов — надо на основе технических параметров. А вы выбрали лишь потому что у вас так принято, а с емейлами справиться не смогли, из-за административных проблем.
Неверное предположение. Что бы справиться с емейлами, нужно наладить коммуникацию со всеми из консумеров, что намного сложнее чем с одним. И надо понавводить целую кучу требований, ограничения именно для той стороны, и добиться что бы они этому следовали. Без этого емейлы работать не будут.
P>>Единственное, что делает менеджмент, это принятие решений, как именно будет решаться та, или иная проблема. Скажет решать емейлами — будет решаться емейлами.
P>>Скажет, что чрез транспорт реквеста — будет решаться через хидеры.
·>Т.е. у вас менеджемент решает технические вопросы? Мде. Тогда ясно.
Менеджер принимает решение. Например, архитектор — это менеджерская позиция. А у вас что, архитектор это разновидность девелоперов?
P>>·>Технически емейл от хедера в данном отличается лишь протоколом, smtp vs http. У хедеров ровно те же административные проблемы.
P>>Не только. хедер лежит вместе с респонзом, request-id и прочими вещами, не надо никаких приседаний, что бы начать инвестигейт.
·>В емейл можно положить и это, и гораздо больше.
И как он дойдет до ответсвенного лица? Полагаю так — шлете CEO, он форвардит подчиненным, те — своим подчиненным, и так пока не дойдет до того самого L2.
P>>Проблема на их части продакшна, что очевидно. Вот и нужно максимально быстро сигнализировать именно на той части.
·>Т.е. благодаря хедеру вы принесли убытки своему клиенту. Молодцы, чё.
Наоборот.
P>>Вот-вот. Ты то хвастался, что impact analysis делаешь, а однако никаких средств у тебя на то нет
·>Читаешь невнимательно. На нашей стороне — есть.
А надо бы и на той стороне глянуть. Какой юзкейс БЛ завязан на конкретный реквест ты не в курсе, а это самое важное.
P>>Емейл как стандарт работает плохо — майлбоксы у ключевых людей как правило переполнены.
·>
Но хедеры они читают!!Хидеры читают технические средства, а дальше все проблемы видны на мониторинге. Ты или юродствуешь, или вообще не в курсе, про что пишешь.
P>>Джира получше, только создавать тикет надо не в твоей джире, а на той стороне, куда у тебя доступа нет
·>Это опять же административная проблема, и фиксится за минуту.
Ну расскажи, в какой джире надо создать тикет, и когда именно, если все запросы исходят будто бы от одного сервиса на той стороне, а на самом деле там сотни команд/продуктов/сервисов со своими трекерами.
Re[65]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, ·, Вы писали:
P>>Ты заменил их на емейлы, которые ненадежны по своей природе. То есть, надо ждать регулярных фейлов.
·>Я не заменил, а предложил использовать тот же коммуникационный механизм, который у тебя уже существует на 7-8 шагах. Емейл — это лишь наиболее частый случай.
Кому ты емейлы слать будешь? На той стороне вполне себе возможна ситуация что N консумеров-клиентов-подразделений и чуть не все пользуются одними и теми же идентификаторами client,product,и тд.
С чего ты взял, что у них там идеальный порядок?
Итого — кому емейл слать, в чью джиру репортать?
А вот через транспорт однозначно известно, что происходит — нажали кнопку "показать трейсы" и сразу нашли, что вон тот сервис принадлежит команде ххх. И на той стороне всё находится мгновенно, достаточно прикрутить мониторинг.
P>>·>Что же твой код делает? Монетку подбрасывает?
P>>Это уже не важно. Главное, что ассерты и тесты это немного разные классы задач, которые всего лишь пересекаются.
·>Важно для того чтобы "в логах появилась нужная мне инфа".
Абсолютно не важно. Ассертам без разницы, что делает вызывающий код, они вызываются всегда, в том их бенефит.
P>>Неверно. Речь о проблемах во входных данных. Ровно как с компилятором — подкидываешь ему код, а он кидает тебе результат + варнинги.
·>Это плохая аналогия. Ибо с компилятором нет административной проблемы, которую мы обсуждаем.
Ну ок.
Вот пришел тебе в логах x-сaller: client=client-v-1245;product=2455a29;api-key=xxx-yyy-zzz + x-request-id:234234523k4j5kjh534 + x-forwarded тоже залогирован
Предложи надежное решение, что бы оперативно сообщить той самой команде о проблеме, желательно минуя человечечский фактор.
Разумеется, порядка на той стороне ждать не нужно — у тебя из той сети/подсети идут запросы миллионами, и id клиента/продукта просто копипастили, ибо "а так работает", api-key выдан один раз на всю контору, ибо так чудовищно дешевле.
P>>Не стоит валять дурака — здесь была речь о том, что ты не в курсе ассертов. И я показал как это искать ассертами.
·>Я не просил рассказывать ничего про ассерты. И в чём я в курсе или нет, ты не знаешь. Разговор идёт про хедер.
Ты спросил — откуда возьмется варнинг. Я тебе сказал — из ассертов. Потом ты начал валять дурака и делать вид, что не в курсе ассертов. Хотя, может ты и не валял ничего, а просто не в курсе ассертов — сколько мы с тобой ни говорим, у тебя с ассертами какие то сложности.
·>Хм, интересное определение. а если if + LOG.info или if + LOG.trace — это тоже ассерт?
Тоже. Ассерт это шорткат для таких вещей. Ассертами это делается как вариант вот так
И разумеется всё это можно включать-выключать.
>А вот такой код: if(condition){LOG.info("X"); doX();} else {LOG.warn("Y"); doY();}? Это лог или уже ассерт?!
Это условный вызов doX и doY + логирование.
P>>Ассерты при правильном применении детектят определенные классы проблем, которые не обнаруживаются тестами.
·>Круто, конечно. Но я тебя спрашивал о хедере.
Ты спрашивал в т.ч. откуда появится соответствующее сообщение в хидере.
·>Это не мой кругозор, а очередное твоё уникальное понимание терминологии. Вот общепринятое понятие:
·>
Какое незамутнённое враньё Глянем фрагмент чуть больше, тот самый, который ты старательно вырезал:
И по твоей же ссылке указано, что это далеко не единственное предназанчение ассертов. Вобщем, даже с такой ссылкой ты всё равно отказываешься узнать, а что же за зверь такой, эти ассерты.
Например, где то в дебрях БЛ мы помечаем Deprecate.assert(condition, message) — на тот случай, если код таки будет вызван из старого апи. В этом случае варнинг появится не просто при вызове старого апи, а только если это старое апи тригерит кое какую функциональность.
P>>Да тебе похоже ясно только как емейлы слать, которые не то читают, не то нет
·>Не только емейлы, а только не хедеры. Перечитай что ещё обсуждалось, если с памятью проблемы.
На счет твоего понимания емейлов есть сомнения, т.к ты не объяснил, куда именно ты будешь слать емейлы и какой предлагается флоу, end-2-end.
P>>"разработчики уже заняты чем то другим, а может и уволились"
·>И что? Кто полезет в код, чтобы разобраться что означает данный хедер и его значение? Тоже команда эксплуатации?!
А это и не надо делать. Хидер это старндартная капабилити в апи. Готовый клиент при наличии этого хидера сам залогирует всё, что необходимо.
гатевей тоже сможет сделать такое, и залогировать.
То есть, в код даже смотреть не надо, а сообщение оперативно получат именно те, кто ответственны за эксплуатацию конкретного сервиса на той стороне
P>>Т.е. все ложится на команду эксплуатации. Им что, следить за всеми анонсами всех сервисов? Эдак придется штат раз в десять раздуть.
·>За анонсами, ясен пень, следить надо. Примеров других анонсов, не относящихся к deprectated я уже приводил несколько.
Я слабо представляю, что бы команда эксплуатации следила за всеми такими анонсами. У них обычно дел по самые нидерланды.
P>>Не ясно, что конкретно ты предлагаешь, какой флоу и что делать, если емейл опоздал, затерялся, итд
·>Емейл — это сообщение. Попробуй поизучать вопросы как организовывать надёжную коммуникацию в системах обмена сообщениями.
Ты никак не можешь рассказать про весь цикл коммуникации, ограничиваешься общими утверждениями. Какой в этом смысл?
У нас простая задача — у нас случилось нечто, и надо оперативно дать знать той самой команде на той стороне. И проблема в том, что на той стороне под конкретным client/product id может сидеть сколько угодно сервисов/продуктов/команд и тд.
·>В том то и дело, что хедеры работают только если
·>1 если их читают все кому нужно
автоматизируется
·>2 вовремя
автоматизируется
·>3 и после чтения хедера точно известны последствия конкретно в твоем продукте
сообщение получат именно те люди, которые в курсе таких дел.
P>>Если п1 еще можно как то гарантировать, то 2 случается не так уж часто, а 3 это вообще какая то магия.
·>А с хедерами п1 даже невозможно гарантировать.
Наоборот.
·>Мы анализируем свои логи и видим какие к нам приходят запросы. Если мы хотим что-то поменять в логике обработки этих запросов, мы исследуем импакт для всех вариаций реальных запросов.
А степень последствий для вызывающего кода какие? Останов сервиса, убытки, итд, вот это как вы анализируете?
P>>Каким образом анализируя ваши логи/мониторинг вы узнаете, что у него случится denial of service ?
·>Я не понял сценарий. Расскажи детальнее, может с каким-нибудь внятным примером.
Элементарно — ошибка то на их стороне, которая приводит к dos. Раз ты в респонсе не сообщаешь нужной инфы, то выйти из dos они могут только в том случае, когда спустя слои переписок всё дойдет до конкретного L2, и тот перестартует сервис.
P>>Что фиксить? Проблема на вызывающей стороне, у них ожидания не соответствуют вашему апи. Начнешь перепиливать апи, что бы угодить всем?
·>твой хедер можно послать только на основе запроса. Если мы упустили какой-то precondition по структуре запроса и стали возвращать неожиданный результат, то это наша проблема, нам и фиксить.
Ну то есть, если тебя ктото продолжит называть по девичьей фамилии, ты заведешь второй паспорт, так что ли?
На нашей стороне все в порядке — небольшая функция в старом апи депрекейтнулась, и вызывается в дебрях БЛ. Заранее узнать, будет ли такой вызов, или нет, не представляется возможным.
P>>Технически — ничем. Главное, что бы ихний мониторинг сработал. Варнинг — это дополнительная фича АПИ, когда мы передаем информацию о качестве результата.
·>Нет. Мы выяснили, что главное, чтобы не мониторинг сработал (это лишь средство), а чтобы они предприняли некие действия и изменили их код (а вот это цель).
В том то и дело, что выяснить ответсвенное лицо бывает крайне сложно, например, потому что client-id, product-id, api-key одни и те же на всех.
P>>Предлагаешь на миллион запросов создавать миллион тикетов в джыре? Или писать AI который будет фильтровать, тот ли это баг или не тот?
·>Так в этом и суть, что не надо посылать миллион. Надо послать ровно один. А вот хедеров посылается миллион.
В какой из 1000 команды ты создашь джыра тикет? С т.з. твоего сервиса это один клиент/консумер/итд. C их т.з. таких целая тыща.
P>>ну да, ты то без багов пишешь, я помню — у тебя баги на прод не попадают.
·>Да, попадают. И да, это эпик фейл.
Слава богу. А то в прошлый раз ты на полном серьезе утверждал, что такого у вас быть не может.
·>Верно. Но технические средства нужно выбирать адекватно. Выбирать между одним емейлом (джирой, етс) и хедером в миллионах респонзов — надо на основе технических параметров. А вы выбрали лишь потому что у вас так принято, а с емейлами справиться не смогли, из-за административных проблем.
Неверное предположение. Что бы справиться с емейлами, нужно наладить коммуникацию со всеми из консумеров, что намного сложнее чем с одним. И надо понавводить целую кучу требований, ограничения именно для той стороны, и добиться что бы они этому следовали. Без этого емейлы работать не будут.
P>>Единственное, что делает менеджмент, это принятие решений, как именно будет решаться та, или иная проблема. Скажет решать емейлами — будет решаться емейлами.
P>>Скажет, что чрез транспорт реквеста — будет решаться через хидеры.
·>Т.е. у вас менеджемент решает технические вопросы? Мде. Тогда ясно.
Менеджер принимает решение. Например, архитектор — это менеджерская позиция. А у вас что, архитектор это разновидность девелоперов?
P>>·>Технически емейл от хедера в данном отличается лишь протоколом, smtp vs http. У хедеров ровно те же административные проблемы.
P>>Не только. хедер лежит вместе с респонзом, request-id и прочими вещами, не надо никаких приседаний, что бы начать инвестигейт.
·>В емейл можно положить и это, и гораздо больше.
И как он дойдет до ответсвенного лица? Полагаю так — шлете CEO, он форвардит подчиненным, те — своим подчиненным, и так пока не дойдет до того самого L2.
P>>Проблема на их части продакшна, что очевидно. Вот и нужно максимально быстро сигнализировать именно на той части.
·>Т.е. благодаря хедеру вы принесли убытки своему клиенту. Молодцы, чё.
Наоборот.
P>>Вот-вот. Ты то хвастался, что impact analysis делаешь, а однако никаких средств у тебя на то нет
·>Читаешь невнимательно. На нашей стороне — есть.
А надо бы и на той стороне глянуть. Какой юзкейс БЛ завязан на конкретный реквест ты не в курсе, а это самое важное.
P>>Емейл как стандарт работает плохо — майлбоксы у ключевых людей как правило переполнены.
·> Но хедеры они читают!!
Хидеры читают технические средства, а дальше все проблемы видны на мониторинге. Ты или юродствуешь, или вообще не в курсе, про что пишешь.
P>>Джира получше, только создавать тикет надо не в твоей джире, а на той стороне, куда у тебя доступа нет
·>Это опять же административная проблема, и фиксится за минуту.
Ну расскажи, в какой джире надо создать тикет, и когда именно, если все запросы исходят будто бы от одного сервиса на той стороне, а на самом деле там сотни команд/продуктов/сервисов со своими трекерами.
P>>Ты заменил их на емейлы, которые ненадежны по своей природе. То есть, надо ждать регулярных фейлов.
·>Я не заменил, а предложил использовать тот же коммуникационный механизм, который у тебя уже существует на 7-8 шагах. Емейл — это лишь наиболее частый случай.
Кому ты емейлы слать будешь? На той стороне вполне себе возможна ситуация что N консумеров-клиентов-подразделений и чуть не все пользуются одними и теми же идентификаторами client,product,и тд.
С чего ты взял, что у них там идеальный порядок?
Итого — кому емейл слать, в чью джиру репортать?
А вот через транспорт однозначно известно, что происходит — нажали кнопку "показать трейсы" и сразу нашли, что вон тот сервис принадлежит команде ххх. И на той стороне всё находится мгновенно, достаточно прикрутить мониторинг.
P>>·>Что же твой код делает? Монетку подбрасывает?
P>>Это уже не важно. Главное, что ассерты и тесты это немного разные классы задач, которые всего лишь пересекаются.
·>Важно для того чтобы "в логах появилась нужная мне инфа".
Абсолютно не важно. Ассертам без разницы, что делает вызывающий код, они вызываются всегда, в том их бенефит.
P>>Неверно. Речь о проблемах во входных данных. Ровно как с компилятором — подкидываешь ему код, а он кидает тебе результат + варнинги.
·>Это плохая аналогия. Ибо с компилятором нет административной проблемы, которую мы обсуждаем.
Ну ок.
Вот пришел тебе в логах x-сaller: client=client-v-1245;product=2455a29;api-key=xxx-yyy-zzz + x-request-id:234234523k4j5kjh534 + x-forwarded тоже залогирован
Предложи надежное решение, что бы оперативно сообщить той самой команде о проблеме, желательно минуя человечечский фактор.
Разумеется, порядка на той стороне ждать не нужно — у тебя из той сети/подсети идут запросы миллионами, и id клиента/продукта просто копипастили, ибо "а так работает", api-key выдан один раз на всю контору, ибо так чудовищно дешевле.
P>>Не стоит валять дурака — здесь была речь о том, что ты не в курсе ассертов. И я показал как это искать ассертами.
·>Я не просил рассказывать ничего про ассерты. И в чём я в курсе или нет, ты не знаешь. Разговор идёт про хедер.
Ты спросил — откуда возьмется варнинг. Я тебе сказал — из ассертов. Потом ты начал валять дурака и делать вид, что не в курсе ассертов. Хотя, может ты и не валял ничего, а просто не в курсе ассертов — сколько мы с тобой ни говорим, у тебя с ассертами какие то сложности.
·>Хм, интересное определение. а если if + LOG.info или if + LOG.trace — это тоже ассерт?
Тоже. Ассерт это шорткат для таких вещей. Ассертами это делается как вариант вот так
Trace.assert(condition, message)
Info.assert(condition, message)
Warning.assert(condition, message)
Error.assert(condition, message)И разумеется всё это можно включать-выключать.
>А вот такой код: if(condition){LOG.info("X"); doX();} else {LOG.warn("Y"); doY();}? Это лог или уже ассерт?!
Это условный вызов doX и doY + логирование.
P>>Ассерты при правильном применении детектят определенные классы проблем, которые не обнаруживаются тестами.
·>Круто, конечно. Но я тебя спрашивал о хедере.
Ты спрашивал в т.ч. откуда появится соответствующее сообщение в хидере.
·>Это не мой кругозор, а очередное твоё уникальное понимание терминологии. Вот общепринятое понятие:
·>
an assertion failure – the program considers itself to be broken and typically deliberately crashes or throws an assertion failure exception.
Какое незамутнённое враньё
Глянем фрагмент чуть больше, тот самый, который ты старательно вырезал:То есть — если предназначение ассерта это детект собственных ошибок, то надо крешит или бросать исключение.Assertions can help a programmer read the code, help a compiler compile it , or help the program detect its own defects.
For the latter, some programs check assertions by actually evaluating the predicate as they run. Then, if it is not in fact true – an assertion failure – the program considers itself to be broken and typically deliberately crashes or throws an assertion failure exception.
И по твоей же ссылке указано, что это далеко не единственное предназанчение ассертов. Вобщем, даже с такой ссылкой ты всё равно отказываешься узнать, а что же за зверь такой, эти ассерты.
Например, где то в дебрях БЛ мы помечаем Deprecate.assert(condition, message) — на тот случай, если код таки будет вызван из старого апи. В этом случае варнинг появится не просто при вызове старого апи, а только если это старое апи тригерит кое какую функциональность.
P>>Да тебе похоже ясно только как емейлы слать, которые не то читают, не то нет
·>Не только емейлы, а только не хедеры. Перечитай что ещё обсуждалось, если с памятью проблемы.
На счет твоего понимания емейлов есть сомнения, т.к ты не объяснил, куда именно ты будешь слать емейлы и какой предлагается флоу, end-2-end.
P>>"разработчики уже заняты чем то другим, а может и уволились"
·>И что? Кто полезет в код, чтобы разобраться что означает данный хедер и его значение? Тоже команда эксплуатации?!
А это и не надо делать. Хидер это старндартная капабилити в апи. Готовый клиент при наличии этого хидера сам залогирует всё, что необходимо.
гатевей тоже сможет сделать такое, и залогировать.
То есть, в код даже смотреть не надо, а сообщение оперативно получат именно те, кто ответственны за эксплуатацию конкретного сервиса на той стороне
P>>Т.е. все ложится на команду эксплуатации. Им что, следить за всеми анонсами всех сервисов? Эдак придется штат раз в десять раздуть.
·>За анонсами, ясен пень, следить надо. Примеров других анонсов, не относящихся к deprectated я уже приводил несколько.
Я слабо представляю, что бы команда эксплуатации следила за всеми такими анонсами. У них обычно дел по самые нидерланды.
P>>Не ясно, что конкретно ты предлагаешь, какой флоу и что делать, если емейл опоздал, затерялся, итд
·>Емейл — это сообщение. Попробуй поизучать вопросы как организовывать надёжную коммуникацию в системах обмена сообщениями.
Ты никак не можешь рассказать про весь цикл коммуникации, ограничиваешься общими утверждениями. Какой в этом смысл?
У нас простая задача — у нас случилось нечто, и надо оперативно дать знать той самой команде на той стороне. И проблема в том, что на той стороне под конкретным client/product id может сидеть сколько угодно сервисов/продуктов/команд и тд.
·>В том то и дело, что хедеры работают только если
·>1 если их читают все кому нужно
автоматизируется
·>2 вовремя
автоматизируется
·>3 и после чтения хедера точно известны последствия конкретно в твоем продукте
сообщение получат именно те люди, которые в курсе таких дел.
P>>Если п1 еще можно как то гарантировать, то 2 случается не так уж часто, а 3 это вообще какая то магия.
·>А с хедерами п1 даже невозможно гарантировать.
Наоборот.
·>Мы анализируем свои логи и видим какие к нам приходят запросы. Если мы хотим что-то поменять в логике обработки этих запросов, мы исследуем импакт для всех вариаций реальных запросов.
А степень последствий для вызывающего кода какие? Останов сервиса, убытки, итд, вот это как вы анализируете?P>>Каким образом анализируя ваши логи/мониторинг вы узнаете, что у него случится denial of service ?
·>Я не понял сценарий. Расскажи детальнее, может с каким-нибудь внятным примером.
Элементарно — ошибка то на их стороне, которая приводит к dos. Раз ты в респонсе не сообщаешь нужной инфы, то выйти из dos они могут только в том случае, когда спустя слои переписок всё дойдет до конкретного L2, и тот перестартует сервис.
P>>Что фиксить? Проблема на вызывающей стороне, у них ожидания не соответствуют вашему апи. Начнешь перепиливать апи, что бы угодить всем?
·>твой хедер можно послать только на основе запроса. Если мы упустили какой-то precondition по структуре запроса и стали возвращать неожиданный результат, то это наша проблема, нам и фиксить.
Ну то есть, если тебя ктото продолжит называть по девичьей фамилии, ты заведешь второй паспорт, так что ли?
На нашей стороне все в порядке — небольшая функция в старом апи депрекейтнулась, и вызывается в дебрях БЛ. Заранее узнать, будет ли такой вызов, или нет, не представляется возможным.
P>>Технически — ничем. Главное, что бы ихний мониторинг сработал. Варнинг — это дополнительная фича АПИ, когда мы передаем информацию о качестве результата.
·>Нет. Мы выяснили, что главное, чтобы не мониторинг сработал (это лишь средство), а чтобы они предприняли некие действия и изменили их код (а вот это цель).
В том то и дело, что выяснить ответсвенное лицо бывает крайне сложно, например, потому что client-id, product-id, api-key одни и те же на всех.
P>>Предлагаешь на миллион запросов создавать миллион тикетов в джыре? Или писать AI который будет фильтровать, тот ли это баг или не тот?
·>Так в этом и суть, что не надо посылать миллион. Надо послать ровно один. А вот хедеров посылается миллион.
В какой из 1000 команды ты создашь джыра тикет? С т.з. твоего сервиса это один клиент/консумер/итд. C их т.з. таких целая тыща.
P>>ну да, ты то без багов пишешь, я помню — у тебя баги на прод не попадают.
·>Да, попадают. И да, это эпик фейл.
Слава богу. А то в прошлый раз ты на полном серьезе утверждал, что такого у вас быть не может.
·>Верно. Но технические средства нужно выбирать адекватно. Выбирать между одним емейлом (джирой, етс) и хедером в миллионах респонзов — надо на основе технических параметров. А вы выбрали лишь потому что у вас так принято, а с емейлами справиться не смогли, из-за административных проблем.
Неверное предположение. Что бы справиться с емейлами, нужно наладить коммуникацию со всеми из консумеров, что намного сложнее чем с одним. И надо понавводить целую кучу требований, ограничения именно для той стороны, и добиться что бы они этому следовали. Без этого емейлы работать не будут.
P>>Единственное, что делает менеджмент, это принятие решений, как именно будет решаться та, или иная проблема. Скажет решать емейлами — будет решаться емейлами.
P>>Скажет, что чрез транспорт реквеста — будет решаться через хидеры.
·>Т.е. у вас менеджемент решает технические вопросы? Мде. Тогда ясно.
Менеджер принимает решение. Например, архитектор — это менеджерская позиция. А у вас что, архитектор это разновидность девелоперов?
P>>·>Технически емейл от хедера в данном отличается лишь протоколом, smtp vs http. У хедеров ровно те же административные проблемы.
P>>Не только. хедер лежит вместе с респонзом, request-id и прочими вещами, не надо никаких приседаний, что бы начать инвестигейт.
·>В емейл можно положить и это, и гораздо больше.
И как он дойдет до ответсвенного лица? Полагаю так — шлете CEO, он форвардит подчиненным, те — своим подчиненным, и так пока не дойдет до того самого L2.
P>>Проблема на их части продакшна, что очевидно. Вот и нужно максимально быстро сигнализировать именно на той части.
·>Т.е. благодаря хедеру вы принесли убытки своему клиенту. Молодцы, чё.
Наоборот.
P>>Вот-вот. Ты то хвастался, что impact analysis делаешь, а однако никаких средств у тебя на то нет
·>Читаешь невнимательно. На нашей стороне — есть.
А надо бы и на той стороне глянуть. Какой юзкейс БЛ завязан на конкретный реквест ты не в курсе, а это самое важное.
P>>Емейл как стандарт работает плохо — майлбоксы у ключевых людей как правило переполнены.
·>
Но хедеры они читают!!Хидеры читают технические средства, а дальше все проблемы видны на мониторинге. Ты или юродствуешь, или вообще не в курсе, про что пишешь.
P>>Джира получше, только создавать тикет надо не в твоей джире, а на той стороне, куда у тебя доступа нет
·>Это опять же административная проблема, и фиксится за минуту.
Ну расскажи, в какой джире надо создать тикет, и когда именно, если все запросы исходят будто бы от одного сервиса на той стороне, а на самом деле там сотни команд/продуктов/сервисов со своими трекерами.