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

  • Статья

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

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

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

Определения

Термин Определение
Доступность Время, в течение которого рабочая нагрузка приложения выполняется в работоспособном состоянии без значительного простоя.
Хаотическая разработка Практика, когда приложения и службы подвергаются реальным нагрузкам и сбоям. Целью проектирования хаоса является создание и проверка устойчивости к ненадежным условиям и отсутствующим зависимостям.
Внедрение ошибок Акт введения ошибки в систему для проверки устойчивости системы.
Возможность восстановления Синоним устойчивости.
Устойчивость Способность рабочей нагрузки приложения выдерживать и восстанавливаться после сбоев.

Ключевые стратегии проектирования

Общие рекомендации по тестированию

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Руководство по внедрению ошибок и инжинирингу хаоса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Упрощение поддержки Azure

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

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

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

См. полный набор рекомендаций.

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