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

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

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

определения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Плановое обслуживание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Установить бюджет ошибок как инвестицию в управление рисками и имитацию ошибок. Ваш бюджет ошибок — это разница между достижением 100 процентов целевого уровня обслуживания (SLO) и достижением согласованного SLO.

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

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

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

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

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

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

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

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

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

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

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

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

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