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

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

P>>>А я её и не знаю на момент добавления такого кода. В этом и цель — сделать так, что бы
P>·>Что же твой код делает? Монетку подбрасывает?
P>Это уже не важно. Главное, что ассерты и тесты это немного разные классы задач, которые всего лишь пересекаются.
Важно для того чтобы "в логах появилась нужная мне инфа".

P>>> в логах появилась нужная мне инфа в тех случаях, которые недоступны в тестах.
P>·>Вот именно. Если ты плохо понимаешь поведение твоего кода, то добавляешь _логи_, чтобы их потом анализировать и изучать поведение _твоего_ кода. И это твоя проблема и забота.
P>Неверно. Речь о проблемах во входных данных. Ровно как с компилятором — подкидываешь ему код, а он кидает тебе результат + варнинги.
Это плохая аналогия. Ибо с компилятором нет административной проблемы, которую мы обсуждаем. Ни мониторинга нет, ни логов, ни L2. И компилятор — это не API, а UI. С компилятором взаимодействует не Appllication, а человек.

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

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

P>>>ты в очередной раз увиливаешь. assert это про варнинги, в т.ч. Сработал ассерт — можно/нужно рендерить варнинг.
P>·>if(!precondition) LOGGER.warn("Hm... Please check that!!"); это ассерт или лог?
P>Ассерт это это if + log.
Хм, интересное определение. а если if + LOG.info или if + LOG.trace — это тоже ассерт? А вот такой код: if(condition){LOG.info("X"); doX();} else {LOG.warn("Y"); doY();}? Это лог или уже ассерт?!

P>>>И это не гарантирует нахождение ошибки, всего лишь повышает вероятность обнаружения.
P>·>А что _гарантирует_ нахождение ошибки? Неужели хедер?!
P>Ассерты при правильном применении детектят определенные классы проблем, которые не обнаруживаются тестами.
Круто, конечно. Но я тебя спрашивал о хедере.

P>>>Ассерт это далеко не всегда фатальное исключение. Иногда это просто странный кейс.
P>·>По крайней мере в c++/java/c#/python — всегда. Даже не припомню где это не так.
P>Ты извини, но это снова про твой кругозор.
Это не мой кругозор, а очередное твоё уникальное понимание терминологии. Вот общепринятое понятие:

an assertion failure – the program considers itself to be broken and typically deliberately crashes or throws an assertion failure exception.

P>·>Может быть "плохой" и совокупность нескольких запросов, и, даже, отсутствия неких нужных запросов. В какие хедеры пихать такие варнинги совсем неясно.
P>Да тебе похоже ясно только как емейлы слать, которые не то читают, не то нет
Не только емейлы, а только не хедеры. Перечитай что ещё обсуждалось, если с памятью проблемы.

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

P>Т.е. все ложится на команду эксплуатации. Им что, следить за всеми анонсами всех сервисов? Эдак придется штат раз в десять раздуть.
За анонсами, ясен пень, следить надо. Примеров других анонсов, не относящихся к deprectated я уже приводил несколько.

P>>>а команда эксплуатации не имеет глубоких знаний по внутренностям продукта.
P>·>Ага. Увидела команда эксплуатации "X-Warning: unexpected input" хедер и так всё сразу ясно стало.
P> Ну вот в компиляторе ты часто видишь подобные варнинги?
Я в компиляторе хедеров не видел вообще. А подобный варнинг основан на твоих словах, так что если он тебя чем-то не устраивает, копайся в своём мониторинге твоих слов. Да и maxkar приводил пример "W321, W123". Всё кристально ясно же, да?

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

P>>>Административные проблемы как были, так и остались. Зато хидер работает всегда, вне зависимости, читаешь ты емейлы или нет.
P>·>Емейлы тоже работают всегда, вне зависимости читаешь ты их или нет.
P>В том то и дело, что емейлы работают только если
P>1 если их читают все кому нужно
P>2 вовремя
P>3 и после чтения емейла точно известны последствия конкретно в твоем продукте
В том то и дело, что хедеры работают только если
1 если их читают все кому нужно
2 вовремя
3 и после чтения хедера точно известны последствия конкретно в твоем продукте

P>Если п1 еще можно как то гарантировать, то 2 случается не так уж часто, а 3 это вообще какая то магия.
А с хедерами п1 даже невозможно гарантировать.

P>>>Как ты узнаешь, что мелкое изменение на твоей стороне будет супер-критичным для 1й из 100 команд?
P>·>По нашим логам/мониторингу/етс. Это наша обязанность делать impact analysis.
P> Правильно понимаю, для этого вы анализируете код всех 100...1000 консумеров доступа к которому у вас нет?
Мы анализируем свои логи и видим какие к нам приходят запросы. Если мы хотим что-то поменять в логике обработки этих запросов, мы исследуем импакт для всех вариаций реальных запросов.

P>Ну вот консумер ждет единственную страницу, а вы ему кидаете только первую страницу. Раньше то была одна, но теперь вы взяли другой квери-процессор и результатов стало больше.
P>Каким образом анализируя ваши логи/мониторинг вы узнаете, что у него случится denial of service ?
Я не понял сценарий. Расскажи детальнее, может с каким-нибудь внятным примером.

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

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

P>·>Это закон природы такой что-ли? Можно разные адреса заводить, можно тикеты в джире. В конце концов мониторинг может технически и по smpt ходить и на дашборд варнинги выкидывать.
P>Предлагаешь на миллион запросов создавать миллион тикетов в джыре? Или писать AI который будет фильтровать, тот ли это баг или не тот?
Так в этом и суть, что не надо посылать миллион. Надо послать ровно один. А вот хедеров посылается миллион.

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

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

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

P>И вот у решения с хидерами есть куча преимуществ перед емейлом — а именно, человеческий фактор исключается почти полностью. Остаётся только кейс злонамеренного игнорирования.
Он не исключается. 7-8 шаги те же самые.

P>>>Мониторинг никогда никуда не переносится, за ним следят 24/7
P>·>А что мешает следить за емейлами 24/7? Более того, следить за системой мониторинга надо квалифицированных спецов сажать. А за аутлук можно хоть школьника посадить.
P>Я ж тебе пример привел — продуктовую команду разогнали, и остался только L2, который один на все сервисы. Ну прочитали они, что какой то компонент пофиксал баг в парсере адреса. Дальше что, как им понять, на какие из 100...1000 проектов на проде это повлияет?
Если они не понимают, что они релизят, то они должны отказать релизить.

P>·>Технически емейл от хедера в данном отличается лишь протоколом, smtp vs http. У хедеров ровно те же административные проблемы.
P>Не только. хедер лежит вместе с респонзом, request-id и прочими вещами, не надо никаких приседаний, что бы начать инвестигейт.
В емейл можно положить и это, и гораздо больше.

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

P>·>Я имею в виду логи на нашей стороне. К логам консьюмера часто доступа нет вообще, никакого. И как им что-то указать в их логах — я даже не представляю.
P>Вот-вот. Ты то хвастался, что impact analysis делаешь, а однако никаких средств у тебя на то нет
Читаешь невнимательно. На нашей стороне — есть.

>> Где они, в каком формате, кто имеет доступ? Да хз! Они вообще их могут сломать или потерять. А нам пофиг, у нас свои логи есть и мы им всё можем на блюдечке с каёмочкий показать и цветами нужные места разукрасить.
P>Твои логи никто не отменял, и changelog никто не отменял.
Я это и написал. Ты читать разучился?
Мне не надо отправлять никакие хедеры на ту сторону, чтобы иметь свои логи.

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

P>Джира получше, только создавать тикет надо не в твоей джире, а на той стороне, куда у тебя доступа нет
Это опять же административная проблема, и фиксится за минуту.