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

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

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

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

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

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

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

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

P>В третьих, в твоем варианте нет возомжности
P>1 запретить передеплоймент, например, старого клиента — только вручную "эй, не надо деплоить вон те версии, смотрите еще один список версий в другой рассылке полгода назад"
404. Т.к. мы уже подтвердили голосом-емейлом, что чуваки окончательно зарелизились и избавились от старого клиента.

P>2 ограничить трафик от старых клиентов — вообще никак
А как хедеры ограничат трафик от старых клиентов?

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

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

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

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

P>В твоем случае был один емейл полгода назад. И что? Я вот вижу, что игнор емейлов существует чуть ли не во всех крупных конторах.
chase&escalate.

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

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

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

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

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

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

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

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

P>В третьих, в твоем варианте нет возомжности
P>1 запретить передеплоймент, например, старого клиента — только вручную "эй, не надо деплоить вон те версии, смотрите еще один список версий в другой рассылке полгода назад"
404. Т.к. мы уже подтвердили голосом-емейлом, что чуваки окончательно зарелизились и избавились от старого клиента.

P>2 ограничить трафик от старых клиентов — вообще никак
А как хедеры ограничат трафик от старых клиентов?

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

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

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

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

P>В твоем случае был один емейл полгода назад. И что? Я вот вижу, что игнор емейлов существует чуть ли не во всех крупных конторах.
chase&escalate.