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

P>>Как найти тот самый емейл той самой команды — это вобщем тоже дополнительная функциональность, и надо всех опсов держать в курсе дел, что бы они не подломали рассылки.
·>Это административная проблема, а не техническая.

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

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

Именно. И это наименьшее предположение, которое можно сделать. А вот ожидать, что диспетчеры емейлов будут реагировать оперативно 24/7 — это чудовищно большое предположение.

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

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

P>>Более того, поскольку они обслуживают чудовщиный трафик 100% времени то задержки неизбежны, — перерывы на обед, скорость работы человека-оператора и тд.
·>Откуда возьмётся чудовищный трафик? Депрекация API это редкое событие, ну в худшем случае раз в месяц.
·>Даже если у приложения 1000 зависимостей (а это просто охренительно много), то 1000 емейлов в месяц 2-3 человека разгребут без проблем.
·>Другое дело, что емейлов будет несколько больше просто потому что емейлы сообщают больше информации, чем могут в себя уместить варнинги. А это значит, что кроме варнингов всё равно потребуется ещё некий канал связи.

Ты понаделывал целую кучу предположений.
во первых, мы здесь не только про депрекацию апи. следовательно, емейлов будет много больше и обрабатывать их надо оперативнее.
во вторых, команда из 5 человек в пересчете на зп, налоги и прочие издержки, типа запасные игроки, и тд, съест намного бОльшее количество денег, чем добавление правила в мониторинг и покрытие интеграционными тестами

Теоретически, в емейл ты впихнешь чуть не все подряд. Ну и что? Нам то надо максимально быстрое реагирование, а не количество информации, которое свалится на L2. По барабану, сколько информации в емейле, если идет непрерывный поток таких емейлов.

·>Ты почему-то предполагаешь, что на каждый response с варнингом надо посылать емейл. Нет, надо один емейл на каждый случай изменения функционирования в сервисе. Т.е. кол-во емейлов в худшем случае пропорционально кол-ву релизов сервиса.

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

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

И хидеры точно так же не уронят прод. Это нормальная фича в хттп апи, response headers, и мониторинг, логирование, итд умеют с этим справляться.

Более того, именно вызывающая сторона должна решать, что ей делать со странной ситуацией.

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

Очень просто — упали интеграционные тесты, т.к. интерграционные тесты прода получили варнинги. Релиз автоматически сдвигается, что как правило влечет за собой разбор полетов.
Другой пример — мониторинг покрасился красным, или из за варнингов, или из за тротлинга, или из за количества таймаутов, что влечет за собой разбор полетов, т.к. энд-юзеры начинают жаловаться в суппорт.
В твоем случае был один емейл полгода назад. И что? Я вот вижу, что игнор емейлов существует чуть ли не во всех крупных конторах.