Рекомендации по разработке стратегии тестирования надежности
Применимо к этой рекомендации Power Platform контрольного списка надежности, хорошо продуманной архитектуры:
| РЕ:06 | Протестируйте сценарии устойчивости и доступности, применяя принципы хаос-инжиниринга в тестовых и рабочих средах. Используйте тестирование, чтобы убедиться в эффективности стратегий постепенной деградации, выполняя активные сбои и моделируя нагрузочное тестирование. |
|---|
В этом руководстве описаны рекомендации по разработке стратегии тестирования надежности для проверки и оптимизации надежности вашей рабочей нагрузки. Тестирование надежности фокусируется на отказоустойчивости и доступности вашей рабочей нагрузки, особенно критических потоков, которые вы определяете при разработке решения. В этом руководстве представлены общие рекомендации по тестированию, а также рекомендации, относящиеся к внесению неисправностей и хаос-инжинирингу.
Определения
| Термин | Определение |
|---|---|
| Availability | Время, в течение которого рабочая нагрузка приложения работает в работоспособном состоянии без значительных простоев. |
| Хаос-инжениринг | Практика подвергания приложений и служб реальным стрессовым нагрузкам и сбоям. Цель хаос-инжиниринга — создать и подтвердить устойчивость к ненадежным условиям и отсутствующим зависимостям. |
| Внесение неисправностей | Внесение ошибки в систему для проверки ее устойчивости. |
| Способность к восстановлению | Синоним устойчивости. |
| Устойчивость | Способность рабочей нагрузки приложения противостоять режимам сбоя и восстанавливаться после них. |
Ключевые стратегии проектирования
Тестирование необходимо для обеспечения соответствия вашей рабочей нагрузки целевым показателям надежности и корректной обработки сбоев. Внесение неполадок — это тип тестирования, при котором намеренно вводятся неполадки или стресс в вашу систему для моделирования реальных сценариев. Используя методы внесения неполадок и хаос-инжиниринга, вы можете заранее обнаруживать и устранять проблемы до того, как они повлияют на вашу производственную среду. В этом разделе представлены общие рекомендации по тестированию, внесению неполадок и хаос-инжинирингу для вашей рабочей нагрузки.
Общее руководство по тестированию
Регулярно проводите тестирование для проверки существующих пороговых значений, целевых показателей и предположений. Если в вашей рабочей нагрузке происходят серьезные изменения, проводите регулярное тестирование. Выполняйте большую часть тестирования в тестовых и промежуточных средах. Также полезно провести подмножество тестов в производственной системе.
Автоматизируйте тестирование, чтобы обеспечить единообразный охват и воспроизводимость результатов тестирования. Автоматизируйте общие задачи тестирования и интегрируйте их в процессы сборки. Тестирование программного обеспечения вручную утомительно и подвержено ошибкам, но вы можете провести исследовательское тестирование вручную. В случаях, когда вам необходимо разработать автоматическое тестирование, используйте ручное тестирование, чтобы определить объем разрабатываемых тестов.
Используйте подход к тестированию со сдвигом влево, чтобы выполнить тестирование отказоустойчивости и доступности на ранних этапах цикла разработки.
Адаптируйте простой формат документации, чтобы каждый мог легко понять процесс и результаты каждого регулярного теста.
Поделитесь задокументированными результатами с соответствующими группами, такими как оперативные группы, технологическое руководство, заинтересованные стороны бизнеса и участники аварийного восстановления. Результаты должны служить основой для уточнения целевых показателей надежности, таких как целевые показатели уровня обслуживания (SLO), соглашения об уровне обслуживания (SLA), целевые показатели времени восстановления (RTO) и целевые точки восстановления (RPO).
Установите регулярную периодичность тестирования резервных копий. Восстановите данные в изолированных системах, чтобы гарантировать, что резервные копии действительны и восстановление работоспособно.
Документируйте и делитесь показателями времени восстановления с заинтересованными сторонами, связанными с аварийным восстановлением, чтобы гарантировать, что ожидания от восстановления соответствуют действительности.
Используйте стандартные процедуры тестирования развертывания, чтобы обеспечить автоматизированный, предсказуемый и эффективный процесс развертывания.
Проверьте способность вашей рабочей нагрузки противостоять временным сбоям. Дополнительные сведения см. в разделе Рекомендации по обработке временных неполадок.
Проверьте, как ваша рабочая нагрузка обрабатывает сбои в зависимых службах или других зависимостях, используя внесение неполадок.
Проверьте свой план по аварийному восстановлению для реагирования на катастрофические сбои и другие крупные инциденты.
Проверьте способность вашей рабочей нагрузки корректно снижать производительность и минимизировать радиус воздействия неисправности компонента с помощью внедрения ошибок.
Воспользуйтесь преимуществами плановых и внеплановых простоев
Если ваша рабочая нагрузка отключена из-за планового обслуживания или незапланированного простоя, у вас есть уникальная возможность провести тестирование и улучшить понимание своей рабочей нагрузки. В следующих разделах приведены рекомендации для каждого сценария.
Плановое техническое обслуживание
Если вы запланировали периоды обслуживания для обновлений или исправлений, вы можете протестировать компоненты и потоки, которые не участвуют в работах по обслуживанию. Выполняйте тесты без потенциального риска неожиданного ухудшения рабочей нагрузки или ее полного отключения. Если у вас есть достаточно времени во время окна обслуживания, вы также можете протестировать компоненты и потоки, участвующие в обслуживании, после завершения работ по техническому обслуживанию.
Незапланированное отключение
Используйте каждый инцидент сбоя как возможность узнать больше о своей рабочей нагрузке и повысить ее отказоустойчивость, выполнив следующие действия, упорядоченные по приоритету:
Верните рабочую нагрузку для своих пользователей в онлайн-режим. Возможно, вам потребуется обойти проблему, решить ее или запустить процессы восстановления.
Определите первопричину сбоя и устраните ее. Если вы можете устранить основную причину в рамках расследования, задокументируйте основную причину и меры, которые вы предприняли для ее устранения. Если для устранения проблемы потребуется повторное выполнение обслуживание позже, убедитесь, что ваши меры по смягчению последствий способны справиться с ожидаемой нагрузкой, тщательно протестировав их. Убедитесь, что вы настроили достаточный мониторинг для охвата ваших мер по смягчению последствий.
Если применимо, найдите такую же проблему или недостатки конфигурации, на которые могут повлиять аналогичные проблемы, во всех компонентах вашей рабочей нагрузки. Используйте эту возможность для активного усовершенствования этих компонентов. Просмотрите историю инцидентов, чтобы обнаружить закономерности возникновения подобных проблем в вашей рабочей нагрузке.
Используйте полученные результаты для улучшения стратегии тестирования. Убедитесь, что вы успешно устранили основную причину и подобные проблемы, непосредственно протестировав ту же ошибку.
Руководство по внедрению ошибок и хаос-инжинирингу
Тестирование с внесением ошибок следует принципам хаос-инжиниринга, подчеркивая способность рабочей нагрузки реагировать на сбои компонентов. Выполняйте тестирование с внесением ошибок в предпроизводственную и производственную среды. Примените информацию, которую вы узнали в результате выполнения анализа режима отказа, чтобы гарантировать, что вы тестируете только те ошибки, которые вы считаете приоритетными, и что у вас есть стратегии устранения ошибок, направленные на устранение ошибок.
Ключевые принципы хаос-инженеринга таковы:
Действуйте упреждающе. Не ждите, пока произойдут сбои. Постарайтесь предвидеть сбои, проводя эксперименты с хаосом, чтобы обнаруживать и устранять проблемы до того, как они повлияют на вашу производственную среду.
Примите сбой. Принимайте и извлекайте уроки из сбоев, которые происходят в вашей системе. Рассматривайте сбои как естественную часть сложных систем и используйте их как возможность изучить и повысить надежность вашей системы.
Сломайте систему. Намеренно вносите сбои или стресс в вашу систему, чтобы проверить ее устойчивость. Моделируйте реальные сбои или нарушения, чтобы протестировать и улучшить возможности восстановления вашей рабочей нагрузки.
Укрепите иммунитет. Используйте эксперименты по хаос-инжинирингу, чтобы улучшить способность вашей рабочей нагрузки предотвращать сбои и восстанавливаться после них.
Хаос-инжиниринг — это неотъемлемая часть культуры рабочей нагрузки и постоянной практики, а не краткосрочные тактические усилия в ответ на единичный сбой. Следуйте этому стандартному методу при планировании экспериментов с хаосом:
Начните с гипотезы. У каждого эксперимента должна быть четкая цель, например проверка способности потока противостоять потере определенного компонента.
Измерьте базовое поведение. Убедитесь, что у вас есть согласованные показатели надежности и производительности для потока и компонентов, участвующих в эксперименте, для сравнения с ухудшенным состоянием при проведении эксперимента.
Внесите ошибку или ошибки. Эксперимент должен быть намеренно нацелен на конкретные компоненты, которые можно быстро восстановить, и вы должны иметь обоснованное ожидание эффекта, который вызовет внедрение неисправности, чтобы помочь контролировать радиус поражения эксперимента.
Отслеживайте результирующее поведение. Соберите телеметрию об отдельных компонентах потока и сквозном поведении потока, на которые нацелен эксперимент, чтобы правильно понять последствия неисправности. Сравните собранные вами метрики с базовыми метриками, чтобы получить полную картину результатов внедрения ошибок.
Документируйте процесс и наблюдения. Ведение подробных записей ваших экспериментов поможет вам в будущем принимать решения о планировании рабочей нагрузки, гарантируя, что вы устраните пробелы, которые были выявлены с течением времени.
Определите и действуйте по результату. Запланируйте действия по исправлению, которые можно будет добавить в журнал невыполненной работы для рабочей нагрузки в качестве улучшений. Убедитесь, что планы улучшения дизайна проверяются и тестируются в непроизводственных средах в соответствии с теми же процессами, что и при других развертываниях.
Периодически проверяйте свой процесс, выбранную архитектуру и код, чтобы быстро выявлять технические недостатки, интегрировать новые технологии и адаптироваться к меняющимся требованиям.
Когда вы проводите эксперименты по внедрению ошибок, вы:
Убеждаетесь, что мониторинг установлен и оповещения настроены.
Проверяете свой процесс назначения непосредственно ответственного лица (DRI), которое возьмет на себя ответственность за инцидент.
Убеждаетесь, что ваша документация и процессы расследования актуальны.
Интегрируйте следующие рекомендации и соображения, чтобы оптимизировать свою стратегию тестирования в условиях хаоса:
Бросьте вызов системным предположениям. С помощью тестирования вы пытаетесь повысить отказоустойчивость вашей рабочей нагрузки и стратегии ее проектирования. Ищите возможности внести сбои в компоненты и потоки, которые, исходя из прошлого опыта, вы считаете надежными. Они могут оказаться ненадежными в вашей новой рабочей нагрузке.
Проверьте изменение. Без тщательного тестирования, включая тестирование с внесением ошибок, вы можете получить неполную картину вашей рабочей нагрузки после внесения изменений. Например, вы можете ввести новые зависимости, которые не сразу бросаются в глаза.
Используйте буферы SLA. Ограничьте тестирование в условиях хаоса, чтобы не выходить за рамки соглашений об уровне обслуживания и избежать потенциальных негативных последствий сбоев. Цели восстановления потока и компонентов помогают определить объем вашего тестирования.
Установите бюджет ошибок как инвестицию в хаос и внесение ошибок. Ваш бюджет ошибок — это разница между достижением 100 % SLO и достижением согласованного SLO.
Остановите эксперимент, если он выходит за рамки. Неизвестные результаты — ожидаемый результат экспериментов с хаосом. Стремитесь достичь баланса между сбором существенных данных о результатах и воздействием на как можно меньшее количество производственных пользователей.
Тесно работайте с командами разработчиков, чтобы обеспечить актуальность внедренных сбоев. Используйте прошлые инциденты или проблемы в качестве руководства. Изучите зависимости и оцените результаты после удаления этих зависимостей.
Выявляйте и документируйте ранее не обнаруженные зависимости между различными компонентами вашей рабочей нагрузки, выявленные в ходе хаос-тестирования.
При необходимости скорректируйте планы восстановления, чтобы учесть зависимости, обнаруженные во время тестирования в условиях хаоса.
Используйте результаты своих экспериментов и тестов в качестве основы для новых экспериментов и тестов. При возникновении непредвиденного поведения новые тесты могут быть нацелены непосредственно на это поведение и дать вам возможность разработать для него стратегии исправления.
Компромисс: Тестирование с использованием метода внесения неисправностей в производство может нарушить работу и потенциально привести к простою. Будьте откровенны с заинтересованными сторонами в отношении этой возможности и убедитесь, что у вас есть меры безопасности для прекращения экспериментов и планы отката, чтобы быстро исправить допущенные вами сбои.
Возможности в Power Platform
Вы можете использовать статические результаты, Power Automate чтобы вернуть фиксированный результат для тестирования рабочей нагрузки.
Power Apps Тестовый движок (предварительная версия) — это Power Platform компонент CLI, который можно использовать для тестирования автономных приложений Canvas в Power Apps.
Планы тестирования Azure — это простое в использовании решение для управления тестированием на основе браузера, которое предоставляет все возможности, необходимые для планового ручного тестирования, тестирования пользовательской приемки, исследовательского тестирования и сбора отзывов от заинтересованных сторон.
Если ваша рабочая нагрузка включает ресурсы Azure, вы можете использовать Azure Chaos Studio, управляемую службу, которая использует хаос-инженеринг, чтобы помочь вам измерить, понять и улучшить устойчивость ваших облачных приложений и служб.
Если ваша рабочая нагрузка включает в себя Microsoft Copilot Studio второй пилот, вы можете использовать Мощность CAT Copilot Studio Набор для настройки вторых пилотов и тестов. Проводя индивидуальные тесты против Copilot Studio API (Direct Line), ответы второго пилота оцениваются по отношению к ожидаемым результатам.
Контрольный список надежности
Обратитесь к полному набору рекомендаций.