Re[86]: Идемпотентность POST - хорошая ли практика?
От: · Великобритания  
Дата: 19.10.22 09:35
Оценка:
Здравствуйте, 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, который так же отвалился благодаря варнингам, работают гораздо надежнее.
Ты вначале расскажи, как бюджет и планы появляются с приходом одного хедера.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.