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

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

>> Важен способ как применено техническое решение, а не решение само по себе. Если мониторинг есть, но за ним не следят или игнорируют — такая же беда, как и игнорирование емейлов|джиры|whatever.
P>Мониторинг так устроен, что за ним легче следить, чем за потоком емейлов. И емейлы могут перестать ходить по чисто человеческим причинам, что регулярно бывает.
Это конкретное устройство вашего мониторинга и вашего потока емейлов, а не закон природы.

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

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

P>>>во первых, мы здесь не только про депрекацию апи. следовательно, емейлов будет много больше и обрабатывать их надо оперативнее.
P>·>Емейлов будет не больше, чем условий варнингов. Скорее на порядки меньше.
P>И это проблема. Клиент, у которого нет планов на передеплоймент, нет бюджета, нет команды, вдруг получил емейл. И что ему делать?
P>Через полгода это появилось. Им что, шерстить емейлы за полгода на предмет "а не было ли чего нибудь важного" от N вендоров API?
В случае хедеров, это означает, что их dashboard будет весь сверкать красным с тучей варнигов и юзеры жалуются в их техподдержку.

P>А вот если они теперь попытаются передеплить, то с варнингами их ждет отлуп.
Зачем они что-то будут пытаться передеплоить?

P>>>во вторых, команда из 5 человек в пересчете на зп, налоги и прочие издержки, типа запасные игроки, и тд, съест намного бОльшее количество денег, чем добавление правила в мониторинг и покрытие интеграционными тестами
P>·>Если в твоём приложении 1000 зависимостей, то значит у тебя уже довольно сложная система и там только девов будет десятки-сотни. +5 человек это будут доли процента от бюджета.
P>Ты путаешь команду разработки и команду эксплуатации. Эти диспетчеры есть часть команды эксплуатации, работают 24/7.
5 человек это по одному челу в каждой tz и пара прозапас на случай отпусков/етс.

P>>>·>Ты почему-то предполагаешь, что на каждый response с варнингом надо посылать емейл. Нет, надо один емейл на каждый случай изменения функционирования в сервисе. Т.е. кол-во емейлов в худшем случае пропорционально кол-ву релизов сервиса.
P>>>Во первых, один емейл спокойно может затеряться по целому ряду причин — вся твоя цепочка зависит от человеческого фактора.
P>·>chase&escalate.
P>Подробно расскажи, как обнаружить неполученное письмо, особенно, если ты не знаешь, а было ли оно послано.
Посмотреть ли был у емейла reply.

P>Вот например, проверить, работает ли мониторинг, достаточно небольшой инструкции на той стороне.
Не достаточно. Надо, как минимум, чтобы эту инструкцию прочитали и исполнили без ошибок.

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

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

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

P>>>И хидеры точно так же не уронят прод. Это нормальная фича в хттп апи, response headers, и мониторинг, логирование, итд умеют с этим справляться.
P>·>Надеюсь. Впрочем, я говорил о риске, а не о свершившемся событии. Емейлы не уронят прод, т.к. в принципе уронить прод не могут. А хедеры у вас не роняют прод, т.к. вы делаете всё без багов и хедеры ваши все баги гарантировано находят.
P>Хидеры не роняют прод. Прод может уронить запоздалая реакция на проблему, которая намного вероятнее с человеком, нежели с автоматическим инструментом.
Бинго. И хедеры никак не влияют не реакцию. Ибо они не позволяют увидеть эту реакцию.

P>>>Более того, именно вызывающая сторона должна решать, что ей делать со странной ситуацией.
P>·>Хедер, как механизм спихнуть проблемы на клиента — вещь замечательная, но почему-то мне кажется, что это не самое правильное отношение к клиентам.
P>Наоборот — именно клиент знает, как быть в случае той или иной ситуации. А обрубать внезапно, рубильником, только что 200, через секунду — 404 это далеко не самая лучшая стратегия.
Таким образом обрубать тесты — самая лучшая стратегия.
А обрубать по "вызовы старого апи" == 0 — тоже не самая лучшая стратегия.

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

P>·>Я не очень понял зачем гонять тесты в проде, но это не важно. Ты сам утвержал, что тесты в проде используют специальные аккаунты-настройки-етс. Следовательно можно просто отдавать 400 вместо варнинга для тестов и не полагаться на корректность ассертов на стороне консьюмеров; это гораздо надёжнее и проще.
P>1 Снова у тебя проблема с ассертами. Ассерты должны быть на стороне сервера апи. Они говорят о том, что клиент делает чтото непотребное.
404 это тоже сторона сервера.

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

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