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

P>>>Ты заменил их на емейлы, которые ненадежны по своей природе. То есть, надо ждать регулярных фейлов.
P>·>Я не заменил, а предложил использовать тот же коммуникационный механизм, который у тебя уже существует на 7-8 шагах. Емейл — это лишь наиболее частый случай.
P>Кому ты емейлы слать будешь? На той стороне вполне себе возможна ситуация что N консумеров-клиентов-подразделений и чуть не все пользуются одними и теми же идентификаторами client,product,и тд.
Тому кто живёт на шаге 7 или 8.

P>С чего ты взял, что у них там идеальный порядок?
Вот именно. Значит шаги 1-7 тоже могут быть сломаны.

P>А вот через транспорт однозначно известно, что происходит — нажали кнопку "показать трейсы" и сразу нашли, что вон тот сервис принадлежит команде ххх. И на той стороне всё находится мгновенно, достаточно прикрутить мониторинг.
Не понял что за трейсы. Как я понял, вы не имеете (ну по крайней мере не должны) иметь доступ к логам той стороны.


P>>>Неверно. Речь о проблемах во входных данных. Ровно как с компилятором — подкидываешь ему код, а он кидает тебе результат + варнинги.
P>·>Это плохая аналогия. Ибо с компилятором нет административной проблемы, которую мы обсуждаем.
P>Ну ок.
P>Вот пришел тебе в логах x-сaller: client=client-v-1245;product=2455a29;api-key=xxx-yyy-zzz + x-request-id:234234523k4j5kjh534 + x-forwarded тоже залогирован
P>Предложи надежное решение, что бы оперативно сообщить той самой команде о проблеме, желательно минуя человечечский фактор.
В шагах 1-7 полно человеческого фактора.

P>Разумеется, порядка на той стороне ждать не нужно — у тебя из той сети/подсети идут запросы миллионами, и id клиента/продукта просто копипастили, ибо "а так работает", api-key выдан один раз на всю контору, ибо так чудовищно дешевле.
Отправить на ту сторону request-id и пусть разбираются кому он принадлежит. Это не твоя проблема значит.

P>>>Не стоит валять дурака — здесь была речь о том, что ты не в курсе ассертов. И я показал как это искать ассертами.
P>·>Я не просил рассказывать ничего про ассерты. И в чём я в курсе или нет, ты не знаешь. Разговор идёт про хедер.
P>Ты спросил — откуда возьмется варнинг. Я тебе сказал — из ассертов. Потом ты начал валять дурака и делать вид, что не в курсе ассертов. Хотя, может ты и не валял ничего, а просто не в курсе ассертов — сколько мы с тобой ни говорим, у тебя с ассертами какие то сложности.
Иди выше по контексту. Ты спросил: как долго будешь искать, какая же комбинация "та самая"?. Я ответил, что именно та комбинация, которая у тебя выдаёт варнинг. Ты начал что-то про ассерты рассказывать, неясно зачем.

P>·>Хм, интересное определение. а если if + LOG.info или if + LOG.trace — это тоже ассерт?
P>Тоже. Ассерт это шорткат для таких вещей. Ассертами это делается как вариант вот так
P>И разумеется всё это можно включать-выключать.
Ок, пусть так. Совершенно неважно как вы это у себя в коде называете. Суть в том, что это просто некое логическое условие.

>>А вот такой код: if(condition){LOG.info("X"); doX();} else {LOG.warn("Y"); doY();}? Это лог или уже ассерт?!
P>Это условный вызов doX и doY + логирование.
Мда. Сложно как всё у вас.

P>>>Ассерты при правильном применении детектят определенные классы проблем, которые не обнаруживаются тестами.
P>·>Круто, конечно. Но я тебя спрашивал о хедере.
P>Ты спрашивал в т.ч. откуда появится соответствующее сообщение в хидере.
Ну вот ты и ответил на свой вопрос об искомой комбинации в тестах.

P>То есть — если предназначение ассерта это детект собственных ошибок, то надо крешит или бросать исключение.
P>И по твоей же ссылке указано, что это далеко не единственное предназанчение ассертов. Вобщем, даже с такой ссылкой ты всё равно отказываешься узнать, а что же за зверь такой, эти ассерты.
А там есть два других предназначения: help a programmer read the code (по сути коммент) и help a compiler compile it (это просто видимо плюсовый static_assert). Какое предназначение я так подло скрыл, по-твоему?

Главная идея в статье вики в том, что ассертами покрывается сам код, а не ошибки во входных данных. И если ассерты падают, то это значит, что требуется поиск баги в самом коде, а не у консьюмеров твоего кода.
Вот и совершенно неясно что было в голове у человека, который придумал что результаты ассертов можно отдавать наружу. Прям классикой пахнуло. on error resume next.
Уж лучше validation, input check, argument check, precondition, warning, complain, report, fault, defect и т.п. Но причём тут ассерты, вообще неясно.

P>Например, где то в дебрях БЛ мы помечаем Deprecate.assert(condition, message) — на тот случай, если код таки будет вызван из старого апи. В этом случае варнинг появится не просто при вызове старого апи, а только если это старое апи тригерит кое какую функциональность.
Это логгирование обыкновевнное. Поэтому да, ты прав, я не в курсе _таких_ ассертов. Да и вряд ли кто-то кроме вас в курсе.

P>>>Да тебе похоже ясно только как емейлы слать, которые не то читают, не то нет
P>·>Не только емейлы, а только не хедеры. Перечитай что ещё обсуждалось, если с памятью проблемы.
P>На счет твоего понимания емейлов есть сомнения, т.к ты не объяснил, куда именно ты будешь слать емейлы и какой предлагается флоу, end-2-end.
Туда кто занимается шагом 7 или 8.

P>>>"разработчики уже заняты чем то другим, а может и уволились"
P>·>И что? Кто полезет в код, чтобы разобраться что означает данный хедер и его значение? Тоже команда эксплуатации?!
P>А это и не надо делать. Хидер это старндартная капабилити в апи. Готовый клиент при наличии этого хидера сам залогирует всё, что необходимо.
P>гатевей тоже сможет сделать такое, и залогировать.
P>То есть, в код даже смотреть не надо, а сообщение оперативно получат именно те, кто ответственны за эксплуатацию конкретного сервиса на той стороне
Что конкретно залогирует? У тебя в примере было 'unexpected input'. Как по этому _точно_ узнать тот самый precondontion, который это залогировал?

P>>>Т.е. все ложится на команду эксплуатации. Им что, следить за всеми анонсами всех сервисов? Эдак придется штат раз в десять раздуть.
P>·>За анонсами, ясен пень, следить надо. Примеров других анонсов, не относящихся к deprectated я уже приводил несколько.
P>Я слабо представляю, что бы команда эксплуатации следила за всеми такими анонсами. У них обычно дел по самые нидерланды.
В такой системе как у вас — с весёлыми релизами, тестами в проде и ассертами-хедерами — не удивительно.

P>>>Не ясно, что конкретно ты предлагаешь, какой флоу и что делать, если емейл опоздал, затерялся, итд
P>·>Емейл — это сообщение. Попробуй поизучать вопросы как организовывать надёжную коммуникацию в системах обмена сообщениями.
P>Ты никак не можешь рассказать про весь цикл коммуникации, ограничиваешься общими утверждениями. Какой в этом смысл?
P>У нас простая задача — у нас случилось нечто, и надо оперативно дать знать той самой команде на той стороне. И проблема в том, что на той стороне под конкретным client/product id может сидеть сколько угодно сервисов/продуктов/команд и тд.
Твой подход был вроде такой, что они к вам приходят с проблемой, что у них что-то не работает. Тогда просто по их request-id вы можете поглядеть свои логи и указать какие проблемы были в их запросах и рассказать что и как им надо поменять. Т.е. отправлять хедеры бессмысленно; отправляли вы эти хедеры, отправляли, а у них всё равно проблемы в проде.
Мой подход создать таску (через емейл, джиру, whatever) для L2. Пусть они сами разбираются как найти нужную команду и дать им шанс их что-то там поменять до указанного срока, пока вы не зарелизили свои изменения.

P>·>В том то и дело, что хедеры работают только если
P>·>1 если их читают все кому нужно
P>автоматизируется
У всех тысяч консьюмеров? Не верю.

P>·>2 вовремя
P>автоматизируется
Как 7-8 шаг автоматизируется?

P>·>3 и после чтения хедера точно известны последствия конкретно в твоем продукте
P>сообщение получат именно те люди, которые в курсе таких дел.
Какое "сообщение"?

P>·>Мы анализируем свои логи и видим какие к нам приходят запросы. Если мы хотим что-то поменять в логике обработки этих запросов, мы исследуем импакт для всех вариаций реальных запросов.
P> А степень последствий для вызывающего кода какие? Останов сервиса, убытки, итд, вот это как вы анализируете?
Это не в зоне нашего контроля, и код мы это не видим и видеть не можем. Поэтому и придумали API и SLA.

P>>>Каким образом анализируя ваши логи/мониторинг вы узнаете, что у него случится denial of service ?
P>·>Я не понял сценарий. Расскажи детальнее, может с каким-нибудь внятным примером.
P>Элементарно — ошибка то на их стороне, которая приводит к dos. Раз ты в респонсе не сообщаешь нужной инфы, то выйти из dos они могут только в том случае, когда спустя слои переписок всё дойдет до конкретного L2, и тот перестартует сервис.
Не понял как отправка хедера может повлиять на их код. Мы в принципе не можем ни видеть, ни контролировать обработку респонзов.

P>>>Что фиксить? Проблема на вызывающей стороне, у них ожидания не соответствуют вашему апи. Начнешь перепиливать апи, что бы угодить всем?
P>·>твой хедер можно послать только на основе запроса. Если мы упустили какой-то precondition по структуре запроса и стали возвращать неожиданный результат, то это наша проблема, нам и фиксить.
P>Ну то есть, если тебя ктото продолжит называть по девичьей фамилии, ты заведешь второй паспорт, так что ли?
Чё?

P>На нашей стороне все в порядке — небольшая функция в старом апи депрекейтнулась, и вызывается в дебрях БЛ. Заранее узнать, будет ли такой вызов, или нет, не представляется возможным.
Ну уж если ЯП и код совсем гно, и понять при каких условиях вызывается какая-то функция ну никак невозможно по анализу кода... С тестами швах, что воспроизвести сценарий не получается... То можно просто добавить в функцию log.warning. Потом анализировать логи и выяснить какая комбинация параметров запроса.
Очень стойкое ощущение, что у вас всё очень плохо и вменяемого понимания что у вас происходит в коде у вас нет. Но вместо того, чтобы самим решать свои проблемы, вы шлёте их через хедер консьюмерам в надежде, что они за вас вашу работу сделают, ведь они же деньги теряют. А вы вот экономите.

P>>>Технически — ничем. Главное, что бы ихний мониторинг сработал. Варнинг — это дополнительная фича АПИ, когда мы передаем информацию о качестве результата.
P>·>Нет. Мы выяснили, что главное, чтобы не мониторинг сработал (это лишь средство), а чтобы они предприняли некие действия и изменили их код (а вот это цель).
P>В том то и дело, что выяснить ответсвенное лицо бывает крайне сложно, например, потому что client-id, product-id, api-key одни и те же на всех.
Ну бардак чё. Надо чинить.

P>>>Предлагаешь на миллион запросов создавать миллион тикетов в джыре? Или писать AI который будет фильтровать, тот ли это баг или не тот?
P>·>Так в этом и суть, что не надо посылать миллион. Надо послать ровно один. А вот хедеров посылается миллион.
P>В какой из 1000 команды ты создашь джыра тикет? С т.з. твоего сервиса это один клиент/консумер/итд. C их т.з. таких целая тыща.
Трейсить по request-id. Не бином ньютона. Студенты индусы с таким справляются.

P>>>ну да, ты то без багов пишешь, я помню — у тебя баги на прод не попадают.
P>·>Да, попадают. И да, это эпик фейл.
P>Слава богу. А то в прошлый раз ты на полном серьезе утверждал, что такого у вас быть не может.
Ты врёшь. Я заявлял, что у нас не бывает, что тесты работающие в препроде вдруг внезапно валятся в проде.

Видишь ли. Баги бывают разные. Те которые у нас доходят до прода основаны на незнании или на непонимании требований. Т.е. кодируем и тестируем мы одно, а когда выкатываем клиенту, они, оказывается, хотели чего-то другого. Ну или банальные баги с техническими проблемами, типа многопоточки, асинхронщины, переполнения, неверных алгоритмов и т.п. Мы не догадались сделать какой-то тест, проверить какой-то сценарий и что-то выкатили в прод. А потом оказалось, что именно этот _неизвестный заранее_ сценарий провалился и сработал не так, как нужно клиенту.

У тебя же совсем другая ситуация. Ты уже знаешь конкретный сценарий, раз ты добавил какие-то условия в код, чтобы что-то писалось в хедер. Т.е. это уже известая тебе конкретная комбинация из 2^10^10 возможных. Но вместо того, чтобы досконально изучить как именно ведёт себя вся система в этом сценарии, удостовериться, что всё работает end2end, подтвердить ожидания у клиентов, ты что-то пихаешь в хедер, чтобы потом к тебе прибежали с прод-проблемами, т.к. убытки несут. И это лишь потому, что ты не знаешь кому какой емейл послать. Просто халатность.

P>·>Верно. Но технические средства нужно выбирать адекватно. Выбирать между одним емейлом (джирой, етс) и хедером в миллионах респонзов — надо на основе технических параметров. А вы выбрали лишь потому что у вас так принято, а с емейлами справиться не смогли, из-за административных проблем.
P>Неверное предположение. Что бы справиться с емейлами, нужно наладить коммуникацию со всеми из консумеров, что намного сложнее чем с одним. И надо понавводить целую кучу требований, ограничения именно для той стороны, и добиться что бы они этому следовали. Без этого емейлы работать не будут.
Так хедеры у вас тоже не работают, т.к. у клиентов простой, деньги теряют.
Отличие в том, что емейлы можно заставить работать, а хедеры — невозможно.

P>>>Единственное, что делает менеджмент, это принятие решений, как именно будет решаться та, или иная проблема. Скажет решать емейлами — будет решаться емейлами.
P>>>Скажет, что чрез транспорт реквеста — будет решаться через хидеры.
P>·>Т.е. у вас менеджемент решает технические вопросы? Мде. Тогда ясно.
P>Менеджер принимает решение. Например, архитектор — это менеджерская позиция. А у вас что, архитектор это разновидность девелоперов?
Это разновидность software engineer. Врочем да, соглашусь, что и управленческие решения принимает.

P>>>Не только. хедер лежит вместе с респонзом, request-id и прочими вещами, не надо никаких приседаний, что бы начать инвестигейт.
P>·>В емейл можно положить и это, и гораздо больше.
P>И как он дойдет до ответсвенного лица? Полагаю так — шлете CEO, он форвардит подчиненным, те — своим подчиненным, и так пока не дойдет до того самого L2.
Шаг 7, шлём L2. Где в том списке CEO, я не видел.

P>>>Проблема на их части продакшна, что очевидно. Вот и нужно максимально быстро сигнализировать именно на той части.
P>·>Т.е. благодаря хедеру вы принесли убытки своему клиенту. Молодцы, чё.
P>Наоборот.
Что наоборот? Не молодцы?

P>>>Вот-вот. Ты то хвастался, что impact analysis делаешь, а однако никаких средств у тебя на то нет
P>·>Читаешь невнимательно. На нашей стороне — есть.
P>А надо бы и на той стороне глянуть. Какой юзкейс БЛ завязан на конкретный реквест ты не в курсе, а это самое важное.
Сам заявил, что к логам той стороны (какой из тысячи, кстати) доступа нет и быть не должно. Кода тоже нет обычно. Что глянуть-то ты предлагаешь? Можно лишь через L2 или через разработчиков на той стороне.

P>>>Емейл как стандарт работает плохо — майлбоксы у ключевых людей как правило переполнены.
P>·> Но хедеры они читают!!
P>Хидеры читают технические средства, а дальше все проблемы видны на мониторинге. Ты или юродствуешь, или вообще не в курсе, про что пишешь.
Ну видно на мониторинге, а толку-то, если никто не смотрит... Ключевые люди не отреагировали же, т.к. к вам с прода бегут.

P>>>Джира получше, только создавать тикет надо не в твоей джире, а на той стороне, куда у тебя доступа нет
P>·>Это опять же административная проблема, и фиксится за минуту.
P>Ну расскажи, в какой джире надо создать тикет, и когда именно, если все запросы исходят будто бы от одного сервиса на той стороне, а на самом деле там сотни команд/продуктов/сервисов со своими трекерами.
Если совсем всё плохо в организации, то в любой, для начала. А там уже выяснять кто за что отвечает по цепочке, передавая ответственность за решение проблемы.

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

P>>>Ты заменил их на емейлы, которые ненадежны по своей природе. То есть, надо ждать регулярных фейлов.
P>·>Я не заменил, а предложил использовать тот же коммуникационный механизм, который у тебя уже существует на 7-8 шагах. Емейл — это лишь наиболее частый случай.
P>Кому ты емейлы слать будешь? На той стороне вполне себе возможна ситуация что N консумеров-клиентов-подразделений и чуть не все пользуются одними и теми же идентификаторами client,product,и тд.
Тому кто живёт на шаге 7 или 8.

P>С чего ты взял, что у них там идеальный порядок?
Вот именно. Значит шаги 1-7 тоже могут быть сломаны.

P>А вот через транспорт однозначно известно, что происходит — нажали кнопку "показать трейсы" и сразу нашли, что вон тот сервис принадлежит команде ххх. И на той стороне всё находится мгновенно, достаточно прикрутить мониторинг.
Не понял что за трейсы. Как я понял, вы не имеете (ну по крайней мере не должны) иметь доступ к логам той стороны.


P>>>Неверно. Речь о проблемах во входных данных. Ровно как с компилятором — подкидываешь ему код, а он кидает тебе результат + варнинги.
P>·>Это плохая аналогия. Ибо с компилятором нет административной проблемы, которую мы обсуждаем.
P>Ну ок.
P>Вот пришел тебе в логах x-сaller: client=client-v-1245;product=2455a29;api-key=xxx-yyy-zzz + x-request-id:234234523k4j5kjh534 + x-forwarded тоже залогирован
P>Предложи надежное решение, что бы оперативно сообщить той самой команде о проблеме, желательно минуя человечечский фактор.
В шагах 1-7 полно человеческого фактора.

P>Разумеется, порядка на той стороне ждать не нужно — у тебя из той сети/подсети идут запросы миллионами, и id клиента/продукта просто копипастили, ибо "а так работает", api-key выдан один раз на всю контору, ибо так чудовищно дешевле.
Отправить на ту сторону request-id и пусть разбираются кому он принадлежит. Это не твоя проблема значит.

P>>>Не стоит валять дурака — здесь была речь о том, что ты не в курсе ассертов. И я показал как это искать ассертами.
P>·>Я не просил рассказывать ничего про ассерты. И в чём я в курсе или нет, ты не знаешь. Разговор идёт про хедер.
P>Ты спросил — откуда возьмется варнинг. Я тебе сказал — из ассертов. Потом ты начал валять дурака и делать вид, что не в курсе ассертов. Хотя, может ты и не валял ничего, а просто не в курсе ассертов — сколько мы с тобой ни говорим, у тебя с ассертами какие то сложности.
Иди выше по контексту. Ты спросил: как долго будешь искать, какая же комбинация "та самая"?. Я ответил, что именно та комбинация, которая у тебя выдаёт варнинг, т.е. комбинация уже найдена. Ты начал что-то про ассерты рассказывать, неясно зачем.

P>·>Хм, интересное определение. а если if + LOG.info или if + LOG.trace — это тоже ассерт?
P>Тоже. Ассерт это шорткат для таких вещей. Ассертами это делается как вариант вот так
P>И разумеется всё это можно включать-выключать.
Ок, пусть так. Совершенно неважно как вы это у себя в коде называете. Суть в том, что это просто некое логическое условие.

>>А вот такой код: if(condition){LOG.info("X"); doX();} else {LOG.warn("Y"); doY();}? Это лог или уже ассерт?!
P>Это условный вызов doX и doY + логирование.
Мда. Сложно как всё у вас.

P>>>Ассерты при правильном применении детектят определенные классы проблем, которые не обнаруживаются тестами.
P>·>Круто, конечно. Но я тебя спрашивал о хедере.
P>Ты спрашивал в т.ч. откуда появится соответствующее сообщение в хидере.
Ну вот ты и ответил на свой вопрос об искомой комбинации в тестах.

P>То есть — если предназначение ассерта это детект собственных ошибок, то надо крешит или бросать исключение.
P>И по твоей же ссылке указано, что это далеко не единственное предназанчение ассертов. Вобщем, даже с такой ссылкой ты всё равно отказываешься узнать, а что же за зверь такой, эти ассерты.
А там есть два других предназначения: help a programmer read the code (по сути коммент) и help a compiler compile it (это просто видимо плюсовый static_assert). Какое предназначение я так подло скрыл, по-твоему?

Главная идея в статье вики в том, что ассертами покрывается сам код, а не ошибки во входных данных. И если ассерты падают, то это значит, что требуется поиск баги в самом коде, а не у консьюмеров твоего кода.
Вот и совершенно неясно что было в голове у человека, который придумал что результаты ассертов можно отдавать наружу. Прям классикой пахнуло. on error resume next.
Уж лучше validation, input check, argument check, precondition, warning, complain, report, fault, defect и т.п. Но причём тут ассерты, вообще неясно.

P>Например, где то в дебрях БЛ мы помечаем Deprecate.assert(condition, message) — на тот случай, если код таки будет вызван из старого апи. В этом случае варнинг появится не просто при вызове старого апи, а только если это старое апи тригерит кое какую функциональность.
Это логгирование обыкновевнное. Поэтому да, ты прав, я не в курсе _таких_ ассертов. Да и вряд ли кто-то кроме вас в курсе.

P>>>Да тебе похоже ясно только как емейлы слать, которые не то читают, не то нет
P>·>Не только емейлы, а только не хедеры. Перечитай что ещё обсуждалось, если с памятью проблемы.
P>На счет твоего понимания емейлов есть сомнения, т.к ты не объяснил, куда именно ты будешь слать емейлы и какой предлагается флоу, end-2-end.
Туда кто занимается шагом 7 или 8.

P>>>"разработчики уже заняты чем то другим, а может и уволились"
P>·>И что? Кто полезет в код, чтобы разобраться что означает данный хедер и его значение? Тоже команда эксплуатации?!
P>А это и не надо делать. Хидер это старндартная капабилити в апи. Готовый клиент при наличии этого хидера сам залогирует всё, что необходимо.
P>гатевей тоже сможет сделать такое, и залогировать.
P>То есть, в код даже смотреть не надо, а сообщение оперативно получат именно те, кто ответственны за эксплуатацию конкретного сервиса на той стороне
Что конкретно залогирует? У тебя в примере было 'unexpected input'. Как по этому _точно_ узнать тот самый precondontion, который это залогировал?

P>>>Т.е. все ложится на команду эксплуатации. Им что, следить за всеми анонсами всех сервисов? Эдак придется штат раз в десять раздуть.
P>·>За анонсами, ясен пень, следить надо. Примеров других анонсов, не относящихся к deprectated я уже приводил несколько.
P>Я слабо представляю, что бы команда эксплуатации следила за всеми такими анонсами. У них обычно дел по самые нидерланды.
В такой системе как у вас — с весёлыми релизами, тестами в проде и ассертами-хедерами — не удивительно.

P>>>Не ясно, что конкретно ты предлагаешь, какой флоу и что делать, если емейл опоздал, затерялся, итд
P>·>Емейл — это сообщение. Попробуй поизучать вопросы как организовывать надёжную коммуникацию в системах обмена сообщениями.
P>Ты никак не можешь рассказать про весь цикл коммуникации, ограничиваешься общими утверждениями. Какой в этом смысл?
P>У нас простая задача — у нас случилось нечто, и надо оперативно дать знать той самой команде на той стороне. И проблема в том, что на той стороне под конкретным client/product id может сидеть сколько угодно сервисов/продуктов/команд и тд.
Твой подход был вроде такой, что они к вам приходят с проблемой, что у них что-то не работает. Тогда просто по их request-id вы можете поглядеть свои логи и указать какие проблемы были в их запросах и рассказать что и как им надо поменять. Т.е. отправлять хедеры бессмысленно; отправляли вы эти хедеры, отправляли, а у них всё равно проблемы в проде.
Мой подход создать таску (через емейл, джиру, whatever) для L2. Пусть они сами разбираются как найти нужную команду и дать им шанс их что-то там поменять до указанного срока, пока вы не зарелизили свои изменения.

P>·>В том то и дело, что хедеры работают только если
P>·>1 если их читают все кому нужно
P>автоматизируется
У всех тысяч консьюмеров? Не верю.

P>·>2 вовремя
P>автоматизируется
Как 7-8 шаг автоматизируется?

P>·>3 и после чтения хедера точно известны последствия конкретно в твоем продукте
P>сообщение получат именно те люди, которые в курсе таких дел.
Какое "сообщение"?

P>·>Мы анализируем свои логи и видим какие к нам приходят запросы. Если мы хотим что-то поменять в логике обработки этих запросов, мы исследуем импакт для всех вариаций реальных запросов.
P> А степень последствий для вызывающего кода какие? Останов сервиса, убытки, итд, вот это как вы анализируете?
Это не в зоне нашего контроля, и код мы это не видим и видеть не можем. Поэтому и придумали API и SLA.

P>>>Каким образом анализируя ваши логи/мониторинг вы узнаете, что у него случится denial of service ?
P>·>Я не понял сценарий. Расскажи детальнее, может с каким-нибудь внятным примером.
P>Элементарно — ошибка то на их стороне, которая приводит к dos. Раз ты в респонсе не сообщаешь нужной инфы, то выйти из dos они могут только в том случае, когда спустя слои переписок всё дойдет до конкретного L2, и тот перестартует сервис.
Не понял как отправка хедера может повлиять на их код. Мы в принципе не можем ни видеть, ни контролировать обработку респонзов.

P>>>Что фиксить? Проблема на вызывающей стороне, у них ожидания не соответствуют вашему апи. Начнешь перепиливать апи, что бы угодить всем?
P>·>твой хедер можно послать только на основе запроса. Если мы упустили какой-то precondition по структуре запроса и стали возвращать неожиданный результат, то это наша проблема, нам и фиксить.
P>Ну то есть, если тебя ктото продолжит называть по девичьей фамилии, ты заведешь второй паспорт, так что ли?
Чё?

P>На нашей стороне все в порядке — небольшая функция в старом апи депрекейтнулась, и вызывается в дебрях БЛ. Заранее узнать, будет ли такой вызов, или нет, не представляется возможным.
Ну уж если ЯП и код совсем гно, и понять при каких условиях вызывается какая-то функция ну никак невозможно по анализу кода... С тестами швах, что воспроизвести сценарий не получается... То можно просто добавить в функцию log.warning. Потом анализировать логи и выяснить какая комбинация параметров запроса.
Очень стойкое ощущение, что у вас всё очень плохо и вменяемого понимания что у вас происходит в коде у вас нет. Но вместо того, чтобы самим решать свои проблемы, вы шлёте их через хедер консьюмерам в надежде, что они за вас вашу работу сделают, ведь они же деньги теряют. А вы вот экономите.

P>>>Технически — ничем. Главное, что бы ихний мониторинг сработал. Варнинг — это дополнительная фича АПИ, когда мы передаем информацию о качестве результата.
P>·>Нет. Мы выяснили, что главное, чтобы не мониторинг сработал (это лишь средство), а чтобы они предприняли некие действия и изменили их код (а вот это цель).
P>В том то и дело, что выяснить ответсвенное лицо бывает крайне сложно, например, потому что client-id, product-id, api-key одни и те же на всех.
Ну бардак чё. Надо чинить.

P>>>Предлагаешь на миллион запросов создавать миллион тикетов в джыре? Или писать AI который будет фильтровать, тот ли это баг или не тот?
P>·>Так в этом и суть, что не надо посылать миллион. Надо послать ровно один. А вот хедеров посылается миллион.
P>В какой из 1000 команды ты создашь джыра тикет? С т.з. твоего сервиса это один клиент/консумер/итд. C их т.з. таких целая тыща.
Трейсить по request-id. Не бином ньютона. Студенты индусы с таким справляются.

P>>>ну да, ты то без багов пишешь, я помню — у тебя баги на прод не попадают.
P>·>Да, попадают. И да, это эпик фейл.
P>Слава богу. А то в прошлый раз ты на полном серьезе утверждал, что такого у вас быть не может.
Ты врёшь. Я заявлял, что у нас не бывает, что тесты работающие в препроде вдруг внезапно валятся в проде.

Видишь ли. Баги бывают разные. Те которые у нас доходят до прода основаны на незнании или на непонимании требований. Т.е. кодируем и тестируем мы одно, а когда выкатываем клиенту, они, оказывается, хотели чего-то другого. Ну или банальные баги с техническими проблемами, типа многопоточки, асинхронщины, переполнения, неверных алгоритмов и т.п. Мы не догадались сделать какой-то тест, проверить какой-то сценарий и что-то выкатили в прод. А потом оказалось, что именно этот _неизвестный заранее_ сценарий провалился и сработал не так, как нужно клиенту.

У тебя же совсем другая ситуация. Ты уже знаешь конкретный сценарий, раз ты добавил какие-то условия в код, чтобы что-то писалось в хедер. Т.е. это уже известая тебе конкретная комбинация из 2^10^10 возможных. Но вместо того, чтобы досконально изучить как именно ведёт себя вся система в этом сценарии, удостовериться, что всё работает end2end, подтвердить ожидания у клиентов, ты что-то пихаешь в хедер, чтобы потом к тебе прибежали с прод-проблемами, т.к. убытки несут. И это лишь потому, что ты не знаешь кому какой емейл послать. Просто халатность.

P>·>Верно. Но технические средства нужно выбирать адекватно. Выбирать между одним емейлом (джирой, етс) и хедером в миллионах респонзов — надо на основе технических параметров. А вы выбрали лишь потому что у вас так принято, а с емейлами справиться не смогли, из-за административных проблем.
P>Неверное предположение. Что бы справиться с емейлами, нужно наладить коммуникацию со всеми из консумеров, что намного сложнее чем с одним. И надо понавводить целую кучу требований, ограничения именно для той стороны, и добиться что бы они этому следовали. Без этого емейлы работать не будут.
Так хедеры у вас тоже не работают, т.к. у клиентов простой, деньги теряют.
Отличие в том, что емейлы можно заставить работать, а хедеры — невозможно.

P>>>Единственное, что делает менеджмент, это принятие решений, как именно будет решаться та, или иная проблема. Скажет решать емейлами — будет решаться емейлами.
P>>>Скажет, что чрез транспорт реквеста — будет решаться через хидеры.
P>·>Т.е. у вас менеджемент решает технические вопросы? Мде. Тогда ясно.
P>Менеджер принимает решение. Например, архитектор — это менеджерская позиция. А у вас что, архитектор это разновидность девелоперов?
Это разновидность software engineer. Врочем да, соглашусь, что и управленческие решения принимает.

P>>>Не только. хедер лежит вместе с респонзом, request-id и прочими вещами, не надо никаких приседаний, что бы начать инвестигейт.
P>·>В емейл можно положить и это, и гораздо больше.
P>И как он дойдет до ответсвенного лица? Полагаю так — шлете CEO, он форвардит подчиненным, те — своим подчиненным, и так пока не дойдет до того самого L2.
Шаг 7, шлём L2. Где в том списке CEO, я не видел.

P>>>Проблема на их части продакшна, что очевидно. Вот и нужно максимально быстро сигнализировать именно на той части.
P>·>Т.е. благодаря хедеру вы принесли убытки своему клиенту. Молодцы, чё.
P>Наоборот.
Что наоборот? Не молодцы?

P>>>Вот-вот. Ты то хвастался, что impact analysis делаешь, а однако никаких средств у тебя на то нет
P>·>Читаешь невнимательно. На нашей стороне — есть.
P>А надо бы и на той стороне глянуть. Какой юзкейс БЛ завязан на конкретный реквест ты не в курсе, а это самое важное.
Сам заявил, что к логам той стороны (какой из тысячи, кстати) доступа нет и быть не должно. Кода тоже нет обычно. Что глянуть-то ты предлагаешь? Можно лишь через L2 или через разработчиков на той стороне.

P>>>Емейл как стандарт работает плохо — майлбоксы у ключевых людей как правило переполнены.
P>·> Но хедеры они читают!!
P>Хидеры читают технические средства, а дальше все проблемы видны на мониторинге. Ты или юродствуешь, или вообще не в курсе, про что пишешь.
Ну видно на мониторинге, а толку-то, если никто не смотрит... Ключевые люди не отреагировали же, т.к. к вам с прода бегут.

P>>>Джира получше, только создавать тикет надо не в твоей джире, а на той стороне, куда у тебя доступа нет
P>·>Это опять же административная проблема, и фиксится за минуту.
P>Ну расскажи, в какой джире надо создать тикет, и когда именно, если все запросы исходят будто бы от одного сервиса на той стороне, а на самом деле там сотни команд/продуктов/сервисов со своими трекерами.
Если совсем всё плохо в организации, то в любой, для начала. А там уже выяснять кто за что отвечает по цепочке, передавая ответственность за решение проблемы.