1) Хм, а в чем проблема? При любом отпуске будет падение производительности команды, с этим ничего нельзя делать. Производительность команды - не является какой-то константой, потому все попытки исходить в планировании - не работают. Это, вообще говоря, довольно очевидное заключение. 2.1) Это набор очень сомнительных утверждений. Оценка примерной трудоемкости - это одно. Планирование - это другое (и вообще не относится к зоне ответственности команды). Планирование нельзя делать на оценках трудоемкости (так как планирование - про даты, а они очень плохо связаны с трудоемкостью). Планирование возможно и без точных оценок. Собственно без них и обходится. И бизнес обычно (если там не совсем уж безграмотные сидят) понимает и стоимость получения точных оценок и осмысленность точных планов в неточной области. Да, кстати, более-менее вменяемое планирование на основании оценок возможно только для простых задач. 2.2) Нет, это не так. Скрам подходит только для очень простых задач, ни в коем случае не для сложных проектов. Это достаточно очевидно просто из его дизайна. Не стоит верить маркетинговым заявлениям, нужно смотреть на практики - а они все про поток одинаковых простых задач, которые нужно перемалывать заточенной под эти (и только) задачи командой. Т.е. бригадная сборка автомашин, а не проектирование космического корабля (или даже новой модели автомашины). 2.3) В SG уже вообще почти ничего обязательного нет, стало совсем бессмысленным документом. 2.4) Ни разу не встречал SP нигде, кроме больных скрамом компаний. Собственно, нигде больше и не требуются подобные оценки.
4) В сложных проектах работает стандартный набор подходов - экспертные оценки задач на высоком уровне (т.е. уровне много выше одного спринта на команду), оценки по аналогии (впрочем, это те же экспертные оценки), работа с рисками оценок (благо тут тоже много подходов). SP к оценкам в сложных проектов вообще никак не подходят, этот инструмент - для оценки небольших и одинаковых задач, но оценки на этом уровне - не аддитивны.
1) Что значит "снижается"? Если в команде было 5 человек, а стало 4, при этом этот пятый - единственный сеньор, то производительность команды упадет раза в полтора. Впрочем, это беда не только идеи SP, а всех практик планирования вокруг Scram - они бесполезны.
2) Для сложных задач вообще нельзя выдать хоть какую-то оценку, они потому и сложные. Впрочем, весь Scram - для простых одинаковых задач, а SP - это в первую очередь инструмент для Scram, больше он, насколько знаю, нигде не используется.
3) При чем тут цели команды? Личное снижение производительности происходит из-за кучи причин - выгорание, личные проблемы, влюбленности или ремонта. Это нормальная динамика.
4) Нормально SP нигде не работают. Как и любое подобное планирование.
Это верно только если: 1) состав команды за 4 спринта не менялся (никто не уходил в отпуск, не болел и так далее) 2) все задачи за эти спринты практически одинаковые и не содержат никакой новизны 3) никто в команде не меняется (ни у кого нет личных причин снижать производительность, никто ничему не учиться - и так далее).
В реальности, конечно, эти критерии не срабатывают - поэтому оценка в SP не работает. Собственно, даже автор идеи SP в твиттере извинялся за свою идею, так как ничего хорошего из нее не получилось.
Ну, там нет ничего про собственно гарантии. Сам MassTransit берет на себя только rerty, а вот все прочее (в том числе гарантии транзакционности, гарантии сохранения данных, реализацию нормального outbox и тому подобное) - уже приходится делать руками. А в .Net есть решения для саг не настолько низкого уровня? Фактически, саги в MT - не столько саги, сколько просто акторные движки с возможностью подключить персистанс, но не гарантирующие при этом ничего сверху. На персистентных акторах можно делать распределенные бизнес-транзакции, я даже на HL про это рассказывал когда-то, но это не самый удобный и не самый современный подход. Да и в реализации от MT слишком про много вещей придется думать, если нужны хоть какие-то гарантии.
1) Вот как раз откат по одной транзакции - в среднем плохая идея, так как чаще всего нет возможности откатить конкретный шаг (нельзя отменить отправку sms-ки или однофазовый платеж, например).
2) После падения откатывать - тоже плохая идея, нужно стараться дожимать сценарий (т.е. продолжать его с того шага, на котором упали). Это гораздо лучше для пользователя.
3) Не понятно, зачем там нужна низкоуровневая библиотека, что она дает? При этом у меня 10 строк на все, а в примере на MassTransit кода в разы больше - и это без компенсаций вообще.
Собственно, подоход temporal (или как в приведенном выше куске), с повтором бизнес-запросов, а не с откатом на каждый чих - гораздо удобнее и полезнее в реальной жизни. Ну и кода получается в разы меньше (хотя это уже зависит от конкретной реализации и MassTransit явно не очень удачная, да и кролик для описанной задачи только лишний)
Вообще, конечно, если делать нормальную библиотеку работы с бизнес-транзакциями, то вызов двух API в ней должен выглядеть примерно так (тут вызов трех APIшных вызовов в двух разных сервисах и компенсация - и это все в 10 строчках и это реальный код)
suspend fun onboard(data: OnboardingData) : ClientId = play { val identityId = step { identityService.nextId () } step { identityService.create (identityId, data.credentials) } val clientId = step { clientService.create (identityId, data.clientInfo) } return@play clientId }.onError { step { if (clientId!=null) clientService.remove(clientId) } step { if (identityId!=null) identityService.remove(identityId) } }.async()
Э, какая разница, в контролируемые или нет сервисы делаются запросы? Или сервисы поддерживают компенсацию по шагам и тогда сага еще применима. Или, что чаще, не поддерживают и тогда нужно говорить о компенсации всей бизнес-транзакции целиком. И как раз такие сценарии на temporal реализуются легко (с разными логиками повторов, ожиданий, обработки ошибок и тому подобное), в рамках линейного кода и с понятными гарантиями выполнения сценария даже при падении выполняющего сервера. В MassTransit, судя по примерам, требуется гораздо больше кода, да и с гарантиями все не очень понятно (ну, из статьи). И, думаю, я все-таки хорошо понимаю, о чем говорю, тех же самых платежных систем сделал достаточно.
Если устраивает eventual consistency, то в том же temporal.io это пишется примерно в три строчки, остальная магия как раз внутри движка (сохранение стейта после каждого шага, ретраи, восстановление после падения сервисов, запуск компенсации с теми же гарантиями и так далее). Примеры кода - да на том же https://docs.temporal.io/docs/temporal-explained/introduction Собственно, для этого temporal.io и делался, чтобы простые вещи можно было писать достаточно компактно (впрочем, там тоже хватает своих проблем, разумеется). (У меня сейчас свой движок для распределенных бизнес-транзакций, там все еще компактнее получается, но это не open source)
1) А какие существуют реализации, как они обеспечивают гарантии в распределенной среде? Это, собственно, самое интересное же в движках саг. 4) Обычно в реальной жизни не нужен поток компенсаций отдельных шагов, нужна компенсация всей бизнес-транзакции (паттерн "Сага" сам по себе не очень пригоден для бизнес-транзакций, да и создавался для совсем других целей и технологий). Поэтому в большинстве движков оркестрации есть возможность компенсации всей транзакции, а не набора шагов 5) Пока не понятно, как поможет MassTransit для решения задачи temporal.io (который вообще не про саги в классическом виде). Проще с нуля написать (ну, или взять уже написанный).
Эээ, опять путают Agile и Scrum (подозреваю, что плохо понятый Scrum, так как формально в Scrum не может быть роли QA-инженер). Ну и остальное в статье - того же уровня, пересказ средних курсов по тестированию. При чем тут стратегия тестирования - не понятно.
Если простое действие требует кучу кода - то может быть нужно искать другие решения? Простые вещи должны быть простыми, а бизнес-операция из двух шагов - простая штука.
А как масштабируется эта персистентность? Как она реализуется? Сколько IOPS нужно на каждый шаг саги? Можно ли организовать компенсацию не отдельного шага, а всего сценария? И чем это лучше того же temporal.io?
Стоило бы еще указать, что alter table add column - не совсем безопасная операция. Хотя в современных СУБД изменяются только метаданные, но она все равно требует эксклюзивную блокировку. И, например, в сценарии "длинный отчет, alter table, мелкие пишущие транзакции", все мелкие транзакции будут ждать окончания отчета (т.е. фактически таблица будет заблокирована). Перед миграциями обязательно нужно закрыть все длинные транзакции на таблице (или достоверно знать, что их не может быть).
Хм, у PCI DSS еще куча требований по хранению данных карт, cvv в процессе платежа, составу логов, подходу к разработке и так далее. И это все требует думать про архитектуру на ранних этапах разработки.
Попробуйте найти друзей, у которых обратная проблема (перевод долларов из Москвы в США/Европу) и договоритесь о взаиморасчете. Сейчас многим это актуально (оплата обучения, ипотеки и т.п.)
Хм, если верить Сыма Цяню, то при Сунь-цзы княжество У все-таки выиграло несколько войн. Впрочем, текст трактата скорее всего более поздний, но там слишком много разных вариантов.
Ага. Просто в результате ты комментируешь не действительно один из основопологающих текстов по стратегии (сравнивать можно разве что с Лиддел-Гартом, да с Триандафилловым), а плохой перевод с плохого перевода с перевода, сильно упрощенный относительно оригинала, еще и без комментариев. Потому и рекомендую прочитать Конрада и уже потом вернуться к комментированию. А лучше кроме Конрада еще и комментарии Малянова почитать и другие комментарии к Сунь-цзы, благо их очень много. Ну и про применение Сунь-цзы к современной реальности (от военной стратегии до бизнеса) написано дофига книг (правда, про переводы не слышал). Все-таки хорошо упакованная стихийная диалектика легко применима к текущим проблемам, да и многие другие принципы вполне универсальны.
А по какому переводу цитаты приведены? Это и не Малявинский и не Конрада, больше похож на перевод с английского (весьма неудачная). Вообще, советую почитать именно Конрадовский перевод с его же комментариями, там очень и очень много всякого интересного - от тонкостей перевода и до понимания отдельных фраз в разные эпохи и разными комментаторами.
Как я понимаю, "работало в командах" - относится к одному и только одному случаю? Тогда почему именно указанные вещи достаточны для того, что бы работало? Или они необходимы, а не достаточны? И, кстати, а что значит "работало"?
Увы, я не проходил курсов у Левенчука, так что не мог кратко описать содержимое подхода ШСМ, хотя с удовольствием их порекомендую. Но это уже "следующий уровень", на мой взгляд. С рациональностью чуть сложнее, описанный подход ближе к "формально научному", но и с его применением для улучшения процессов все непростом, тем более все сложно с применением менее очевидных практик из LessWrong-овской тусовки (и вообще я к ним отношусь с любовью, но осторожностью).
1) Хм, а в чем проблема? При любом отпуске будет падение производительности команды, с этим ничего нельзя делать. Производительность команды - не является какой-то константой, потому все попытки исходить в планировании - не работают. Это, вообще говоря, довольно очевидное заключение.
2.1) Это набор очень сомнительных утверждений. Оценка примерной трудоемкости - это одно. Планирование - это другое (и вообще не относится к зоне ответственности команды). Планирование нельзя делать на оценках трудоемкости (так как планирование - про даты, а они очень плохо связаны с трудоемкостью). Планирование возможно и без точных оценок. Собственно без них и обходится. И бизнес обычно (если там не совсем уж безграмотные сидят) понимает и стоимость получения точных оценок и осмысленность точных планов в неточной области.
Да, кстати, более-менее вменяемое планирование на основании оценок возможно только для простых задач.
2.2) Нет, это не так. Скрам подходит только для очень простых задач, ни в коем случае не для сложных проектов. Это достаточно очевидно просто из его дизайна. Не стоит верить маркетинговым заявлениям, нужно смотреть на практики - а они все про поток одинаковых простых задач, которые нужно перемалывать заточенной под эти (и только) задачи командой. Т.е. бригадная сборка автомашин, а не проектирование космического корабля (или даже новой модели автомашины).
2.3) В SG уже вообще почти ничего обязательного нет, стало совсем бессмысленным документом.
2.4) Ни разу не встречал SP нигде, кроме больных скрамом компаний.
Собственно, нигде больше и не требуются подобные оценки.
4) В сложных проектах работает стандартный набор подходов - экспертные оценки задач на высоком уровне (т.е. уровне много выше одного спринта на команду), оценки по аналогии (впрочем, это те же экспертные оценки), работа с рисками оценок (благо тут тоже много подходов). SP к оценкам в сложных проектов вообще никак не подходят, этот инструмент - для оценки небольших и одинаковых задач, но оценки на этом уровне - не аддитивны.
1) Что значит "снижается"? Если в команде было 5 человек, а стало 4, при этом этот пятый - единственный сеньор, то производительность команды упадет раза в полтора.
Впрочем, это беда не только идеи SP, а всех практик планирования вокруг Scram - они бесполезны.
2) Для сложных задач вообще нельзя выдать хоть какую-то оценку, они потому и сложные. Впрочем, весь Scram - для простых одинаковых задач, а SP - это в первую очередь инструмент для Scram, больше он, насколько знаю, нигде не используется.
3) При чем тут цели команды? Личное снижение производительности происходит из-за кучи причин - выгорание, личные проблемы, влюбленности или ремонта. Это нормальная динамика.
4) Нормально SP нигде не работают. Как и любое подобное планирование.
Это верно только если:
1) состав команды за 4 спринта не менялся (никто не уходил в отпуск, не болел и так далее)
2) все задачи за эти спринты практически одинаковые и не содержат никакой новизны
3) никто в команде не меняется (ни у кого нет личных причин снижать производительность, никто ничему не учиться - и так далее).
В реальности, конечно, эти критерии не срабатывают - поэтому оценка в SP не работает.
Собственно, даже автор идеи SP в твиттере извинялся за свою идею, так как ничего хорошего из нее не получилось.
Ну, там нет ничего про собственно гарантии. Сам MassTransit берет на себя только rerty, а вот все прочее (в том числе гарантии транзакционности, гарантии сохранения данных, реализацию нормального outbox и тому подобное) - уже приходится делать руками.
А в .Net есть решения для саг не настолько низкого уровня?
Фактически, саги в MT - не столько саги, сколько просто акторные движки с возможностью подключить персистанс, но не гарантирующие при этом ничего сверху. На персистентных акторах можно делать распределенные бизнес-транзакции, я даже на HL про это рассказывал когда-то, но это не самый удобный и не самый современный подход. Да и в реализации от MT слишком про много вещей придется думать, если нужны хоть какие-то гарантии.
1) Вот как раз откат по одной транзакции - в среднем плохая идея, так как чаще всего нет возможности откатить конкретный шаг (нельзя отменить отправку sms-ки или однофазовый платеж, например).
2) После падения откатывать - тоже плохая идея, нужно стараться дожимать сценарий (т.е. продолжать его с того шага, на котором упали). Это гораздо лучше для пользователя.
3) Не понятно, зачем там нужна низкоуровневая библиотека, что она дает? При этом у меня 10 строк на все, а в примере на MassTransit кода в разы больше - и это без компенсаций вообще.
Собственно, подоход temporal (или как в приведенном выше куске), с повтором бизнес-запросов, а не с откатом на каждый чих - гораздо удобнее и полезнее в реальной жизни. Ну и кода получается в разы меньше (хотя это уже зависит от конкретной реализации и MassTransit явно не очень удачная, да и кролик для описанной задачи только лишний)
Вообще, конечно, если делать нормальную библиотеку работы с бизнес-транзакциями, то вызов двух API в ней должен выглядеть примерно так (тут вызов трех APIшных вызовов в двух разных сервисах и компенсация - и это все в 10 строчках и это реальный код)
suspend fun onboard(data: OnboardingData) : ClientId = play {
val identityId = step { identityService.nextId () }
step { identityService.create (identityId, data.credentials) }
val clientId = step { clientService.create (identityId, data.clientInfo) }
return@play clientId
}.onError {
step { if (clientId!=null) clientService.remove(clientId) }
step { if (identityId!=null) identityService.remove(identityId) }
}.async()
Э, какая разница, в контролируемые или нет сервисы делаются запросы? Или сервисы поддерживают компенсацию по шагам и тогда сага еще применима. Или, что чаще, не поддерживают и тогда нужно говорить о компенсации всей бизнес-транзакции целиком. И как раз такие сценарии на temporal реализуются легко (с разными логиками повторов, ожиданий, обработки ошибок и тому подобное), в рамках линейного кода и с понятными гарантиями выполнения сценария даже при падении выполняющего сервера.
В MassTransit, судя по примерам, требуется гораздо больше кода, да и с гарантиями все не очень понятно (ну, из статьи).
И, думаю, я все-таки хорошо понимаю, о чем говорю, тех же самых платежных систем сделал достаточно.
Если устраивает eventual consistency, то в том же temporal.io это пишется примерно в три строчки, остальная магия как раз внутри движка (сохранение стейта после каждого шага, ретраи, восстановление после падения сервисов, запуск компенсации с теми же гарантиями и так далее). Примеры кода - да на том же https://docs.temporal.io/docs/temporal-explained/introduction
Собственно, для этого temporal.io и делался, чтобы простые вещи можно было писать достаточно компактно (впрочем, там тоже хватает своих проблем, разумеется).
(У меня сейчас свой движок для распределенных бизнес-транзакций, там все еще компактнее получается, но это не open source)
1) А какие существуют реализации, как они обеспечивают гарантии в распределенной среде? Это, собственно, самое интересное же в движках саг.
4) Обычно в реальной жизни не нужен поток компенсаций отдельных шагов, нужна компенсация всей бизнес-транзакции (паттерн "Сага" сам по себе не очень пригоден для бизнес-транзакций, да и создавался для совсем других целей и технологий). Поэтому в большинстве движков оркестрации есть возможность компенсации всей транзакции, а не набора шагов
5) Пока не понятно, как поможет MassTransit для решения задачи temporal.io (который вообще не про саги в классическом виде). Проще с нуля написать (ну, или взять уже написанный).
Эээ, опять путают Agile и Scrum (подозреваю, что плохо понятый Scrum, так как формально в Scrum не может быть роли QA-инженер).
Ну и остальное в статье - того же уровня, пересказ средних курсов по тестированию.
При чем тут стратегия тестирования - не понятно.
Если простое действие требует кучу кода - то может быть нужно искать другие решения?
Простые вещи должны быть простыми, а бизнес-операция из двух шагов - простая штука.
А как масштабируется эта персистентность?
Как она реализуется?
Сколько IOPS нужно на каждый шаг саги?
Можно ли организовать компенсацию не отдельного шага, а всего сценария?
И чем это лучше того же temporal.io?
Стоило бы еще указать, что alter table add column - не совсем безопасная операция. Хотя в современных СУБД изменяются только метаданные, но она все равно требует эксклюзивную блокировку. И, например, в сценарии "длинный отчет, alter table, мелкие пишущие транзакции", все мелкие транзакции будут ждать окончания отчета (т.е. фактически таблица будет заблокирована). Перед миграциями обязательно нужно закрыть все длинные транзакции на таблице (или достоверно знать, что их не может быть).
Хм, у PCI DSS еще куча требований по хранению данных карт, cvv в процессе платежа, составу логов, подходу к разработке и так далее. И это все требует думать про архитектуру на ранних этапах разработки.
Попробуйте найти друзей, у которых обратная проблема (перевод долларов из Москвы в США/Европу) и договоритесь о взаиморасчете. Сейчас многим это актуально (оплата обучения, ипотеки и т.п.)
Хм, если верить Сыма Цяню, то при Сунь-цзы княжество У все-таки выиграло несколько войн. Впрочем, текст трактата скорее всего более поздний, но там слишком много разных вариантов.
Ага. Просто в результате ты комментируешь не действительно один из основопологающих текстов по стратегии (сравнивать можно разве что с Лиддел-Гартом, да с Триандафилловым), а плохой перевод с плохого перевода с перевода, сильно упрощенный относительно оригинала, еще и без комментариев. Потому и рекомендую прочитать Конрада и уже потом вернуться к комментированию. А лучше кроме Конрада еще и комментарии Малянова почитать и другие комментарии к Сунь-цзы, благо их очень много.
Ну и про применение Сунь-цзы к современной реальности (от военной стратегии до бизнеса) написано дофига книг (правда, про переводы не слышал). Все-таки хорошо упакованная стихийная диалектика легко применима к текущим проблемам, да и многие другие принципы вполне универсальны.
А по какому переводу цитаты приведены? Это и не Малявинский и не Конрада, больше похож на перевод с английского (весьма неудачная).
Вообще, советую почитать именно Конрадовский перевод с его же комментариями, там очень и очень много всякого интересного - от тонкостей перевода и до понимания отдельных фраз в разные эпохи и разными комментаторами.
Как я понимаю, "работало в командах" - относится к одному и только одному случаю? Тогда почему именно указанные вещи достаточны для того, что бы работало? Или они необходимы, а не достаточны?
И, кстати, а что значит "работало"?
Увы, я не проходил курсов у Левенчука, так что не мог кратко описать содержимое подхода ШСМ, хотя с удовольствием их порекомендую. Но это уже "следующий уровень", на мой взгляд.
С рациональностью чуть сложнее, описанный подход ближе к "формально научному", но и с его применением для улучшения процессов все непростом, тем более все сложно с применением менее очевидных практик из LessWrong-овской тусовки (и вообще я к ним отношусь с любовью, но осторожностью).