Обеспечиваем устойчивость интеграции (SQAdays-2025) — различия между версиями

Материал из MaksWiki
Перейти к: навигация, поиск
м
м
 
(не показана одна промежуточная версия этого же участника)
Строка 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 транзакций или падение по памяти. Монолитная архитектура позволяла обернуть обработку запроса пользователя в транзакцию и при ошибке выполнить откат. Распределённая архитектура не даёт такой возможности. Необходимо обеспечивать устойчивость работы приложения другими средствами, а также проверять её при тестировании.  
Строка 10: Строка 10:
 
Пока видео нет, можно смотреть доклад '''[[Что такое - хорошая интеграция (Saint Highload-2021)]]''', этот доклад отличается фокусом на устойчивости и тестировании.
 
Пока видео нет, можно смотреть доклад '''[[Что такое - хорошая интеграция (Saint Highload-2021)]]''', этот доклад отличается фокусом на устойчивости и тестировании.
  
Из вопросов после доклада я понял, что тема будет иметь продолжение, потому что есть ряд актуальных вопросов, о которых я почему-то забыл при подготовке. ФИксирую их здесь, чтобы не забыть.  
+
Из вопросов после доклада я понял, что тема будет иметь продолжение, потому что есть ряд актуальных вопросов, о которых я почему-то забыл при подготовке. Фиксирую их здесь, чтобы не забыть.  
 
* Организационные вопросы обеспечения устойчивости — взаимодействие со смежными командами и заказчиками, создание тестовых стендов, особенно актуальное в ситуации, когда «после релизов все разваливается» (это — цитата из вопроса).  
 
* Организационные вопросы обеспечения устойчивости — взаимодействие со смежными командами и заказчиками, создание тестовых стендов, особенно актуальное в ситуации, когда «после релизов все разваливается» (это — цитата из вопроса).  
 
* Смежные с предыдущим вопросы создания mock-объектов, особенно актуальные при отсутствии полноценных интеграционных стендов: технически оно более-менее понятно, но кто несет ответственность, как обеспечить своевременность изменения mock-библиотек при изменениях протоколов. Этих вопросов я немного касался на слайде про тестирование интеграции под нагрузкой, но явно недостаточно.  
 
* Смежные с предыдущим вопросы создания mock-объектов, особенно актуальные при отсутствии полноценных интеграционных стендов: технически оно более-менее понятно, но кто несет ответственность, как обеспечить своевременность изменения mock-библиотек при изменениях протоколов. Этих вопросов я немного касался на слайде про тестирование интеграции под нагрузкой, но явно недостаточно.  
Строка 16: Строка 16:
 
* Подробнее рассмотреть эффекты многопоточной обработки — перестановку порядка транзакций и псевдопотери, когда транзакции пошли в разные потоки и обработка идет одновременно, а не последовательно.  
 
* Подробнее рассмотреть эффекты многопоточной обработки — перестановку порядка транзакций и псевдопотери, когда транзакции пошли в разные потоки и обработка идет одновременно, а не последовательно.  
 
По всем вопросам у меня тут точно есть опыт, другой вопрос — получится ли его показать с ясными примерами. Будем работать.
 
По всем вопросам у меня тут точно есть опыт, другой вопрос — получится ли его показать с ясными примерами. Будем работать.
 +
 +
= Видео =
 +
 +
{{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»

Презентация

Скачать весь pdf
Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf Integration-SQA-2025a-Tsepkov.pdf