Спасибо за пример. В статье я намеренно рассматривала упрощённый сценарий взаимодействия двух систем, чтобы разобрать конкретную проблему: timeout не всегда позволяет определить результат бизнес-операции и поэтому требует отдельно продумать retry, идемпотентность и reconciliation.
Сценарий со снятием наличных в другой стране и последующими межсистемными и валютными расчётами требует уже отдельного разбора всей цепочки участников и их контрактов. Это интересный кейс, но он не противоречит тезису статьи: отсутствие ответа само по себе не позволяет сделать вывод о результате бизнес-операции.
Если вы видите ошибку именно в этом тезисе или в предложенных механизмах обработки, то было бы интересно обсудить её предметно.
Спасибо за подробный разбор терминологии. Понравилась мысль, что прежде чем говорить об «отказоустойчивой» или «доступной» системе, важно сначала определить сам критерий отказа, иначе одинаковые слова могут описывать совершенно разные свойства системы.
Правильно ли я понимаю практическое следствие этого подхода для системного аналитика: в нефункциональных требованиях недостаточно написать что-то вроде «система должна обладать высокой доступностью», а нужно определить, что именно считается отказом? При каких условиях система считается работоспособной и каким показателем это измеряется?
Получается, что одна и та же система может одновременно удовлетворять требованиям по отказоустойчивости узлов, но не удовлетворять требованиям по обслуживанию пиковой нагрузки.
Спасибо за пример. В статье я намеренно рассматривала упрощённый сценарий взаимодействия двух систем, чтобы разобрать конкретную проблему: timeout не всегда позволяет определить результат бизнес-операции и поэтому требует отдельно продумать retry, идемпотентность и reconciliation.
Сценарий со снятием наличных в другой стране и последующими межсистемными и валютными расчётами требует уже отдельного разбора всей цепочки участников и их контрактов. Это интересный кейс, но он не противоречит тезису статьи: отсутствие ответа само по себе не позволяет сделать вывод о результате бизнес-операции.
Если вы видите ошибку именно в этом тезисе или в предложенных механизмах обработки, то было бы интересно обсудить её предметно.
Спасибо за подробный разбор терминологии. Понравилась мысль, что прежде чем говорить об «отказоустойчивой» или «доступной» системе, важно сначала определить сам критерий отказа, иначе одинаковые слова могут описывать совершенно разные свойства системы.
Правильно ли я понимаю практическое следствие этого подхода для системного аналитика: в нефункциональных требованиях недостаточно написать что-то вроде «система должна обладать высокой доступностью», а нужно определить, что именно считается отказом? При каких условиях система считается работоспособной и каким показателем это измеряется?
Получается, что одна и та же система может одновременно удовлетворять требованиям по отказоустойчивости узлов, но не удовлетворять требованиям по обслуживанию пиковой нагрузки.