Рекомендации по проектированию стратегии тестирования надежности
Применяется к этой рекомендации проверки надежности платформы Azure Well-Architected Framework:
| RE:08 | Протестируйте сценарии устойчивости и доступности, применяя принципы проектирования хаоса в тестовых и рабочих средах. Используйте тестирование, чтобы обеспечить эффективную реализацию и масштабирование стратегий снижения производительности, выполняя активные неисправные и имитированные нагрузочные тесты. |
|---|
В этом руководстве описаны рекомендации по проектированию стратегии тестирования надежности для проверки и оптимизации надежности рабочей нагрузки. Тестирование надежности ориентировано на устойчивость и доступность рабочей нагрузки, в частности критически важные потоки, которые вы определяете при разработке решения. В этом руководстве приведены общие рекомендации по тестированию и рекомендации, относящиеся к внедрению ошибок и проектированию хаоса.
Определения
| Термин | Определение |
|---|---|
| Availability | Время выполнения рабочей нагрузки приложения в работоспособном состоянии без значительного простоя. |
| Хаотическая разработка | Практика предоставления приложений и служб реальному миру стрессов и сбоев. Цель инженерии хаоса заключается в создании и проверке устойчивости к ненадежным условиям и отсутствием зависимостей. |
| Внедрение ошибок | Акт введения ошибки в систему для проверки устойчивости системы. |
| Возможность восстановления | Синоним устойчивости. |
| Устойчивость | Способность рабочей нагрузки приложения выдержать и восстановиться из режимов сбоя. |
Основные стратегии проектирования
Проверка готовности к надежности
Регулярно выполняйте тестирование для проверки существующих пороговых значений, целевых объектов и допущений. Когда в рабочей нагрузке происходит основное изменение, выполните регулярное тестирование. Выполнение большинства тестов в средах тестирования и промежуточного хранения. Также полезно выполнить подмножество тестов в рабочей системе. Запланируйте одно-одно четность ключевых тестовых сред с рабочей средой.
Автоматизация тестирования, чтобы обеспечить согласованное покрытие тестов и воспроизводимость. Автоматизируйте часто выполняемые задачи тестирования и интегрируйте их в процессы создания. Тестирование программного обеспечения вручную мучено и подвержено ошибке, но вы можете проводить ручное исследование. В случаях, когда необходимо разработать автоматическое тестирование, используйте ручное тестирование, чтобы определить область разработки тестов.
Внедрение подхода к тестированию влево с сменой влево для выполнения тестирования устойчивости и доступности в начале цикла разработки.
Адаптируйте простой формат документации, поэтому все легко понять процесс и результаты каждого регулярного теста.
Поделитесь документированных результатами с соответствующими командами, такими как операционные группы, руководство по технологиям, заинтересованные лица бизнеса и заинтересованные лица по аварийному восстановлению. Результаты должны информировать о уточнении целевых показателей надежности, таких как цели уровня обслуживания (SLOS), соглашения об уровне обслуживания (SLA), цели времени восстановления (ОСРВ) и цели точек восстановления (RPOS).
Создайте регулярный курс тестирования для резервных копий. Восстановите данные в изолированных системах, чтобы убедиться, что резервные копии являются допустимыми и что восстановление работает.
Задокументируйте и поделитесь метриками времени восстановления с заинтересованными лицами аварийного восстановления, чтобы убедиться, что ожидания восстановления соответствуют требованиям.
Используйте стандартные процедуры тестирования развертывания в отрасли, чтобы обеспечить автоматизированный, предсказуемый и эффективный процесс развертывания.
Проверьте способность рабочей нагрузки противостоять временным сбоям. Дополнительные сведения см. в рекомендациях по обработке временных сбоев.
Проверьте возможность рабочей нагрузки реагировать на изменения шаблонов нагрузки и пиков использования. Используйте эти сведения, чтобы проверить стратегию масштабирования. Сведения о нагрузочном и стресс-тестировании см . в рекомендациях по тестированию.
Проверьте, как рабочая нагрузка обрабатывает сбои в зависимых службах или других зависимостях с помощью внедрения ошибок.
Проверьте и проверьте, как ваша конструкция самовосстановления и самосохранения реагирует на неисправности. Тестирование автоматических и ручных операций восстановления.
Проверьте план аварийного восстановления для реагирования на катастрофические сбои и другие крупные инциденты.
Проверьте возможность снижения производительности рабочей нагрузки и свести к минимуму радиус взрыва неисправности компонента с помощью внедрения ошибок.
Воспользуйтесь преимуществами запланированных и незапланированных сбоев
Если рабочая нагрузка находится в автономном режиме из-за планового обслуживания или незапланированного сбоя, у вас есть уникальная возможность выполнять тестирование и улучшить понимание рабочей нагрузки. В следующих разделах приведены рекомендации по каждому сценарию.
Плановое техническое обслуживание
При планировании периодов обслуживания для обновлений или исправлений можно протестировать компоненты и потоки, которые не участвуют в работе по обслуживанию. Выполняйте тесты без потенциального риска неожиданного ухудшения рабочей нагрузки или его отключения в автономном режиме. Если у вас достаточно времени во время периода обслуживания, можно также протестировать компоненты и потоки, участвующие в обслуживании после завершения работы по обслуживанию.
Незапланированный сбой
Используйте каждый инцидент сбоя в качестве возможности узнать больше о рабочей нагрузке и повысить ее устойчивость, выполнив следующие действия, упорядоченные по приоритету:
Получите рабочую нагрузку в сети для клиентов. Для этого можно выполнить обходное решение проблемы, устранить проблему или инициировать процессы восстановления.
Определите первопричину сбоя и устранить ее. Если вы можете исправить первопричину в рамках исследования, задокументируйте первопричину и принятые меры. Если проблема требует дополнительного периода обслуживания в дальнейшем, убедитесь, что меры по устранению рисков могут обрабатывать ожидаемую нагрузку путем тщательного тестирования. Убедитесь, что вы настроили достаточный мониторинг для покрытия мер по устранению рисков.
Если применимо, найдите одну и ту же проблему или слабые места конфигурации, которые могут повлиять на аналогичные проблемы во всех компонентах рабочей нагрузки. Используйте эту возможность для упреждающего решения этих компонентов. Обратитесь к журналу инцидентов, чтобы обнаружить шаблоны аналогичных проблем в рабочей нагрузке.
Используйте ваши выводы для улучшения стратегии тестирования. Убедитесь, что вы успешно выполнили первопричину и аналогичные проблемы, непосредственно проверив тот же сбой.
Использование внедрения ошибок и инженерии хаоса
Тестирование на внедрение ошибок следует принципам проектирования хаоса, подчеркивая способность рабочей нагрузки реагировать на сбои компонентов. Выполните тестирование при внедрении ошибок в предварительной среде и рабочей среде. Применение тестирования к уровням инфраструктуры и приложений. Примените сведения, которые вы узнали о рекомендациях по выполнению анализа режима сбоя, чтобы убедиться, что тестируются только ошибки, которые вы задаете приоритеты, и у вас есть стратегии устранения ошибок, которые устраняют ошибки. Ключевыми принципами проектирования хаоса являются:
Действуйте на упреждение. Не подождите, пока не произойдет сбой. Попробуйте предвидеть сбои путем проведения экспериментов хаоса для обнаружения и устранения проблем, прежде чем они влияют на рабочую среду.
Принимайте возможность сбоев. Примите и изучите ошибки, возникающие в вашей системе. Ознакомьтесь с ошибками как естественной частью сложных систем и используйте их в качестве возможностей для изучения и улучшения надежности системы.
Ломайте систему. Намеренно внедряйте ошибки или стресс в систему, чтобы проверить ее устойчивость. Имитация реальных сбоев или сбоев для тестирования и улучшения возможностей восстановления рабочей нагрузки.
Выявляйте и устраняйте единые точки отказа на ранних этапах. При тестировании обратитесь к анализу режима сбоя и обновите его , чтобы проверить и устранить ошибки в документации. Применение подходов к надежности, таких как избыточность и сегментация, для повышения доступности рабочей нагрузки и минимизации простоя.
Устанавливайте ограждения и постепенное устранение. Реализуйте меры безопасности, такие как шаблон разбиения цепи или шаблон регулирования, чтобы повысить доступность. Реализуйте подходы к корректному снижению производительности, позволяющие обеспечить непрерывность бизнес-процессов во время сбоев.
Уменьшите радиус воздействия. Реализуйте стратегии изоляции сбоя, чтобы обеспечить, даже если произошел сбой, его область ограничена. Система продолжает функционировать с минимальным воздействием на клиентов.
Укрепляйте невосприимчивость. Используйте эксперименты по проектированию хаоса, чтобы улучшить способность рабочей нагрузки предотвращать и восстанавливаться от сбоев.
Проектирование хаоса является неотъемлемой частью культуры рабочей нагрузки и текущей практики, а не краткосрочными тактическими усилиями в ответ на один сбой. Следуйте этому стандартному методу при разработке экспериментов хаоса:
- Начните с гипотезы. Каждый эксперимент должен иметь четкую цель, например тестирование способности данного потока противостоять потере определенного компонента.
- Измерьте базовые показатели поведения. Убедитесь, что у вас есть согласованные метрики надежности и производительности для потока и компонентов, участвующих в данном эксперименте, чтобы сравниться с состоянием снижения производительности при выполнении эксперимента.
- Внедрите одну или несколько ошибок. Эксперимент должен намеренно нацеливать определенные компоненты, которые можно быстро восстановить, и вы должны иметь информированное ожидание эффекта, что внедрение сбоя приведет к контролю радиуса взрыва эксперимента.
- Проследите за изменившимся поведением. Соберите данные телеметрии о отдельных компонентах потока и поведении сквозного потока, которые эксперимент предназначен для правильного понимания последствий сбоя. Сравните метрики, собранные с базовыми метриками, для полной картины результатов внедрения ошибок.
- Задокументируйте процесс и наблюдения. Сохранение подробных записей экспериментов будет информировать будущие решения о проектировании рабочей нагрузки, обеспечивая устранение пробелов, которые были выявлены с течением времени.
- Определите результаты и примите меры. Запланируйте шаги по исправлению, которые можно добавить в невыполненную работу рабочей нагрузки в качестве улучшений. Убедитесь, что планы улучшения проектирования проверяются и тестируются в непроизводственных средах в соответствии с теми же процессами, что и другие развертывания.
Периодически проверяйте процесс, выбор архитектуры и код для быстрого обнаружения технического долга, интеграции новых технологий и адаптации к изменяющимся требованиям.
При проведении экспериментов по внедрению ошибок вы:
- Убедитесь, что мониторинг установлен и настроены оповещения.
- Проверьте процесс назначения непосредственно ответственного человека (DRI), чтобы взять на себя ответственность за инцидент.
- Убедитесь, что ваши процессы документации и исследования актуальны.
Интеграция следующих рекомендаций и рекомендаций для оптимизации стратегии тестирования хаоса:
Ставьте под сомнения предположения о системе. При тестировании вы пытаетесь повысить устойчивость рабочей нагрузки и стратегии проектирования рабочей нагрузки. Ищите возможности внедрения ошибок в компоненты и потоки, которые вы предполагаете, являются надежными на основе прошлых опытов. Они могут быть ненадежными в новой рабочей нагрузке.
Проверьте изменение, например топологию, платформу и ресурсы. Без тщательного тестирования, включая тестирование на внедрение ошибок, возможно, у вас может быть неполное представление о рабочей нагрузке после внесения изменений. Например, вы можете непреднамеренно вводить новые зависимости или разбить существующие зависимости способами, которые не сразу очевидны.
Используйте буферы SLA. Ограничьте тестирование хаоса, чтобы оставаться в пределах соглашений об уровне обслуживания и избегать потенциальных репутаций или финансовых последствий от сбоев. Целевые объекты восстановления потоков и компонентов помогают определить область тестирования.
Создайте бюджет ошибок для хаос-инжиниринга и внедрения сбоев. Ваш бюджет ошибок заключается в разнице между достижением 100 процентов SLO и достижением согласованного SLO.
Остановите эксперимент, если он выходит за рамки области. Неизвестные результаты — это ожидаемый итог экспериментов в рамках хаос-инжиниринга. Постарайтесь найти баланс, чтобы собрать важные данные, но при этом затронуть как можно меньше пользователей в рабочей среде.
Тесно сотрудничайте с командами разработчиков, чтобы обеспечить актуальность внедренных сбоев. Опирайтесь на прошлые инциденты или проблемы. Проверьте зависимости и оцените результаты при удалении этих зависимостей.
Определите и задокументируйте ранее необнаружаемые зависимости между различными компонентами в рабочей нагрузке, которые отображаются с помощью тестирования хаоса.
При необходимости настройте планы восстановления для учета зависимостей, обнаруженных во время тестирования хаоса.
Используйте результаты экспериментов и тестов в качестве основы для новых экспериментов и тестов. По мере возникновения непредвиденных действий новые тесты могут напрямую ориентироваться на эти действия и предоставлять вам возможность разрабатывать стратегии исправления для них.
Компромисс. Тестирование при внедрении сбоев в рабочей среде может быть нарушено и может привести к простою. Будьте прозрачны с заинтересованными лицами по этой возможности и убедитесь, что у вас есть гарантии для прекращения экспериментов и отката планов быстрого отмены ошибок, которые вы вводите. Чтобы защититься от непреднамеренных сбоев в рабочей среде, убедитесь, что вы планируете достаточное избыточность и что заинтересованные лица понимают компромисс затрат.
Упрощение функций Azure
Планы тестирования Azure — это простое решение для управления тестами на основе браузера, которое предоставляет все возможности, необходимые для планового ручного тестирования, проверки принятия пользователей, исследования тестирования и сбора отзывов заинтересованных лиц.
Azure Chaos Studio — это управляемая служба, которая использует инженерию хаоса для измерения, понимания и улучшения устойчивости облачных приложений и служб. Azure Chaos Studio достигла общедоступной доступности в Ignite 2023 и имеет множество функций, которые помогут вам приступить к внедрению ошибок и тестированию устойчивости для приложения с помощью инфраструктуры Azure.
Дополнительные ссылки
- Резервное копирование и аварийное восстановление для приложений Azure
- Контрольный список для проверки надежности
- Тестирование приложений для обеспечения доступности и устойчивости
Контрольный список надежности
Ознакомьтесь с полным набором рекомендаций.