Рекомендации по проектированию стратегии тестирования надежности

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

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

Определения

Основные стратегии проектирования

Проверка готовности к надежности

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

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

• Внедрение подхода к тестированию влево с сменой влево для выполнения тестирования устойчивости и доступности в начале цикла разработки.

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

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

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

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

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

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

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

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

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

• Проверьте план аварийного восстановления для реагирования на катастрофические сбои и другие крупные инциденты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Начните с гипотезы. Каждый эксперимент должен иметь четкую цель, например тестирование способности данного потока противостоять потере определенного компонента.
2. Измерьте базовые показатели поведения. Убедитесь, что у вас есть согласованные метрики надежности и производительности для потока и компонентов, участвующих в данном эксперименте, чтобы сравниться с состоянием снижения производительности при выполнении эксперимента.
3. Внедрите одну или несколько ошибок. Эксперимент должен намеренно нацеливать определенные компоненты, которые можно быстро восстановить, и вы должны иметь информированное ожидание эффекта, что внедрение сбоя приведет к контролю радиуса взрыва эксперимента.
4. Проследите за изменившимся поведением. Соберите данные телеметрии о отдельных компонентах потока и поведении сквозного потока, которые эксперимент предназначен для правильного понимания последствий сбоя. Сравните метрики, собранные с базовыми метриками, для полной картины результатов внедрения ошибок.
5. Задокументируйте процесс и наблюдения. Сохранение подробных записей экспериментов будет информировать будущие решения о проектировании рабочей нагрузки, обеспечивая устранение пробелов, которые были выявлены с течением времени.
6. Определите результаты и примите меры. Запланируйте шаги по исправлению, которые можно добавить в невыполненную работу рабочей нагрузки в качестве улучшений. Убедитесь, что планы улучшения проектирования проверяются и тестируются в непроизводственных средах в соответствии с теми же процессами, что и другие развертывания.

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

При проведении экспериментов по внедрению ошибок вы:

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

Интеграция следующих рекомендаций и рекомендаций для оптимизации стратегии тестирования хаоса:

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

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

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

• Создайте бюджет ошибок для хаос-инжиниринга и внедрения сбоев. Ваш бюджет ошибок заключается в разнице между достижением 100 процентов SLO и достижением согласованного SLO.

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

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

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

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

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

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

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

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

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

Дополнительные ссылки

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

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

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