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

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.