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

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

Ты альтернативу так и не показал, кроме "у нас есть рассылки" Рассылки сами все проблемы порешают?

P>>Могут, еще как. Это их основное предназначение. Сам же пишешь — выявить комбинацию прописаную в условии. Только не precondition, а postcondintion, и даже инвариант. И не сама комбинация прописывает, а её признаки. Условие ровно одно — свойства входа или результата.
·>Под precondition я имею в виду идентификатор из твоего кода: Warning.assert(precondontion, 'unexpected input'). Тебя опять куда-то унесло в оффтопик.

Ну вот. А где здесь та самая комбинация и как её узнать на момент тестирования?

P>>Например — контрольная сумма. Гыгы. Не сходится — с реквестом вероятно чтото не то. Логируем, выставляем варнинг и возвращаем респонс.
·>Такую херню надо просто реджектить без вопросов.

Теоретически. А вот практически этот вариант не всегда реализуем, т.к. всегда будут какие нибудь варнинги.

P>>В прекондишн прописано только условие. На этапе разработки ты эту комбинацию не знаешь.
·>Если ты эту комбинацию не знаешь, ты не сможешь написать Warning.assert(precondontion, 'unexpected input').

Минутка ликбеза:
Вот у нас есть код, сумма — это что бы условие задачи упростить, синтетический пример — говорю заранее, т.к. ты щас начнешь придираться к словам.

function sum(a, b) {
  // код этой функции для тебя не виден, включи воображение
  // то есть, тот самый чОрный ящик
  if(a == randomInt(1000000000)) return 100; // симулируем баг с нестабильным поведением
  if(b == randomInt(1000000000)) return 200; // симулируем баг с нестабильным поведением

  return a + b;     
}

assert выдаст в лог, что посткондишн не сходится, и напечает тебе и а, и b.
Например assert(() => a+b == result, a, b);

А теперь твой ход — покажи, как ты подобную багу будешь искать тестами.

·>Перечитай вопрос внимательно. Почему именно хедер? Например, пусть ваш мониторинг аггрится на ERROR в логах и шлёт емейлы кому положено, напрямую. Зачем эти промежуточные слои через rest, чужой мониторинг, чужой L2 и т.п.?

Еще раз — емейл это крайне перегруженый канал. Слишком велик шанс что письмо тупо пропустят или прочитают слишком поздно.

P>>Например, потому что это самый простой и дешевый способ разграничить ответственность. Вкомитал вызов согласно этому АПИ — теперь отвечай сам за корректность запросов.
·>Некорректные запросы надо просто реджектить. Давай другой пример.

Пример тебе не нравится — это уже твои проблемы.

P>>Ага, в ответ на "escalate" прибегает архитектор, и говорит "делай хидер с варнингом, мне так приказали сверху, теперь всё апи будет таким."
·>Т.е. у вас так принято, культ карго. Так бы сразу и сказал.

Рашение административных проблем как правило занимает много времени, бывает даже годы, пока выработается и стабилизируется конкретный процесс.
А решение нужно прямо сейчас.

P>>Ты так и не рассказал, как будет без хидера
·>Сказал. После 0го шага идёт сразу 8й.

Это детские отписки. Поскольку ты закладываешься на емейл, слишком велик шанс что прочитают с запозданием. И на этот случай у тебя решения как не было, так и нет.

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

Ты, похоже, не читаешь. Емейл слишком ненадежный канал. При условии, что люди относятся к обязанностям добросовестно, емейл не дает никаких гарантий — срочная работа на выезде, воркшоп, командировка, отпуск, итд итд. Упс — прочитали, но неделю спустя. Еще момент — человек просто устал и пропустил тот самый емейл.
А вот на звоночек в мониторинге реагируют очень быстро, и L2 суппорт в состоянии купировать большинство проблем.

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

Ты усиленно игнорируешь всё, что я пишу про емейлы. Какой в этом смысл?

·>Да тоже самое. Оптимум — после 0го шага сразу 8й. Ну или 7й, может быть. Шаги 1-6 не нужны вообще.

Ну вот был воркшоп, чтение емейлов перенесли на завтра. Упс. Что делать?

·>Если они могут обеспечить, что ихние менеджеры не игнорируют емейлы от L2, то они смогут обеспечить, чтобы ихние менеджеры не игнорировали емейлы от вас. А если нет, то и хедеры не помогут. Вывод — хедер — лишняя сущность.

А почему ты решил, что коммуникация L2 и менеджеров идет по емейлам? Я вроде пишу почти что противоположное.

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

При траблшутинге они заинтересованы решать всё быстро тк они несут убыток, и все вопросы решаются буквально голосом. Соответственно, мне не надо напоминать "а видели ли вы емейлы от нас полгода назад?"
Вместо этого "давайте глянем ваши логи... Видите — варнинг такой, следовательно, вам надо обновить вашу конфигурацию"
И дальше они справляются без меня. Моя цель в том и состоит, что бы предоставлять инструмент решения проблем, а не влазить в каждое из решений.
Искать, где чьи логи, это одна из проблем. Проще отфутболить тому, на чьей стороне косяк, пость он видит проблему в своих логах и своем мониторинге.
Тогда ихние L2 смогут разобраться самостоятельно, и будут эскалировать не абы куда, а именно тем людям кто в данный момент может лучше разрулить.

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

Тебе не нужно — ну не отправляй. Разве я тебя заставляю?

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

P>>>Тебе уже много раз рассказали.
P>·>Рассказано текущее положение дел у вас, а не обоснование чем такое решение лучше, чем альтернативы.
P>Ты альтернативу так и не показал, кроме "у нас есть рассылки" Рассылки сами все проблемы порешают?
Они решают проблемы как минимум не хуже, чем хедеры. А по некоторым параметрам — значительно лучше.

P>·>Под precondition я имею в виду идентификатор из твоего кода: Warning.assert(precondontion, 'unexpected input'). Тебя опять куда-то унесло в оффтопик.
P>Ну вот. А где здесь та самая комбинация и как её узнать на момент тестирования?
Как минимум — ровно тем же способом, которым ты её узнал во время добавления кода для твоего хедера.

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

P>А теперь твой ход — покажи, как ты подобную багу будешь искать тестами.
Причём тут тестирование? Мы вроде о warning headers говорим?

Впрочем отвечу, intermittent failures мы искали постоянным прогоном тестов в тестовых окружениях. С random, конечно, проблем не припомню, но всякие race conditions, эффекты асинхронности, зависимость от текущего времени, переход летнее-зимнее время — ловили. Никаких warning хедеров ясен пень. assert не проходит — это фатальное исключение и падение теста.

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

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

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

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

P>>>Ты так и не рассказал, как будет без хидера
P>·>Сказал. После 0го шага идёт сразу 8й.
P>Это детские отписки. Поскольку ты закладываешься на емейл, слишком велик шанс что прочитают с запозданием. И на этот случай у тебя решения как не было, так и нет.
Если проблема очень ограничена во времени, могу и в чат, и позвонить, и даже ногами дойти.
А хедер у вас лично CEO читает в реальном времени, и тут же указания раздаёт. Так что-ли?

P>>>Что бы они приняли действия на своей стороне по исправлению проблемы.
P>·>Как это их обязует принимать действия? Почему они не могут предпринять те же действия, например, при получении емейла от вас?
P>Ты, похоже, не читаешь. Емейл слишком ненадежный канал. При условии, что люди относятся к обязанностям добросовестно, емейл не дает никаких гарантий — срочная работа на выезде, воркшоп, командировка, отпуск, итд итд. Упс — прочитали, но неделю спустя. Еще момент — человек просто устал и пропустил тот самый емейл.
P>А вот на звоночек в мониторинге реагируют очень быстро, и L2 суппорт в состоянии купировать большинство проблем.
L2 у нас и на емейлы реагирует. Работа у них такая. Бизнес и клиенты о своих проблемах емейлы шлют, в хедеры они не умеют.

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

P>·>Да тоже самое. Оптимум — после 0го шага сразу 8й. Ну или 7й, может быть. Шаги 1-6 не нужны вообще.
P>Ну вот был воркшоп, чтение емейлов перенесли на завтра. Упс. Что делать?
С таким же успехом перенесут и анализ хедеров. Что делать?

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

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

P>Вместо этого "давайте глянем ваши логи... Видите — варнинг такой, следовательно, вам надо обновить вашу конфигурацию"
Т.е. ваши хедеры проблему не решили, а допустили до прода. А проблему, в итоге, решает не хедер, а голос. Полный фейл.

P>И дальше они справляются без меня. Моя цель в том и состоит, что бы предоставлять инструмент решения проблем, а не влазить в каждое из решений.
С таким же успехом можно показать что угодно, и логи, и старые емейлы, и вики, и changelogs и т.п., у кого бы они ни были.
И вообще, сложно себе представить, чтобы я должен был разбираться как мне кому-то показывать "ваши логи", и это у тысяч косьюмеров.

P>Искать, где чьи логи, это одна из проблем. Проще отфутболить тому, на чьей стороне косяк, пость он видит проблему в своих логах и своем мониторинге.
Мне проще быстро скопипастить свои логи, т.к. я знаю где что и как искать. Разбираться в чужих логах? Как? Да и доступа у меня может не быть, и никакого контроля.

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

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

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

·>Ты же как-то узнаёшь, что используется именно deprecated api...
В смысле "узнаю"? Ну да, я сам лично написал, что на моем сервере /api/v21 — deprecated. И если это API вызвали, оно используется.

·>Получается т.е. ты идентифицируешь deprecated клиентов по урлу или как-то иначе
Я вообще не идентифицирую клиентов. У меня даже понятия "deprecated клиент" нет. И я не знаю, чем и как клиент вызывает мой API — curl, ручной код, какая-то сгенерированная библиотека. Я идентифицирую deprecated API по той информации (данным запроса), которые посылаются всеми клиентами. Warning имеет семантику "Чувак, кто бы ты ни был! Пожалуйста, больше не делай так, как сделал сейчас. Это уже не модно. Пока что то, что ты сделал, работает. Но через какое-то время перестанет. И это будет твоя проблема!". Мне не нужно связывать запрос с чем-то еще для маршрутизации сообщений по альтернативному каналу. Использовал deprecated API — получил предупреждение прямо в заголовках ответа. Использовал modern API — не получил предупреждений. Если вдруг клиент использует оба API одновременно, то предупреждение он получит только на тех, которые deprecated. Потому что deprecated — свойство API а не клиента.

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

P>>Ты альтернативу так и не показал, кроме "у нас есть рассылки" Рассылки сами все проблемы порешают?
·>Они решают проблемы как минимум не хуже, чем хедеры. А по некоторым параметрам — значительно лучше.

Ты так и не показал весь цикл решения проблем. Собственно, ты только повторяешь мантру "лучше иначе", "емейлы решают все проблемы"

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

А я её и не знаю на момент добавления такого кода. В этом и цель — сделать так, что бы в логах появилась нужная мне инфа в тех случаях, которые недоступны в тестах.

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

А что, все сводится к фаанг?

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

Не надо вилять — покажи как ты будешь ту самую комбинацию искать тестами. Ты же утверждаешь, что де все известно на момент написания кода. Вот и покажи это.
ты в очередной раз увиливаешь. assert это про варнинги, в т.ч. Сработал ассерт — можно/нужно рендерить варнинг.

·>Впрочем отвечу, intermittent failures мы искали постоянным прогоном тестов в тестовых окружениях.

И это не гарантирует нахождение ошибки, всего лишь повышает вероятность обнаружения.

> С random, конечно, проблем не припомню, но всякие race conditions, эффекты асинхронности, зависимость от текущего времени, переход летнее-зимнее время — ловили. Никаких warning хедеров ясен пень. assert не проходит — это фатальное исключение и падение теста.

Ассерт это далеко не всегда фатальное исключение. Иногда это просто странный кейс.

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

Это вариант нормы, на самом деле. Если уж у нас могут быть разные протоколы, то имеет смысл выделить варнинг в поле в энвелопе.

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

Ну да — городить огород. "слежение за анонсами" как правило трудно применить к конкретному коду — разработчики уже заняты чем то другим, а может и уволились, а команда эксплуатации не имеет глубоких знаний по внутренностям продукта.

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

Мы пока так и не узнали, какую альтернативу ты предлагаешь, кроме как спамить емейлами.

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

Административные проблемы как были, так и остались. Зато хидер работает всегда, вне зависимости, читаешь ты емейлы или нет.

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

Как ты узнаешь, что мелкое изменение на твоей стороне будет супер-критичным для 1й из 100 команд?
Каким образом та команда узнает, что вон в той рассылке, что они пропустили неделю назад из за воркшопа, для них было чтото супер-критичное?
Даже если они увидели — они то не в курсе, на что ваш фикс вообще повлиять может.

·>А хедер у вас лично CEO читает в реальном времени, и тут же указания раздаёт. Так что-ли?

Ты адекватен? Я же тебе сказал, что это на раз прикручивается к мониторингу. Ты уже ударился в юродствование. Какой в этом смысл?

P>>А вот на звоночек в мониторинге реагируют очень быстро, и L2 суппорт в состоянии купировать большинство проблем.
·>L2 у нас и на емейлы реагирует. Работа у них такая. Бизнес и клиенты о своих проблемах емейлы шлют, в хедеры они не умеют.

У них та же проблема — емейлы слишком перегруженый канал. И это всегда устаревшая или искаженная инфа. А вот то, что происходит прямо сейчас всегда будет намного актуальнее.

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

В той или иной степени эта проблема есть у большинства корпораций. Она административной природы и решить её одномоментно не выйдет. А раз так, то все завязаные на емейлы методы будут регулярно давать сбой.

P>>Ну вот был воркшоп, чтение емейлов перенесли на завтра. Упс. Что делать?
·>С таким же успехом перенесут и анализ хедеров. Что делать?

Мониторинг никогда никуда не переносится, за ним следят 24/7

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

К тому, что ты игнорируешь проблемы емейлов. У тебя это магическая волшебная палочка.

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

Я помню — ты умеешь писать без багов, и все проблемы находишь тестами.

P>>Вместо этого "давайте глянем ваши логи... Видите — варнинг такой, следовательно, вам надо обновить вашу конфигурацию"
·>Т.е. ваши хедеры проблему не решили, а допустили до прода. А проблему, в итоге, решает не хедер, а голос. Полный фейл.

Ты похоже забыл, о чем речь — проблема изначально на вызывающей стороне которая возможно была задеплоена год назад.
Давать всем отлуп после деплоя нового сервиса идея так себе — всё, что работало, должно продолжить работать.


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

Какие свои логи? У вас что, девелоперы имеют доступ к логам на проде? Девелопер имеет доступ к логам только через L2 в момент траблшутинга.
И постучится тебе не ваш L2, а тот, с клиентской стороны. А если им это не надо, то нет смысла приседать.

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

Разумеется. Раз уж подобный хидер это внутренний стандарт, то L2 точно в курсе дел. Вообще, в хидеры помещается много инфы именно для помощи L2.

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

M>·>Ты же как-то узнаёшь, что используется именно deprecated api...
M>В смысле "узнаю"? Ну да, я сам лично написал, что на моем сервере /api/v21 — deprecated. И если это API вызвали, оно используется.
Т.е. идентифицируешь клиента по суффиксу в урле. в чём возражение-то?

M>·>Получается т.е. ты идентифицируешь deprecated клиентов по урлу или как-то иначе
M>Я вообще не идентифицирую клиентов. У меня даже понятия "deprecated клиент" нет. И я не знаю, чем и как клиент вызывает мой API — curl, ручной код, какая-то сгенерированная библиотека. Я идентифицирую deprecated API по той информации (данным запроса), которые посылаются всеми клиентами.
Ну я наверно терминологию неудачно выбрал. Под идентификацией клиента я подразумевал как различать приходящие API запросы и классифицировать их на "хорошие" и "плохие".

M>Warning имеет семантику "Чувак, кто бы ты ни был! Пожалуйста, больше не делай так, как сделал сейчас. Это уже не модно. Пока что то, что ты сделал, работает. Но через какое-то время перестанет. И это будет твоя проблема!". Мне не нужно связывать запрос с чем-то еще для маршрутизации сообщений по альтернативному каналу. Использовал deprecated API — получил предупреждение прямо в заголовках ответа. Использовал modern API — не получил предупреждений. Если вдруг клиент использует оба API одновременно, то предупреждение он получит только на тех, которые deprecated. Потому что deprecated — свойство API а не клиента.
Так в этом-то и беда. Отправка warning ничего нового не даёт. И тебе всё равно придётся связаться с девелоперами и узнать когда они таки перестанут использовать deprecated, если требуется обеспечить надёжное функционирование всей системы. А если обеспечение надёжности не твоя забота, то и узнавать ничего не нужно, и варнинги не нужны. Отрубаешь deprecated и они сами придут и спросят.

Здравствуйте, 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.
Ты ловко жонглируешь условиями. Ты уж определись. То у тебя внутренний стандарт, то у тебя тысячи внешних консьюмеров.
Впрочем, опять не аргумент. Ничто не мешает емейл-рассылку или джиру или ещё чего сделать внутренним стандартом. В чём преимущество хедера-то?

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

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

Ты заменил их на емейлы, которые ненадежны по своей природе. То есть, надо ждать регулярных фейлов.

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

Это уже не важно. Главное, что ассерты и тесты это немного разные классы задач, которые всего лишь пересекаются.

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

Неверно. Речь о проблемах во входных данных. Ровно как с компилятором — подкидываешь ему код, а он кидает тебе результат + варнинги.
Варнинги это информация о качестве результата, нужна вызывающей стороне в первую очередь.

> Зачем это передавать куда-то по хедерам наружу?

Затем, что во время процессинга возникли варнинги и вызывающей стороне хорошо бы быть в курсе дел.

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

Не стоит валять дурака — здесь была речь о том, что ты не в курсе ассертов. И я показал как это искать ассертами.

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

Ассерт это это if + log.

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

Ассерты при правильном применении детектят определенные классы проблем, которые не обнаруживаются тестами.

P>>Ассерт это далеко не всегда фатальное исключение. Иногда это просто странный кейс.
·>По крайней мере в c++/java/c#/python — всегда. Даже не припомню где это не так.

Ты извини, но это снова про твой кругозор.

·>Может быть "плохой" и совокупность нескольких запросов, и, даже, отсутствия неких нужных запросов. В какие хедеры пихать такие варнинги совсем неясно.

Да тебе похоже ясно только как емейлы слать, которые не то читают, не то нет

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

Цитирую себя:
"разработчики уже заняты чем то другим, а может и уволились"
Т.е. все ложится на команду эксплуатации. Им что, следить за всеми анонсами всех сервисов? Эдак придется штат раз в десять раздуть.

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

Ну вот в компиляторе ты часто видишь подобные варнинги?

P>>Мы пока так и не узнали, какую альтернативу ты предлагаешь, кроме как спамить емейлами.
·>Не спамить хедерами.

Не ясно, что конкретно ты предлагаешь, какой флоу и что делать, если емейл опоздал, затерялся, итд

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

В том то и дело, что емейлы работают только если
1 если их читают все кому нужно
2 вовремя
3 и после чтения емейла точно известны последствия конкретно в твоем продукте

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

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

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

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

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

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

Технически — ничем. Главное, что бы ихний мониторинг сработал. Варнинг — это дополнительная фича АПИ, когда мы передаем информацию о качестве результата.
Если у нас нет такого поля в пейлоаде, что чаще всего и будет, то единственный вариант для хттп это хидер.

·>Это закон природы такой что-ли? Можно разные адреса заводить, можно тикеты в джире. В конце концов мониторинг может технически и по smpt ходить и на дашборд варнинги выкидывать.

Предлагаешь на миллион запросов создавать миллион тикетов в джыре? Или писать AI который будет фильтровать, тот ли это баг или не тот?

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

ну да, ты то без багов пишешь, я помню — у тебя баги на прод не попадают.

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

Успокойся — все административные проблемы так или иначе решаются техническими средствами. Например, ты скажешь использовать рассылку. Упс — рассылка это техническое средство.
Единственное, что делает менеджмент, это принятие решений, как именно будет решаться та, или иная проблема. Скажет решать емейлами — будет решаться емейлами.
Скажет, что чрез транспорт реквеста — будет решаться через хидеры.

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

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

Я ж тебе пример привел — продуктовую команду разогнали, и остался только L2, который один на все сервисы. Ну прочитали они, что какой то компонент пофиксал баг в парсере адреса. Дальше что, как им понять, на какие из 100...1000 проектов на проде это повлияет?

·>Технически емейл от хедера в данном отличается лишь протоколом, smtp vs http. У хедеров ровно те же административные проблемы.

Не только. хедер лежит вместе с респонзом, request-id и прочими вещами, не надо никаких приседаний, что бы начать инвестигейт.

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

Проблема на их части продакшна, что очевидно. Вот и нужно максимально быстро сигнализировать именно на той части.

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

Вот-вот. Ты то хвастался, что impact analysis делаешь, а однако никаких средств у тебя на то нет

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

Твои логи никто не отменял, и changelog никто не отменял.

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

Емейл как стандарт работает плохо — майлбоксы у ключевых людей как правило переполнены. Джира получше, только создавать тикет надо не в твоей джире, а на той стороне, куда у тебя доступа нет

Здравствуйте, 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>Джира получше, только создавать тикет надо не в твоей джире, а на той стороне, куда у тебя доступа нет
Это опять же административная проблема, и фиксится за минуту.

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

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>>Джира получше, только создавать тикет надо не в твоей джире, а на той стороне, куда у тебя доступа нет
·>Это опять же административная проблема, и фиксится за минуту.

Ну расскажи, в какой джире надо создать тикет, и когда именно, если все запросы исходят будто бы от одного сервиса на той стороне, а на самом деле там сотни команд/продуктов/сервисов со своими трекерами.

Здравствуйте, 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). Какое предназначение я так подло скрыл, по-твоему? Статью ты не читал же. Вот ещё цитаты оттуда же:

Assertions are distinct from routine error-handling.

Using assertions as a general-purpose error handling mechanism is unwise: assertions do not allow for recovery from errors

Главная идея в статье вики в том, что ассертами покрывается сам код, а не ошибки во входных данных. И если ассерты падают, то это значит, что требуется поиск баги в самом коде, а не у консьюмеров твоего кода.
Вот и совершенно неясно что было в голове у человека, который придумал что результаты ассертов можно отдавать наружу. Прям классикой пахнуло. 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>Ну расскажи, в какой джире надо создать тикет, и когда именно, если все запросы исходят будто бы от одного сервиса на той стороне, а на самом деле там сотни команд/продуктов/сервисов со своими трекерами.
Если совсем всё плохо в организации, то в любой, для начала. А там уже выяснять кто за что отвечает по цепочке, передавая ответственность за решение проблемы.

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

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

Смотрим вместе:

0. Ты обнаружил precondontion.
1. Код ворнинга — это ваша зона ответственности, варнинги должны быть покрыты тестами и пройти код ревью.
2. QA — снова ваша зона ответсвенности, qa дают добро на выход в прод
3. Хедер — пишется автоматически, ваша зона ответственности, покрыто тестами
4. Система логгирования — их зона ответственности
5. Мониторинг — это правило для деплоймента, добавляется ровно 1 степ на фильтрацию логов
6. L2 замечает проблему
7. L2 расследует
8. разработчик-менеджер — не абы кто из рассылки, а именно тот, кто отвечает за конкретный продукт

Твой вариант — 0..4 тож самое, только в хидеры ничего не пихаете. Вместо 4..5 у тебя
1. взять человека, который будет заниматься роутингом по request-id при получении соответствующего письма
2. ожидать, что на той стороне люди будут форвардить друг другу письма, тикеты итд

далее 6,7,8 один в один.

Итого — цепочка примерно та же, только ручной роутинг-форвардинг вносит хаос.

> Уж лучше validation, input check, argument check, precondition, warning, complain, report, fault, defect и т.п. Но причём тут ассерты, вообще неясно.

Забавно, что ты перечислил целую кучу разновидностей ассертов
Разница только в том, что
1. есть ли продолжение или нет
2. стратегия обработки разные

И что очевидно, ассерты это не error handling, а способ обнаружить проблему.Понадобится после этого error handling, или нет, это уже дело десятое.

Про комбинации я уже устал писать, вероятно ты ожидаешь ассерт вида assert(x == combination), очевидно, что такие ассерты смысла не имеют т.к. тесты сработают лучше.
Ассерты нужно применять тогда, когда мы знаем только свойства, под которые может подойти сколько угодно комбинаций и заранее ни одна из них неизвестна.

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

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

P>Смотрим вместе:
P>0. Ты обнаружил precondontion.
P>1. Код ворнинга — это ваша зона ответственности, варнинги должны быть покрыты тестами и пройти код ревью.
P>2. QA — снова ваша зона ответсвенности, qa дают добро на выход в прод
P>3. Хедер — пишется автоматически, ваша зона ответственности, покрыто тестами
P>4. Система логгирования — их зона ответственности
P>5. Мониторинг — это правило для деплоймента, добавляется ровно 1 степ на фильтрацию логов
P>6. L2 замечает проблему
P>7. L2 расследует
P>8. разработчик-менеджер — не абы кто из рассылки, а именно тот, кто отвечает за конкретный продукт

P>Твой вариант — 0..4 тож самое, только в хидеры ничего не пихаете.
Нет. Необходим только 0 (и вообще это не шаг как таковой, а так, начало всего процесса). После этого (в тяжелых случаях) можно добавить логгирование в наш код для инвестигирования проблемы, но в большинстве случаев существующих логов вполне достаточно. Для наших логов QA не нужен, т.к. они наши и их качество — наша внутренняя проблема. Вы же хедер публикуете наружу клиентам, через API. Значит QA необходим, т.к. client-driven тестирование вещь, мягко говоря, не лучшая идея.

P> Вместо 4..5 у тебя
P>1. взять человека, который по request-id будет заниматься роутингом по request-id
Искать по request-id что, откуда, куда, зачем пришло всё равно постоянно приходится. С варнингами и без. С этим справляется любой у кого есть доступ к логам.

P>2. ожидать, что на той стороне люди будут форвардить друг другу письма, тикеты итд
Это то что у тебя на шагах 6-7-8.

P>далее 6,7,8 один в один.
6 не нужно, т.к. проблему ты сообщаешь явно и, в идеале, добиваешься подтверждения у получателя, что проблему начали расследовать.

P>Итого — цепочка примерно та же, только ручной роутинг-форвардинг вносит хаос.
Нет.

>> Уж лучше validation, input check, argument check, precondition, warning, complain, report, fault, defect и т.п. Но причём тут ассерты, вообще неясно.
P>Забавно, что ты перечислил целую кучу разновидностей ассертов
Это только в твоей уникальной терминологии.

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

P>>Твой вариант — 0..4 тож самое, только в хидеры ничего не пихаете.
·>Нет. Необходим только 0 (и вообще это не шаг как таковой, а так, начало всего процесса). После этого (в тяжелых случаях) можно добавить логгирование в наш код для инвестигирования проблемы, но в большинстве случаев существующих логов вполне достаточно. Для наших логов QA не нужен, т.к. они наши и их качество — наша внутренняя проблема. Вы же хедер публикуете наружу клиентам, через API. Значит QA необходим, т.к. client-driven тестирование вещь, мягко говоря, не лучшая идея.

Вы выкатили в прод, значительной часть логов не появляется вовсе. Вот тебе и "QA не нужен".

P>> Вместо 4..5 у тебя
P>>1. взять человека, который по request-id будет заниматься роутингом по request-id
·>Искать по request-id что, откуда, куда, зачем пришло всё равно постоянно приходится. С варнингами и без. С этим справляется любой у кого есть доступ к логам.

У тебя всё на емейл завязано. Вы кинули куда то емейл — там должен сидеть человек, чья работа будет заключаться в первичном сборе сведений, и только потом он должен форвардить реквест той или иной команде...
Отфорвардил. И что? А там менеджер ушел в отпуск, и к L2 это не попадёт.- Или ты предлагаешь емейлы слать на всех причастных? Эдак вообще ничего не будет обработано.

P>>2. ожидать, что на той стороне люди будут форвардить друг другу письма, тикеты итд
·>Это то что у тебя на шагах 6-7-8.

Совсем не то.

P>>далее 6,7,8 один в один.
·>6 не нужно, т.к. проблему ты сообщаешь явно и, в идеале, добиваешься подтверждения у получателя, что проблему начали расследовать.

Снова какая то магия, ну или неявные предположения, как работает та или иная контора.

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

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

P>>>Твой вариант — 0..4 тож самое, только в хидеры ничего не пихаете.
P>·>Нет. Необходим только 0 (и вообще это не шаг как таковой, а так, начало всего процесса). После этого (в тяжелых случаях) можно добавить логгирование в наш код для инвестигирования проблемы, но в большинстве случаев существующих логов вполне достаточно. Для наших логов QA не нужен, т.к. они наши и их качество — наша внутренняя проблема. Вы же хедер публикуете наружу клиентам, через API. Значит QA необходим, т.к. client-driven тестирование вещь, мягко говоря, не лучшая идея.
P>Вы выкатили в прод, значительной часть логов не появляется вовсе. Вот тебе и "QA не нужен".
Для наших логов QA не нужен. Для хедеров отправляемых наружу — нужен. Логи такого типа это дело разработчиков и никого больше не касается.

P>>>1. взять человека, который по request-id будет заниматься роутингом по request-id
P>·>Искать по request-id что, откуда, куда, зачем пришло всё равно постоянно приходится. С варнингами и без. С этим справляется любой у кого есть доступ к логам.
P>У тебя всё на емейл завязано. Вы кинули куда то емейл — там должен сидеть человек, чья работа будет заключаться в первичном сборе сведений, и только потом он должен форвардить реквест той или иной команде...
Ровно то, что у тебя происходит на шаге 6 и 7.

P>Отфорвардил. И что? А там менеджер ушел в отпуск, и к L2 это не попадёт.- Или ты предлагаешь емейлы слать на всех причастных? Эдак вообще ничего не будет обработано.
Чейсить и эскалайтить. Ровно то что должно происходить у тебя на шагах 6 и далее.
Проблема в том, что у тебя в твоей схеме обрыв в коммуникации. До того как вам прибегут с прода злые клиенты ты не знаешь что происходит начиная с 4го шага.

P>>>2. ожидать, что на той стороне люди будут форвардить друг другу письма, тикеты итд
P>·>Это то что у тебя на шагах 6-7-8.
P>Совсем не то.
А что?

P>>>далее 6,7,8 один в один.
P>·>6 не нужно, т.к. проблему ты сообщаешь явно и, в идеале, добиваешься подтверждения у получателя, что проблему начали расследовать.
P>Снова какая то магия, ну или неявные предположения, как работает та или иная контора.
Расскажи как работает ваша контора.

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

P>>Вы выкатили в прод, значительной часть логов не появляется вовсе. Вот тебе и "QA не нужен".
·>Для наших логов QA не нужен. Для хедеров отправляемых наружу — нужен. Логи такого типа это дело разработчиков и никого больше не касается.

На ваши логи завязана такая капабилити, как уведомление той стороны о проблемах(SLA). Следовательно, нужен QA который скажет, что логи соответствуют вашим внутренним ожиданиям(предоставить гарантии SLA).

P>>У тебя всё на емейл завязано. Вы кинули куда то емейл — там должен сидеть человек, чья работа будет заключаться в первичном сборе сведений, и только потом он должен форвардить реквест той или иной команде...
·>Ровно то, что у тебя происходит на шаге 6 и 7.

6 и 7 это работа L2 конкретной команды. А у тебя эту команду еще разыскать надо методом форварда емейлов и анализом трейсов.

P>>Отфорвардил. И что? А там менеджер ушел в отпуск, и к L2 это не попадёт.- Или ты предлагаешь емейлы слать на всех причастных? Эдак вообще ничего не будет обработано.
·>Чейсить и эскалайтить. Ровно то что должно происходить у тебя на шагах 6 и далее.
·>Проблема в том, что у тебя в твоей схеме обрыв в коммуникации. До того как вам прибегут с прода злые клиенты ты не знаешь что происходит начиная с 4го шага.

Если они прибегают, то мы спрашиваем у них request id и мы можем показать весь процессинг на нашей стороне.

P>>Совсем не то.
·>А что?

При условии добросовестной реализации или использования нашего клиента можно ожидать
1. корректные логи
2. мониторинг прикрученый к этим логам
Отсюда ясно, что информирован будет L2 непосредственно того самого сервиса.
А в твоём случае этого L2 еще найти надо будет перекидыванием тикетов и форвардом емейлов.

P>>Снова какая то магия, ну или неявные предположения, как работает та или иная контора.
·>Расскажи как работает ваша контора.

Зачем? ты делаешь слишком много предположений. В норме нужно предоставлять не только сам ответ, но и диагностику. Обслуживание сервисов стоит чудовищно дорого из за ручного труда. Если подкидываешь с ответом еще и диагностику, то значительную часть таких издержек можно автоматизировать.

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

P>>>Вы выкатили в прод, значительной часть логов не появляется вовсе. Вот тебе и "QA не нужен".
P>·>Для наших логов QA не нужен. Для хедеров отправляемых наружу — нужен. Логи такого типа это дело разработчиков и никого больше не касается.
P>На ваши логи завязана такая капабилити, как уведомление той стороны о проблемах(SLA). Следовательно, нужен QA который скажет, что логи соответствуют вашим внутренним ожиданиям(предоставить гарантии SLA).
Не очень что ты конкретно имеешь в виду, что именно завязано? Скажем, в рассматриваемом примере deprecated api, нам не нужны логи, мы и так уже знаем, что некий наш API мы решили сделать deprecated.
Формально мы по логам можем ответить на вопрос, мол, сколько в данный момент запросов мы получаем на deprecated api, но это не слишком полезное знание. Ибо наличие/отсутствие реальных запросов ни о чём не говорит. Важно получить подверждение от всех клиентов, что они переписали свои приложения на новый API, успешно всё задеплоили и не собираются делать rollback. Вот только такое явное подтверждение может дать более менее сильную гарантию, что нам не побегут с прода несущие убытки злые клиенты. Наличие варнингов, хедеров, мониторинга — ни о чём. Ибо, повторюсь, проблема административная, требующая коммуникации, _двухсторонней_, между людьми, а не между приложениями.

P>>>У тебя всё на емейл завязано. Вы кинули куда то емейл — там должен сидеть человек, чья работа будет заключаться в первичном сборе сведений, и только потом он должен форвардить реквест той или иной команде...
P>·>Ровно то, что у тебя происходит на шаге 6 и 7.
P>6 и 7 это работа L2 конкретной команды. А у тебя эту команду еще разыскать надо методом форварда емейлов и анализом трейсов.
У тебя ровно то же: А вот через транспорт однозначно известно, что происходит — нажали кнопку "показать трейсы" и сразу нашли, что вон тот сервис принадлежит команде ххх.
Или ты в прыжке переобуваешься?

P>>>Отфорвардил. И что? А там менеджер ушел в отпуск, и к L2 это не попадёт.- Или ты предлагаешь емейлы слать на всех причастных? Эдак вообще ничего не будет обработано.
P>·>Чейсить и эскалайтить. Ровно то что должно происходить у тебя на шагах 6 и далее.
P>·>Проблема в том, что у тебя в твоей схеме обрыв в коммуникации. До того как вам прибегут с прода злые клиенты ты не знаешь что происходит начиная с 4го шага.
P>Если они прибегают, то мы спрашиваем у них request id и мы можем показать весь процессинг на нашей стороне.
Вот именно. Т.е. хедер не особо то и нужен.

P>>>Совсем не то.
P>·>А что?
P>При условии добросовестной реализации или использования нашего клиента можно ожидать
Это слишком невероятное условие. Практически наверняка невыполнимое для тысяч консьюмеров.

P>Отсюда ясно, что информирован будет L2 непосредственно того самого сервиса.
Проблема не в том, кто информирован, а в том, что коммуникация односторонняя. А следовательно non-guarateed message delivery.

P>А в твоём случае этого L2 еще найти надо будет перекидыванием тикетов и форвардом емейлов.
Или трейсом по request-id. Техническая реализация не так важна.

P>>>Снова какая то магия, ну или неявные предположения, как работает та или иная контора.
P>·>Расскажи как работает ваша контора.
P> Зачем? ты делаешь слишком много предположений. В норме нужно предоставлять не только сам ответ, но и диагностику. Обслуживание сервисов стоит чудовищно дорого из за ручного труда. Если подкидываешь с ответом еще и диагностику, то значительную часть таких издержек можно автоматизировать.
Верно. Но совершенно необязательно диагностику прокидывать по тому же каналу.
Более того, это не всегда технически возможно использовать тот же канал. Ты так и не предложил как это делать в отличных от REST request-response случаях Т.е. решение, как минимум, не универсальное, а значит всё равно понадобится другое решение.

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

P>>·>Ровно то, что у тебя происходит на шаге 6 и 7.
P>>6 и 7 это работа L2 конкретной команды. А у тебя эту команду еще разыскать надо методом форварда емейлов и анализом трейсов.
·>У тебя ровно то же: А вот через транспорт однозначно известно, что происходит — нажали кнопку "показать трейсы" и сразу нашли, что вон тот сервис принадлежит команде ххх.
·>Или ты в прыжке переобуваешься?

В моем случае это делает L2 той самой команды, что обслуживает конкретный сервис. А в твоём случае её еще найти надо, через те же самые трейсы, тк у тебя этот сервис изначально неизвестен. Что предложишь, форвардить мессагу всем L2 и попросить, что бы они разыскали каждый своё? Или нанять человека, кторый будет диспетчером работать?

P>>·>Проблема в том, что у тебя в твоей схеме обрыв в коммуникации. До того как вам прибегут с прода злые клиенты ты не знаешь что происходит начиная с 4го шага.
P>>Если они прибегают, то мы спрашиваем у них request id и мы можем показать весь процессинг на нашей стороне.
·>Вот именно. Т.е. хедер не особо то и нужен.

Ты что, ногой читаешь или затылком?
У нас хидер нужден для другого кейса — мы им сообщаем что у них проблема.

P>>При условии добросовестной реализации или использования нашего клиента можно ожидать
·>Это слишком невероятное условие. Практически наверняка невыполнимое для тысяч консьюмеров.

Это минимальное условие, которое можно себе позволить.

P>>Отсюда ясно, что информирован будет L2 непосредственно того самого сервиса.
·>Проблема не в том, кто информирован, а в том, что коммуникация односторонняя. А следовательно non-guarateed message delivery.

С email выходит еще хуже. Например, регулярно случается кейс "ой, шота рассылки перестали ходить"

P>>А в твоём случае этого L2 еще найти надо будет перекидыванием тикетов и форвардом емейлов.
·>Или трейсом по request-id. Техническая реализация не так важна.

Всё равно нужно искать ту самую команду, а уже потом внутри нее разбираться с произошедшим. То есть — два шага.

·>Верно. Но совершенно необязательно диагностику прокидывать по тому же каналу.
·>Более того, это не всегда технически возможно использовать тот же канал. Ты так и не предложил как это делать в отличных от REST request-response случаях Т.е. решение, как минимум, не универсальное, а значит всё равно понадобится другое решение.

Ровно то же, только рендерить будем не в хидер, а в энвелоп "диагностика: { варнинг: "<описание или ссылка или еще что>" }"

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

P>>Кому ты емейлы слать будешь? На той стороне вполне себе возможна ситуация что N консумеров-клиентов-подразделений и чуть не все пользуются одними и теми же идентификаторами client,product,и тд.
·>Тому кто живёт на шаге 7 или 8.
Налицо какое-то неверное представление об устройстве вселенной.
Емейла того, кто живёт на шаге 7 или 8 у вас нет. И быть не может.
Всё, что вы знаете — это что application с id 22124c40-b22d-4269-b30c-2d0d3ffe5594 успешно логинится в ваш API и вызывает какой-то deprecated метод.
Ок, допустим, вы пошли куда-то в вашу систему регистраций, и выяснили, что приложение 22124c40-b22d-4269-b30c-2d0d3ffe5594 принадлежит клиенту Acme Inc, зарегистрировано в системе в 2016 году.

Дальше что? На какой адрес вы собрались писать письмо? На john.doe@acme.inc, который был указан при регистрации клиента в 2004?
Поздравляю, delivery failed: no such recipient. Джон уже много лет в Акме не работает. Более того, никто из тех, кто его застал, в Акме тоже не работает. Никто там понятия не имеет, на что там подписался Джон, кому ещё он дал ключи приложения, и как это всё применяется.

Наверное, вы, как ответственный сотрудник, пойдёте к к Director of Customer Success, и попросите у него имя Account Manager, который назначен на Acme, inc. В предположении, что у Acme вообще есть SAM или TAM, а не базовый контракт на поддержку.
Найденный вами account manager даст вам адрес актуального контакта из Acme Inc.
Скорее всего, это будет кто-то типа BizDev Manager — девочка, вся работа которой сводится к актуализации контрактов и передаче свежих реквизитов вашей компании в accounts payable.
Ни про какие API она не знает — ну, то есть она знает, что Acme, Inc у вашей конторы потребляет некий сервис. Но ни о версиях, ни о заголовках, ни об айпи адресах она с вами говорить не сможет — это вообще другая вселенная.
После серии писем вы сможете затащить её на zoom call, где глядя ей в глаза, с максимальной убедительностью будете говорить: "Поймите, Сьюзан, через три месяца мы отключаем этот сервис, и что-то на вашей стороне сломается". В следующий раз Сьюзан приведёт коллегу Меган, из legal, которая будет вам объяснять, что отключать сервис никак нельзя по условиям контракта. Что неустойка, которую они с вас слупят, превысит вашу выручку за пять лет и всё такое. Когда вы всё же прорвётесь через этот шторм из юридических терминов, и объясните, что вы просто переводите сервис на новую версию API, Меган скажет "ну, тогда раздел про непредоставление услуги неприменим, и с моей точки зрения всё ок", а вы останетесь один на один со Сьюзан, объяснять, что "нет, это не означает, что нет никакой проблемы".
Потом Сьюзан несколько недель будет искать в Acme, Inc того, кто занимается интеграциями. За эти несколько недель вы получите бездну информации о структуре бизнеса Acme, Inc., о хитросплетении обязанностей и границ ответственности — потому что Сьюзан вам будет таскать на звонки всех подряд, начиная с отдела разработки (нет, они не занимаются интеграциями с внешними сервисами; эти ребята пилят корпоративную систему фин.учёта и ни про какие API не знают), отдела развития (эти вообще модельки на питоне гоняют для анализа профилей активности кастомеров), IT отдела (неа), технического отдела (неа), и так далее.
Каждый раз на согласование митинга будет уходит много времени — все эти люди очень заняты и постоянно уходят в отпуска, из которых вы их ждёте.

А когда найдёт Джима, то тот уверенно вам сообщит, что беспокоиться не о чем, т.к. Acme уже перешла на новую версию вашего API ещё в феврале. На ваши робкие попытки вставить слова про то, что в логах до сих пор идут обращения от их приложения к старому API будут разбиваться о его уверенное "этого не может быть".

Ещё через месяц вы уже знаете не только структуру подразделений Акме, но и топологию их внутренней сети (жалкое зрелище), подробности personal life многих сотрудников (этим занималась Бекки, но она ушла в декрет, список серверов она должна была передать Полу, но не передала, потому что он переспал с Кейт, чего делать не должен был, хотя ребёнок у Бекки не от Пола), и много чего ещё.

Чего вы не знаете — так что за подсистема в Acme долбит ваш устаревший API с неослабевающей интенсивностью, и кто за неё отвечает.

Ваше предложение "тупо отключить его нахрен и всё — тогда-то и посмотрим, кто прибежит жаловаться" встречает резкое непонимание со стороны вашего руководства: "Вам разве Меган не объясняла, сколько будет стоить отказ в обслуживании? Что значит не можете найти — найдите, разберитесь, и помогите им перейти на новую версию".

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

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

P>>>·>Проблема в том, что у тебя в твоей схеме обрыв в коммуникации. До того как вам прибегут с прода злые клиенты ты не знаешь что происходит начиная с 4го шага.
P>>>Если они прибегают, то мы спрашиваем у них request id и мы можем показать весь процессинг на нашей стороне.
P>·>Вот именно. Т.е. хедер не особо то и нужен.
P>У нас хидер нужден для другого кейса — мы им сообщаем что у них проблема.
Почему тогда они прибегают с прода?

P>>>При условии добросовестной реализации или использования нашего клиента можно ожидать
P>·>Это слишком невероятное условие. Практически наверняка невыполнимое для тысяч консьюмеров.
P>Это минимальное условие, которое можно себе позволить.
Звучит невероятно.

P>>>Отсюда ясно, что информирован будет L2 непосредственно того самого сервиса.
P>·>Проблема не в том, кто информирован, а в том, что коммуникация односторонняя. А следовательно non-guarateed message delivery.
P>С email выходит еще хуже. Например, регулярно случается кейс "ой, шота рассылки перестали ходить"
chase&escalate. Ведь email это двухсторонний канал. А хедер — односторонний. В этом основная беда.

P>>>А в твоём случае этого L2 еще найти надо будет перекидыванием тикетов и форвардом емейлов.
P>·>Или трейсом по request-id. Техническая реализация не так важна.
P>Всё равно нужно искать ту самую команду, а уже потом внутри нее разбираться с произошедшим. То есть — два шага.
Ты ж вроде заявлял, что у вас есть трейсы. С 0го шага вбиваешь request-id и трейсишь до той самой команды. И сразу на 6-7 шаг — на адрес их L2 или AD шлёшь мыло-джиру-whatever.

P>·>Верно. Но совершенно необязательно диагностику прокидывать по тому же каналу.
P>·>Более того, это не всегда технически возможно использовать тот же канал. Ты так и не предложил как это делать в отличных от REST request-response случаях Т.е. решение, как минимум, не универсальное, а значит всё равно понадобится другое решение.
P>Ровно то же, только рендерить будем не в хидер, а в энвелоп "диагностика: { варнинг: "<описание или ссылка или еще что>" }"
Ты так и не рассказал в энвелоп чего. Далеко не всегда есть конкретный response для данного request.

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

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

S>А когда найдёт Джима, то тот уверенно вам сообщит, что беспокоиться не о чем, т.к. Acme уже перешла на новую версию вашего API ещё в феврале. На ваши робкие попытки вставить слова про то, что в логах до сих пор идут обращения от их приложения к старому API будут разбиваться о его уверенное "этого не может быть".
А предложенная альтернатива какая? Посылать им хедеры? Тогда будет уверенное: "что за хедеры? Мы не видели ничего". У Pauel было "давайте глянем ваши логи... Видите — варнинг такой, следовательно, вам надо обновить вашу конфигурацию". Как это реализуется вообще? Тебе придётся изучить не только структуру подразделений Акме, но и устройство сети, установленное ПО, версии и настройки ПО, систему конроля пермишеннов, ибо у Джима нужной роли не хватает, и ссылочка из его букмарков почему-то не работает, а там где он смотрит, ничего такого не видит.