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

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

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

P> в логах появилась нужная мне инфа в тех случаях, которые недоступны в тестах.
Вот именно. Если ты плохо понимаешь поведение твоего кода, то добавляешь _логи_, чтобы их потом анализировать и изучать поведение _твоего_ кода. И это твоя проблема и забота. Зачем это передавать куда-то по хедерам наружу?

P>>>Теоретически. А вот практически этот вариант не всегда реализуем, т.к. всегда будут какие нибудь варнинги.
P>·>Почему-то у большинства нет такой практики... ибо плохая практика. Я вот не сталкивался с публичными API от каких-нибудь известных контор типа FAANG. А ты?
P>А что, все сводится к фаанг?
Ну не фаанг. Давай ссылку на любую уважаемую тобой известную контору с таким API.

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

P>ты в очередной раз увиливаешь. assert это про варнинги, в т.ч. Сработал ассерт — можно/нужно рендерить варнинг.
if(!precondition) LOGGER.warn("Hm... Please check that!!"); это ассерт или лог?

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

>> С random, конечно, проблем не припомню, но всякие race conditions, эффекты асинхронности, зависимость от текущего времени, переход летнее-зимнее время — ловили. Никаких warning хедеров ясен пень. assert не проходит — это фатальное исключение и падение теста.
P>Ассерт это далеко не всегда фатальное исключение. Иногда это просто странный кейс.
По крайней мере в c++/java/c#/python — всегда. Даже не припомню где это не так.

P>·>Более того, хедер может работать в принципе только в одном частном случае, когда на один запрос ожидается ровно один ответ, что, впрочем, типично для REST. Как только появляется какой-нибудь stream, websocket или типа того, то это вообще никуда не годится. А иметь два разных механизма — это полный бардак.
P>Это вариант нормы, на самом деле. Если уж у нас могут быть разные протоколы, то имеет смысл выделить варнинг в поле
Нет, не имеет.

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

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

P>а команда эксплуатации не имеет глубоких знаний по внутренностям продукта.
Ага. Увидела команда эксплуатации "X-Warning: unexpected input" хедер и так всё сразу ясно стало.

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

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

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

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

P>·>А хедер у вас лично CEO читает в реальном времени, и тут же указания раздаёт. Так что-ли?
P>Ты адекватен? Я же тебе сказал, что это на раз прикручивается к мониторингу. Ты уже ударился в юродствование. Какой в этом смысл?
Непонятно в чём заслуга хедеров-то? Чем с технической т.з. мониторинг хедеров отличается от мониторинга логов или даже емейлов?

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

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

P>>>Ты усиленно игнорируешь всё, что я пишу про емейлы. Какой в этом смысл?
P>·>Ты проецируешь ваш бардак с коммуникационными каналами на всех. Я просто пытаюсь донести мысль, что ваша проблема с емейлами — это ваша проблема. Легко решаемая.
P>В той или иной степени эта проблема есть у большинства корпораций. Она административной природы и решить её одномоментно не выйдет. А раз так, то все завязаные на емейлы методы будут регулярно давать сбой.
Да, об этом я и говорю. Проблема административная, и техническими средствами не решается. Хедер — техническое средство.

P>>>Ну вот был воркшоп, чтение емейлов перенесли на завтра. Упс. Что делать?
P>·>С таким же успехом перенесут и анализ хедеров. Что делать?
P>Мониторинг никогда никуда не переносится, за ним следят 24/7
А что мешает следить за емейлами 24/7? Более того, следить за системой мониторинга надо квалифицированных спецов сажать. А за аутлук можно хоть школьника посадить.

P>>>А почему ты решил, что коммуникация L2 и менеджеров идет по емейлам? Я вроде пишу почти что противоположное.
P>·>По хедерам что-ли идёт? Или к чему это всё возражение?
P>К тому, что ты игнорируешь проблемы емейлов. У тебя это магическая волшебная палочка.
ты игнорируешь проблемы хедеров. У тебя это магическая волшебная палочка.
Технически емейл от хедера в данном отличается лишь протоколом, smtp vs http. У хедеров ровно те же административные проблемы.
И емейл это не единственная альтернатива, я называл и другие.

P>>>При траблшутинге они заинтересованы решать всё быстро тк они несут убыток, и все вопросы решаются буквально голосом. Соответственно, мне не надо напоминать "а видели ли вы емейлы от нас полгода назад?"
P>·>Ужас. Если доходит до траблшутинга, то дело уже плохо.
P>Я помню — ты умеешь писать без багов, и все проблемы находишь тестами.
Да, ты — круче! Все проблемы находишь хедером.

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

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

P> У вас что, девелоперы имеют доступ к логам на проде?
Это уже L3. Обычно логи консьюмерам выдаст команда L2.

P>Девелопер имеет доступ к логам только через L2 в момент траблшутинга.
P>И постучится тебе не ваш L2, а тот, с клиентской стороны. А если им это не надо, то нет смысла приседать.
Клиенты стучатся к L1-L2. И если совсем всё плохо, то L2 стучится ко мне, если я на L3.

P>>>Тогда ихние L2 смогут разобраться самостоятельно, и будут эскалировать не абы куда, а именно тем людям кто в данный момент может лучше разрулить.
P>·>Т.е. они по хедерам смогут разобраться?! Скорее всего потребуют changelog или типа того, для описания сути изменений.
P>Разумеется. Раз уж подобный хидер это внутренний стандарт, то L2 точно в курсе дел. Вообще, в хидеры помещается много инфы именно для помощи L2.
Ты ловко жонглируешь условиями. Ты уж определись. То у тебя внутренний стандарт, то у тебя тысячи внешних консьюмеров.
Впрочем, опять не аргумент. Ничто не мешает емейл-рассылку или джиру или ещё чего сделать внутренним стандартом. В чём преимущество хедера-то?