Обеспечиваем устойчивость интеграции (SQAdays-2025) — различия между версиями
(Новая страница: «{{RightNote|Еще об архитектуре}} 25-26.04.2025 Петербург [https://sqadays.com/ '''SQAdays…») |
м |
||
| (не показаны 3 промежуточные версии этого же участника) | |||
| Строка 2: | Строка 2: | ||
25-26.04.2025 Петербург [https://sqadays.com/ '''SQAdays'''] | 25-26.04.2025 Петербург [https://sqadays.com/ '''SQAdays'''] | ||
[https://sqadays.com/ru/talk/131769 Доклад на сайте конференции] | [https://sqadays.com/ru/talk/131769 Доклад на сайте конференции] | ||
| − | Видео | + | Видео https://vimeo.com/1081487929 |
Ошибки обработки операций возникают тогда, когда их не ждут. Причиной может быть как ошибка в софте, так и нештатная операция под нагрузкой, например, deadlock транзакций или падение по памяти. Монолитная архитектура позволяла обернуть обработку запроса пользователя в транзакцию и при ошибке выполнить откат. Распределённая архитектура не даёт такой возможности. Необходимо обеспечивать устойчивость работы приложения другими средствами, а также проверять её при тестировании. | Ошибки обработки операций возникают тогда, когда их не ждут. Причиной может быть как ошибка в софте, так и нештатная операция под нагрузкой, например, deadlock транзакций или падение по памяти. Монолитная архитектура позволяла обернуть обработку запроса пользователя в транзакцию и при ошибке выполнить откат. Распределённая архитектура не даёт такой возможности. Необходимо обеспечивать устойчивость работы приложения другими средствами, а также проверять её при тестировании. | ||
| Строка 8: | Строка 8: | ||
Как тестировать устойчивость работы интеграции и приложения в целом? Придумывать сценарии тестирования, опираясь на описания архитектуры? Что делать в легаси-проектах, когда описания архитектуры неточны? Как в этом помогает понимание бизнес-архитектуры? И как исправлять ситуацию, если взаимодействие систем неустойчиво? Понятно, что в рамках одного доклада невозможно полностью раскрыть все эти вопросы, тема слишком обширна. Но я расскажу о практиках, которые помогают мне получить ответы, и надеюсь, это будет полезно. | Как тестировать устойчивость работы интеграции и приложения в целом? Придумывать сценарии тестирования, опираясь на описания архитектуры? Что делать в легаси-проектах, когда описания архитектуры неточны? Как в этом помогает понимание бизнес-архитектуры? И как исправлять ситуацию, если взаимодействие систем неустойчиво? Понятно, что в рамках одного доклада невозможно полностью раскрыть все эти вопросы, тема слишком обширна. Но я расскажу о практиках, которые помогают мне получить ответы, и надеюсь, это будет полезно. | ||
| − | Пока видео нет, можно смотреть доклад [[Что такое - хорошая интеграция (Saint Highload-2021)]], этот доклад отличается фокусом на устойчивости и тестировании. | + | Пока видео нет, можно смотреть доклад '''[[Что такое - хорошая интеграция (Saint Highload-2021)]]''', этот доклад отличается фокусом на устойчивости и тестировании. |
| + | |||
| + | Из вопросов после доклада я понял, что тема будет иметь продолжение, потому что есть ряд актуальных вопросов, о которых я почему-то забыл при подготовке. Фиксирую их здесь, чтобы не забыть. | ||
| + | * Организационные вопросы обеспечения устойчивости — взаимодействие со смежными командами и заказчиками, создание тестовых стендов, особенно актуальное в ситуации, когда «после релизов все разваливается» (это — цитата из вопроса). | ||
| + | * Смежные с предыдущим вопросы создания mock-объектов, особенно актуальные при отсутствии полноценных интеграционных стендов: технически оно более-менее понятно, но кто несет ответственность, как обеспечить своевременность изменения mock-библиотек при изменениях протоколов. Этих вопросов я немного касался на слайде про тестирование интеграции под нагрузкой, но явно недостаточно. | ||
| + | * Рассмотрение альтернатив для распределенных транзакциям. Мне очевидно, что распределенные транзакции есть безусловное зло, но надо подробнее показать альтернативы, такие как идемпотентные операции, о которых я говорил недостаточно. А также разобрать современные подходы, такие как SAGA, предполагающая, что реализуется откат — насколько оно реалистично. | ||
| + | * Подробнее рассмотреть эффекты многопоточной обработки — перестановку порядка транзакций и псевдопотери, когда транзакции пошли в разные потоки и обработка идет одновременно, а не последовательно. | ||
| + | По всем вопросам у меня тут точно есть опыт, другой вопрос — получится ли его показать с ясными примерами. Будем работать. | ||
| + | |||
| + | = Видео = | ||
| + | |||
| + | {{Vimeoembed|1081487929|720|405}} | ||
= Презентация = | = Презентация = | ||
Текущая версия на 10:59, 1 декабря 2025
25-26.04.2025 Петербург SQAdays Доклад на сайте конференции Видео https://vimeo.com/1081487929
Ошибки обработки операций возникают тогда, когда их не ждут. Причиной может быть как ошибка в софте, так и нештатная операция под нагрузкой, например, deadlock транзакций или падение по памяти. Монолитная архитектура позволяла обернуть обработку запроса пользователя в транзакцию и при ошибке выполнить откат. Распределённая архитектура не даёт такой возможности. Необходимо обеспечивать устойчивость работы приложения другими средствами, а также проверять её при тестировании.
Как тестировать устойчивость работы интеграции и приложения в целом? Придумывать сценарии тестирования, опираясь на описания архитектуры? Что делать в легаси-проектах, когда описания архитектуры неточны? Как в этом помогает понимание бизнес-архитектуры? И как исправлять ситуацию, если взаимодействие систем неустойчиво? Понятно, что в рамках одного доклада невозможно полностью раскрыть все эти вопросы, тема слишком обширна. Но я расскажу о практиках, которые помогают мне получить ответы, и надеюсь, это будет полезно.
Пока видео нет, можно смотреть доклад Что такое - хорошая интеграция (Saint Highload-2021), этот доклад отличается фокусом на устойчивости и тестировании.
Из вопросов после доклада я понял, что тема будет иметь продолжение, потому что есть ряд актуальных вопросов, о которых я почему-то забыл при подготовке. Фиксирую их здесь, чтобы не забыть.
- Организационные вопросы обеспечения устойчивости — взаимодействие со смежными командами и заказчиками, создание тестовых стендов, особенно актуальное в ситуации, когда «после релизов все разваливается» (это — цитата из вопроса).
- Смежные с предыдущим вопросы создания mock-объектов, особенно актуальные при отсутствии полноценных интеграционных стендов: технически оно более-менее понятно, но кто несет ответственность, как обеспечить своевременность изменения mock-библиотек при изменениях протоколов. Этих вопросов я немного касался на слайде про тестирование интеграции под нагрузкой, но явно недостаточно.
- Рассмотрение альтернатив для распределенных транзакциям. Мне очевидно, что распределенные транзакции есть безусловное зло, но надо подробнее показать альтернативы, такие как идемпотентные операции, о которых я говорил недостаточно. А также разобрать современные подходы, такие как SAGA, предполагающая, что реализуется откат — насколько оно реалистично.
- Подробнее рассмотреть эффекты многопоточной обработки — перестановку порядка транзакций и псевдопотери, когда транзакции пошли в разные потоки и обработка идет одновременно, а не последовательно.
По всем вопросам у меня тут точно есть опыт, другой вопрос — получится ли его показать с ясными примерами. Будем работать.
Видео
Видео в HD-качестве, смотрите в полноэкранном режиме.
HTML-код включения <iframe src="https://player.vimeo.com/video/1081487929?title=0&portrait=0" width="720" height="405" frameborder="0"></iframe>
Скачать → на странице видео на vimeo, кнопка «Download»