Короткая ссылка: Integration-SQA

25-26.04.2025 Петербург SQAdays
Доклад на сайте конференции
Видео ожидается

Ошибки обработки операций возникают тогда, когда их не ждут. Причиной может быть как ошибка в софте, так и нештатная операция под нагрузкой, например, deadlock транзакций или падение по памяти. Монолитная архитектура позволяла обернуть обработку запроса пользователя в транзакцию и при ошибке выполнить откат. Распределённая архитектура не даёт такой возможности. Необходимо обеспечивать устойчивость работы приложения другими средствами, а также проверять её при тестировании.

Как тестировать устойчивость работы интеграции и приложения в целом? Придумывать сценарии тестирования, опираясь на описания архитектуры? Что делать в легаси-проектах, когда описания архитектуры неточны? Как в этом помогает понимание бизнес-архитектуры? И как исправлять ситуацию, если взаимодействие систем неустойчиво? Понятно, что в рамках одного доклада невозможно полностью раскрыть все эти вопросы, тема слишком обширна. Но я расскажу о практиках, которые помогают мне получить ответы, и надеюсь, это будет полезно.

Пока видео нет, можно смотреть доклад Что такое - хорошая интеграция (Saint Highload-2021), этот доклад отличается фокусом на устойчивости и тестировании.

Из вопросов после доклада я понял, что тема будет иметь продолжение, потому что есть ряд актуальных вопросов, о которых я почему-то забыл при подготовке. ФИксирую их здесь, чтобы не забыть.

Организационные вопросы обеспечения устойчивости — взаимодействие со смежными командами и заказчиками, создание тестовых стендов, особенно актуальное в ситуации, когда «после релизов все разваливается» (это — цитата из вопроса).
Смежные с предыдущим вопросы создания mock-объектов, особенно актуальные при отсутствии полноценных интеграционных стендов: технически оно более-менее понятно, но кто несет ответственность, как обеспечить своевременность изменения mock-библиотек при изменениях протоколов. Этих вопросов я немного касался на слайде про тестирование интеграции под нагрузкой, но явно недостаточно.
Рассмотрение альтернатив для распределенных транзакциям. Мне очевидно, что распределенные транзакции есть безусловное зло, но надо подробнее показать альтернативы, такие как идемпотентные операции, о которых я говорил недостаточно. А также разобрать современные подходы, такие как SAGA, предполагающая, что реализуется откат — насколько оно реалистично.
Подробнее рассмотреть эффекты многопоточной обработки — перестановку порядка транзакций и псевдопотери, когда транзакции пошли в разные потоки и обработка идет одновременно, а не последовательно.

По всем вопросам у меня тут точно есть опыт, другой вопрос — получится ли его показать с ясными примерами. Будем работать.