Сообщение Re[85]: Идемпотентность POST - хорошая ли практика? от 17.10.2022 9:26
Изменено 17.10.2022 9:42 Pauel
Re[85]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, ·, Вы писали:
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, который так же отвалился благодаря варнингам, работают гораздо надежнее.
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, который так же отвалился благодаря варнингам, работают гораздо надежнее.
Re[85]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, ·, Вы писали:
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, который так же отвалился благодаря варнингам, работают гораздо надежнее.
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, который так же отвалился благодаря варнингам, работают гораздо надежнее.