Стратегии архитектуры для разработки стратегии тестирования надежности

Применяется к этой рекомендации проверки надежности платформы Azure Well-Architected Framework:

Тестирование надежности перехватывает архитектурные недостатки, прежде чем они вызывают сбои. Без целенаправленного тестирования на сценариях отказа невозможно понять, действительно ли работают ваши паттерны отказоустойчивости и восстанавливается ли ваша рабочая нагрузка в пределах заданных целевых показателей.

Вы повышаете надежность рабочей нагрузки при тестировании рисков безопасности, влияющих на доступность, проблемы с производительностью, которые делают систему непригодными для использования и операционными пробелами, ограничивающими реагирование на инциденты. Используйте стратегии, приведенные в этой статье, чтобы установить периодичность тестирования, которая регулярно проверяет рабочую нагрузку в режиме сбоя. Развивайте тесты по мере изменения архитектуры и инцидентов, чтобы выявить новые слабые места. Будьте уверены, что ваша рабочая нагрузка способна выдерживать сбои, масштабироваться в соответствии со спросом и восстанавливаться в пределах целевых показателей RTO и RPO, создавая при этом цикл обратной связи, который со временем укрепляет ваш подход к обеспечению надежности.

Основные стратегии, описанные в этой статье, опирались на базовые методики тестирования, описанные в стратегиях архитектуры OE:09 для тестирования. Сначала ознакомьтесь с этой статьей. Рекомендации, приведенные в этом руководстве, ограничены вопросами надежности и направлены на обеспечение уверенности в способности вашей рабочей нагрузки выдерживать сбои и восстанавливаться в пределах целевых показателей.

В следующей таблице определены ключевые термины надежности, используемые в этой статье.

Определения

Определение области тестирования надежности на основе типов служб

При определении области тестирования надежности рассмотрите модель общей ответственности используемых служб. Каждый тип службы (IaaS, PaaS, SaaS) поставляется с различными гарантиями надежности и разными уровнями контроля за обработкой сбоев. Сосредоточьтесь на тестировании тех аспектов надежности, за которые вы отвечаете.

• Соотносите глубину тестирования с зоной вашей ответственности. Для инфраструктурных сервисов (IaaS) ваша команда отвечает за большинство решений, связанных с надежностью, поэтому уделяйте особое внимание тщательной проверке с помощью хаос-инжиниринга и инъекции отказов. Для служб платформы (PaaS) и программного обеспечения (SaaS) поставщик управляет большой частью базовой надежности. Уделите внимание тому, как ваша рабочая нагрузка взаимодействует с этими службами, например, как она обрабатывает переключение при отказе инфраструктуры в PaaS, троттлинг, снижение производительности службы или изменения характера нагрузки.

• Учитывайте рабочие нагрузки смешанных служб. Если рабочая нагрузка охватывает несколько типов служб, обязанности тестирования зависят от компонентов. Вы можете протестировать отработку отказа компонентов инфраструктуры на основе виртуальных машин во время сбоя зоны доступности, но полагаться на гарантии поставщика для базы данных PaaS, предназначенной для обеспечения высокой доступности. Определите, где эти границы находятся, и убедитесь, что тестирование охватывает пробелы между ними.

Проверяйте соответствие целевым показателям надежности на всех этапах

Ваши целевые показатели надежности, такие как SLOs, RTOs и RPOs, определяют, как ваша рабочая нагрузка должна вести себя в условиях отказа. Используйте их как критерии успешного и неуспешного прохождения во всех критически важных сквозных сценариях, а не только для отдельных компонентов.

• Проверьте восстановление на всём протяжении процесса. Отдельный компонент может восстановиться в пределах своего RTO, но общее время восстановления может превысить целевое значение, если зависимые нижестоящие компоненты также требуют восстановления. Учитывать общее время восстановления по всему процессу, включая время, необходимое для обнаружения проблемы и реагирования на неё.

• Определите область тестирования с помощью уровней обслуживания и бюджетов ошибок. Бюджет ошибок представляет инвестиции, которые можно внести в внедрение ошибок. Ограничьте chaos-тестирование, чтобы оставаться в пределах ваших SLO, и используйте целевые показатели восстановления потока, чтобы определить границы каждого теста.

Создание сценариев надежности из критических потоков и режимов сбоев

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

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

Проверка механизмов отказоустойчивости и восстановления

Сосредоточьтесь на сценариях, которые, скорее всего, вызывают простой или ухудшают взаимодействие с пользователем. Используйте стратегии, приведенные в этом разделе, для создания тестов, которые проверяют способность рабочей нагрузки обрабатывать ошибки и эффективно восстанавливаться.

Резервное копирование и восстановление

Тестирование резервного копирования и восстановления должно проверить, соответствует ли подход защиты данных вашим целям восстановления.

• Определите регулярность тестирования. Определите частоту тестирования восстановления на основе частоты изменения конфигурации резервного копирования, схемы данных или инфраструктуры. Чем чаще происходят изменения, тем чаще требуется тестирование восстановления.

• Задайте целевые объекты восстановления. Измеряйте фактическое время восстановления по целевым объектам RPO и RTO, чтобы убедиться, что стратегия резервного копирования соответствует вашим целям восстановления.

• Не предполагайте полноту резервного копирования. Резервные копии могут быть неправильно настроены для записи только подмножества данных. Проверьте целостность и полноту данных, а не только успешность операции восстановления.

• Тестирование в изоляции. Проверьте восстановление в среде, отдельной от рабочей среды, чтобы можно было выполнять тщательные проверки без прерывания рабочих нагрузок в реальном времени.

Временные сбои

Временные сбои, такие как временные сетевые прерывания, кратковременная недоступность службы и время ожидания подключения, являются общими рисками надежности. Убедитесь, что рабочая нагрузка обрабатывает эти сбои без влияния на пользователей. Дополнительные сведения см. в Рекомендациях по обработке временных сбоев.

• Сосредоточьтесь на том, что вы владеете. Если ваши SDK или службы платформы автоматически обрабатывают повторные попытки и размыкание цепи, проверьте, что происходит, когда возможности этих встроенных механизмов исчерпаны, например когда все повторные попытки завершаются неудачей или происходит размыкание цепи.

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

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

• Учитывайте кратковременные сбои, вызванные механизмами отказоустойчивости. Зональная избыточность и аналогичные архитектуры часто приводят к кратковременным сбоям во время штатных операций переключения при отказе. Например, база данных с избыточностью между зонами может привести к временным сбоям подключения при перемещении трафика в здоровую зону во время сбоя. Проверьте, может ли рабочая нагрузка обрабатывать ожидаемые временные ошибки без значительного влияния пользователя.

Реакция на нагрузку и масштабирование

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

• Проверьте как горизонтальное масштабирование, так и обратное масштабирование. Убедитесь, что новая емкость поставляется в Сети достаточно быстро и что масштабирование не удаляет запросы или не оставляет потерянные ресурсы.

• Учитывайте задержку масштабирования. Всегда существует задержка между выполнением условий для активации масштабирования и подготовки новой емкости. Определите, может ли рабочая нагрузка обрабатывать спрос во время этого разрыва или необходимо ли предварительно подготовить дополнительную емкость.

Сбои зависимостей

Ваша рабочая нагрузка, скорее всего, зависит от служб за пределами прямого управления, таких как сторонние API, управляемые службы платформы или общие внутренние службы. Убедитесь, что рабочая нагрузка обрабатывает сбои в этих зависимостях без значительных нарушений работы пользователей.

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

• Проверьте резервное поведение для каждой зависимости. Когда зависимость становится недоступной, рабочая нагрузка должна переключаться на альтернативный сценарий или режим работы, а не приводить к полному отказу. Убедитесь, что каждый резервный механизм срабатывает корректно и что несвязанная функциональность продолжает работать.

• Учет частичных и каскадных сбоев. Зависимости редко дают сбой по принципу «да/нет». Не ограничивайтесь тестированием только полных отказов. Учитывайте рост задержек, периодически возникающие ошибки и частичную доступность данных.

• Проверьте изоляцию и локализацию радиуса поражения. Убедитесь, что сбой одной зависимости не приводит к каскадному отказу несвязанной функциональности.

Самосохранение и восстановление

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

• Протестируйте автоматическое восстановление от начала до конца. Оцените модели проверки работоспособности, чтобы убедиться, что они включают необходимые проверки. Убедитесь, что эти проверки обнаруживают ошибки точно, активируют автоматическое исправление, как ожидалось, и возвращают систему в работоспособное состояние в допустимые сроки.

• Проверьте инструкции по восстановлению вручную. Автоматическое восстановление не будет охватывать каждый сценарий. Протестируйте модули Runbook вручную в реалистичных условиях, чтобы убедиться, что операторы могут выполнять их под давлением и в течение целевых показателей времени восстановления.

• Проверьте поведение системы при постепенной деградации. Если один из компонентов выходит из строя, ваша рабочая нагрузка должна продолжать работать, пусть и с ограниченной функциональностью, а не полностью отказывать. Проверьте, что система может работать в ограниченном режиме, например помещать запросы в очередь на ручную проверку, и что такое ухудшение пользовательского опыта приемлемо для пользователей. Убедитесь, что ваша команда знает, как работать с рабочей нагрузкой в этом состоянии и как восстановить полную функциональность.

Инциденты и аварийное восстановление (DR)

При возникновении инцидента или аварии ваша способность быстро обнаруживать ее и эффективно реагировать на них имеет решающее значение. Протестируйте планы и процессы, чтобы убедиться, что они устраняют катастрофические сбои и крупные инциденты. Используйте выделенную среду для тестирования DR, чтобы не затрагивать производственные нагрузки. Дополнительные сведения см. в плане аварийного восстановления.

• Проверьте механизмы обнаружения инцидентов. Имитируйте инциденты, чтобы убедиться, что журналы мониторинга фиксируют необходимую информацию и активируют оповещения соответствующим образом. Например, проверьте, как быстро обнаруживается увеличение частоты сбоев запросов и как часто выполняется выборка данных мониторинга.

• Тестирование процессов управления инцидентами. Убедитесь, что ваша команда может эффективно следовать процедурам реагирования на инциденты. Дополнительные сведения см. в статье об реагировании на инциденты.

• Проверьте полное переключение при отказе и обратное переключение. Тестирование отдельных компонентов по отдельности может не выявить сбои координации, которые проявляются только во время фактического переключения. Проверьте полный сценарий аварийного переключения, включая переключение DNS, восстановление из резервных копий, согласованность репликации данных и повторное подключение клиентов. Также протестируйте обратное переключение на основное развертывание, которое часто оказывается более сложным, чем первоначальное переключение.

• Проверьте доступную мощность в среде аварийного переключения. Убедитесь, что в вашей среде аварийного переключения имеется достаточный объем заранее подготовленных ресурсов, чтобы сразу принять трафик при аварийном переключении и не выйти из строя под нагрузкой. Проверьте, что среда может поддерживать операции во время активации механизмов масштабирования и проверки подхода к масштабированию. Дополнительные сведения см. в разделе "Загрузка и масштабирование ответа".

• Сравните результаты с целевыми показателями. Если тест аварийного восстановления не позволяет достичь целевых показателей RTO или RPO, проанализируйте выявленные несоответствия и соответствующим образом обновите план аварийного восстановления.

• Проверьте людей и процесс. Тестирование аварийного восстановления должно включать проверку каналов связи, подтверждение того, что у операторов есть необходимый доступ и права для выполнения процедур восстановления, а также обеспечивать возможность быстро находить инструкции (runbooks) по аварийному восстановлению в стрессовой ситуации.

Тестируйте и оценивайте ваш план с помощью настольных учений

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

• Имитация реалистичных инцидентов. Просмотрите сценарий сбоя, например региональный сбой или поврежденное развертывание, и укажите команде шаги, которые они будут предпринять для обнаружения, реагирования и восстановления от него. Эти обсуждения часто показывают предположения о поведении системы, которые не были проверены с помощью тестирования.

• Превратите результаты в тестовые случаи. Используйте пробелы и неизвестные факторы, которые выявляются в ходе упражнения, чтобы разработать новые тесты на надежность. Если команда обнаруживает, что никто не знает, как работает рабочая нагрузка при сбое определенной зависимости, это сценарий для добавления в стратегию тестирования.

Воспользуйтесь преимуществами запланированных и незапланированных сбоев

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

Плановое техническое обслуживание

Во время окон технического обслуживания для установки обновлений или исправлений тестируйте компоненты и потоки, которые не задействованы в работах по обслуживанию. Вы можете выполнять тесты без риска неожиданного снижения рабочей нагрузки или отключать его в автономном режиме. Если у вас достаточно времени, также проверьте компоненты, участвующие в обслуживании после завершения работы.

Незапланированный сбой

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

• Проверьте меры по устранению рисков. Если вы применили временное решение или временное исправление, убедитесь, что они способны выдержать ожидаемую нагрузку до внедрения постоянного исправления.

• Сканирование аналогичных слабых мест. Проверьте другие компоненты на предмет аналогичной конфигурации или шаблонов проектирования, которые привели к сбою. Добавьте тесты для этих компонентов до того, как они начнут отказывать таким же образом.

Объединение различных типов тестов

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

• Повторное использование существующей тестовой инфраструктуры. Если у вас уже есть инфраструктура и тестовый стенд для нагрузочного тестирования, используйте их, чтобы одновременно запускать хаос-тесты. Объединение нагрузочного тестирования и инъекции сбоев в рамках одного тестового запуска позволяет увидеть, как ведёт себя ваша рабочая нагрузка в реальных условиях, когда нагрузка и сбои возникают одновременно.

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

Использование внедрения ошибок и инженерии хаоса

Внедрение ошибок и инженерия хаоса помогут вам обеспечить уверенность в устойчивости рабочей нагрузки, намеренно введя сбои и наблюдая за ответом. Перед выполнением экспериментов убедитесь, что у вас есть стратегии устранения рисков.

• Регулярно выполняйте эксперименты хаоса. Оцените область тестирования. Внедрение ошибок в компоненты и потоки, которые предполагается, являются надежными. По мере изменения архитектуры возникают новые сценарии отказа, а прежние допущения могут больше не быть верными. Запустите эксперименты по регулярной частоте для перехвата регрессий, проверки новых зависимостей и подтверждения того, что последние изменения не ввели слабые места.

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

• Ограничьте масштаб возможных последствий во время экспериментов. Целевые компоненты можно быстро восстановить и задать обоснованные ожидания о влиянии каждого внедрения сбоя. Если эксперимент выходит за рамки или выдает непредвиденные результаты, остановите его. Балансируйте сбор значимых данных с минимизацией влияния на пользователей.

• Оценивать по базовым показателям. Установите согласованные метрики надежности и производительности для потоков и компонентов в каждом эксперименте. Сравните метрики пониженного состояния с этими базовыми показателями, чтобы понять полный эффект сбоя и определить, соответствует ли структура устойчивости своим целям.

• Используйте результаты для корректировки стратегии тестирования. Используйте результаты эксперимента для разработки новых тестов, обновления планов восстановления и уточнения элементов бэклога по устранению проблем. По мере возникновения непредвиденных действий создайте целевые тесты для этих действий и стратегий устранения неполадок.

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

Риск: Тестирование надежности может расширить охват множества режимов отказа, но его следует прекратить, как только оно перестанет приносить существенную пользу. Если у вас уже есть список известных проблем с надежностью, в первую очередь устраните их вместо того, чтобы добавлять новые тесты.

Упрощение функций Azure

Планы тестирования Azure — это решение для управления тестами на основе браузера, которое предоставляет все возможности, необходимые для запланированного ручного тестирования, проверки принятия пользователей, исследования тестирования и получения отзывов от заинтересованных лиц.

Azure Chaos Studio — это управляемая служба, которая использует хаос-тестирование для измерения, понимания и повышения устойчивости облачных приложений и служб.

Azure App Testing — это служба, которая позволяет выполнять функциональные тесты с Playwright Workspaces и тестами производительности с помощью Нагрузочное тестирование Azure для выявления проблем в своих приложениях.

Работоспособность служб Azure имеет область планового обслуживания, которая является выделенным разделом на портале Azure, который позволяет получать сведения о предстоящих действиях по обслуживанию. Он выделяет события, которые могут повлиять на Azure ресурсы, помогая заранее подготовиться.

Монитор подключений — это функция Наблюдателя за сетями Azure , которую можно использовать для искусственного мониторинга и тестирования сетевых подключений в гибридных средах Azure. В сценариях проектирования хаоса монитор подключений можно использовать для внедрения сбоев в целевые сетевые компоненты и непрерывно измерять ключевые метрики, такие как задержка и потеря пакетов. Эта возможность позволяет командам наблюдать, как нарушения влияют на надежность сети, как для отдельных компонентов потока, так и для сквозных сетевых путей. Чтобы оценить влияние сбоев и определить области для улучшения, сравните данные телеметрии монитора подключения с базовыми метриками.

Связанные ссылки

• резервное копирование и аварийное восстановление для приложений Azure
• Контрольный список для тестирования надежности
• тестовые приложения для обеспечения доступности и устойчивости

Контрольный список надежности

Ознакомьтесь с полным набором рекомендаций.