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

S>>Непонятно, чем будет плохо, если он есть.
·>Затем, что это дополнительная функциональность, которую надо проектировать, документировать, тестировать, мейнтейнить и т.п. Плюс риск чего-нибудь поломать. Заспамить нечаяно мониторинг у кого-нибудь, например.

Как найти тот самый емейл той самой команды — это вобщем тоже дополнительная функциональность, и надо всех опсов держать в курсе дел, что бы они не подломали рассылки.
И тестировать тоже надо — на тот случай, если с сервиса придет нотификация, нужны гарантии, что их получит нужна команда.
И документировать, и мейнтейнить — поменялся менеджер, надо добавить/удалить емейл из рассылки.
И всё это ручная работа.
Думаешь, человека посадил разгребать емейлы и это не надо тестировать?

S>>·>Например, на одной из прошлых работ у была Market Connectivity team. Которая отвечала за всю ~сотню бирж. И там не только deprecated api (куда кстати, хедер пихать в какой-нибудь FIX — неясно), но и всякие аннонсы изменений в opening hours, holidays, data centre relocations, изменения в требованиях аудита, routing rules, переключения между dr/prd и т.д., т.п.
S>>Интересно, сколько было народу в этой команде.
·>Не помню, порядка 5 человек, вроде, в разных таймзонах чтобы. По сути работа не сложная, но нудная... разгребать письма, поддерживать актуальную инфу во всяких документах, да тикеты создавать; знать структуру бизнеса, кто куда как соединяется, етс.

То есть, ты предлагаешь на полную ставку держать цельную команду. Эдакий кол-центр, и с такой нудной работой люди как правило долго не выдерживают, а значит нужно постоянно иметь пул запасных, который надо постоянно пополнять.
Более того, поскольку они обслуживают чудовщиный трафик 100% времени то задержки неизбежны, — перерывы на обед, скорость работы человека-оператора и тд.

S>>Народ начинает осваивать обязательность, и в версии 1.3 оно становится обязательным, и те, кто игнорировал warninigs, получают 4хх с соответствующим объектом ошибки.
·>Так же можно "наказывать" тех, кто игнорирует емейлы. Вот только емейл будет один, а хедеров миллионы.

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

S>>Постепенно клиенты привыкают обращать внимание на warnings, потому что это выгоднее, чем их игнорировать.
·>Возможно это и сработает в каких-то случаях, но как универсальное решение ну никак не годится. Так я и представил как в каждое из десятка миллиона сообщений в день вдруг мы запихнём какой-то хедер и заспамим логи и мониторинг.

Это гораздо лучше, чем отослать десяток миллионов емейлов.

S>>Как по мне — так нет. Регулярные опоздания с внедрением изменений на 12-18 месяцев — плохой результат. Надо лучше.
·>Так 12-18мес не потому что хедера не было, а потому что люди должны что-то делать. Как десяток тысяч людей заставить что-то сделать быстрее с помощью хедера — не очень понимаю.

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

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

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

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

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

S>>>·>Например, на одной из прошлых работ у была Market Connectivity team. Которая отвечала за всю ~сотню бирж. И там не только deprecated api (куда кстати, хедер пихать в какой-нибудь FIX — неясно), но и всякие аннонсы изменений в opening hours, holidays, data centre relocations, изменения в требованиях аудита, routing rules, переключения между dr/prd и т.д., т.п.
S>>>Интересно, сколько было народу в этой команде.
P>·>Не помню, порядка 5 человек, вроде, в разных таймзонах чтобы. По сути работа не сложная, но нудная... разгребать письма, поддерживать актуальную инфу во всяких документах, да тикеты создавать; знать структуру бизнеса, кто куда как соединяется, етс.
P>То есть, ты предлагаешь на полную ставку держать цельную команду. Эдакий кол-центр, и с такой нудной работой люди как правило долго не выдерживают, а значит нужно постоянно иметь пул запасных, который надо постоянно пополнять.
P>Более того, поскольку они обслуживают чудовщиный трафик 100% времени то задержки неизбежны, — перерывы на обед, скорость работы человека-оператора и тд.
Откуда возьмётся чудовищный трафик? Депрекация API это редкое событие, ну в худшем случае раз в месяц.
Даже если у приложения 1000 зависимостей (а это просто охренительно много), то 1000 емейлов в месяц 2-3 человека разгребут без проблем.
Другое дело, что емейлов будет несколько больше просто потому что емейлы сообщают больше информации, чем могут в себя уместить варнинги. А это значит, что кроме варнингов всё равно потребуется ещё некий канал связи.

S>>>Народ начинает осваивать обязательность, и в версии 1.3 оно становится обязательным, и те, кто игнорировал warninigs, получают 4хх с соответствующим объектом ошибки.
P>·>Так же можно "наказывать" тех, кто игнорирует емейлы. Вот только емейл будет один, а хедеров миллионы.
P>С емейлами у тебя человеческий фактор во всей красе. Емейл будет один — вот это не совсем ясно, с чего бы так. Похоже, здесь снова неявное предположение.
Ты почему-то предполагаешь, что на каждый response с варнингом надо посылать емейл. Нет, надо один емейл на каждый случай изменения функционирования в сервисе. Т.е. кол-во емейлов в худшем случае пропорционально кол-ву релизов сервиса.

S>>>Постепенно клиенты привыкают обращать внимание на warnings, потому что это выгоднее, чем их игнорировать.
P>·>Возможно это и сработает в каких-то случаях, но как универсальное решение ну никак не годится. Так я и представил как в каждое из десятка миллиона сообщений в день вдруг мы запихнём какой-то хедер и заспамим логи и мониторинг.
P>Это гораздо лучше, чем отослать десяток миллионов емейлов.
Даже если это случится (правда я не могу представить как), то это не уронит прод.

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

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

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, который так же отвалился благодаря варнингам, работают гораздо надежнее.
·>Ты вначале расскажи, как бюджет и планы появляются с приходом одного хедера.

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

Здравствуйте, 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.

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

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

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

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

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

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

Твои диспетчеры нужны только для того, что бы найти ту самую L2 команду. И дальше они форвардят емейл L2 команде. В моем случае 6 и 8 это l2 команда, а фунукции диспетчеризации автоматизированы.
Это что, так трудно понять?

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

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

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

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

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

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

Ты путаешь команду разработки и команду эксплуатации. Эти диспетчеры есть часть команды эксплуатации, работают 24/7.

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

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

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

Голосом-емейлом такое не подтверждается. Подтверждают только логи и метрика "вызовы старого апи" == 0 за последние 3 месяца.

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

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

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

Хидеры не роняют прод. Прод может уронить запоздалая реакция на проблему, которая намного вероятнее с человеком, нежели с автоматическим инструментом.

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

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

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

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

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

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

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

Алё — проблемы у вызывающей стороны, которую ты не контролируешь. С твоим продом всё в порядке.

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

Общие слова. Что сейчас делать, писать всем диспетчерам "эй, ребята, а не было ли у вас важного письма для нас за последние полгода?"

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

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

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

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

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

Это именно что закон природы, т.к. в разных конторах ситуация примерно одна и та же.

Свежий пример — несколько не мог восстановить доступ к фейсбуку, т.е. их емейл до меня тупо недоходил. У них — фейсбук, у меня — gmail. Даже обращение в суппорт не помогало. Разрешилось чисто случайно — по прошествии N лет я вдруг начал получать спам от фейсбука. Попробовал ресетнуть пароль и сразу же увидел их письмо в инбоксе.
Вот так работает твой емейл. Кого винить — фейсбук, gmail, еще кого — без понятия.

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

Ты ухитряешься вычитывать вплоть до наоборот. Доступа к трейсам на той стороне, логам на той стороне просто так ни у кого нет.

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

Именно, что ничего нового к решению с хидерами добавлять не нужно. А вот с твоей командой нужны особые приседания приседания
1. понанимать людей в разных таймзонах, сиречь в разных странах
2. понанимать запасных
3. обучить
4. приставить менеджера, который будет обслуживать эту команду

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

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

Именно!

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

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

P>>Ты путаешь команду разработки и команду эксплуатации. Эти диспетчеры есть часть команды эксплуатации, работают 24/7.
·>5 человек это по одному челу в каждой tz и пара прозапас на случай отпусков/етс.

И это только для того, что бы емейлы добирались до нужных людей

P>>Подробно расскажи, как обнаружить неполученное письмо, особенно, если ты не знаешь, а было ли оно послано.
·>Посмотреть ли был у емейла reply.

Похоже, ты вообще не читаешь Еще раз — у тебя inbox пустой. Как узнать, а он и должен быть пустым или там должны быть письма(те что потерялись)?

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

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

С емейлами надо предположить наличие цельной команды в разных часовых поясах, запасных людей на бенче и менеджер-два которые обслуживают её.

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

То есть, тебе нечего сказать

P>>Голосом-емейлом такое не подтверждается. Подтверждают только логи и метрика "вызовы старого апи" == 0 за последние 3 месяца.
·> А потом они внезапно переключатся на DR-сайт, а там они забыли что-то проапдейтить.

Внезапно никто не переключается.

·>Нет уж, логи могут лишь поддтвердить, что "вызовы старого апи" == 0 за последние 3 месяца, что очень важно для какого-нибудь сервиса, который работает раз в квартал. И всё.
·>И для этого хедеры не нужны. Нужны только логи.

С чего ты взял, что раз в квартал? Снова с потолка?

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

Именно. А тротлинг включается при наличии хидера. Об этом тебе уже говорили.

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

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

P>>Наоборот — именно клиент знает, как быть в случае той или иной ситуации. А обрубать внезапно, рубильником, только что 200, через секунду — 404 это далеко не самая лучшая стратегия.
·>Таким образом обрубать тесты — самая лучшая стратегия.

Вы там похоже тем и заняты, что обрубаете тесты "а они только время тратят"

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

И после деплоя, и после изменений у 3rd-party, инфраструктуры, и даже в моменты пиковой нагрузки.

P>>1 Снова у тебя проблема с ассертами. Ассерты должны быть на стороне сервера апи. Они говорят о том, что клиент делает чтото непотребное.
·>404 это тоже сторона сервера.

Это неприемлемо для консумера. Если можно кидать ошибки направо-налево, оно конечно просто — консумер сам винова. Штука в том, что 60-70% приложений это старые приложения, деплоились вообще хрен знает когда. Ломать крайне нежелательно.

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

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

·>Это потому что ты бессовестно спихнул проблему на вызывающую сторону.

А мне кажется, что ты своими емейлами делаешь именно это — используешь заведомо ненадежный канал.