Тестирование приложений Azure для обеспечения устойчивости и доступностиTesting Azure applications for resiliency and availability

Чтобы протестировать устойчивость, следует проверить, как рабочая нагрузка end-to-end выполняется в условиях Периодические сбои.To test resiliency, you should verify how the end-to-end workload performs under intermittent failure conditions.

Выполнение тестов в рабочей среде с помощью обоих синтетические и реальных пользовательских данных.Run tests in production using both synthetic and real user data. Тестирования и производственная среда редко идентичны, поэтому очень важно для проверки приложения в рабочей среде с помощью сине зеленый или раннее развертывание.Test and production are rarely identical, so it's important to validate your application in production using a blue-green or canary deployment. Таким образом, вы тестируете приложение в реальных условиях, поэтому можно быть уверенным, что она будет работать должным образом, когда полностью развернут.This way, you're testing the application under real conditions, so you can be sure that it will function as expected when fully deployed.

Как часть плана тестирования включают:As part of your test plan, include:

  • Автоматическое тестирование перед развертываниемAutomated predeployment testing
  • Тестирование посредством внесения ошибокFault injection testing
  • Нагрузочное тестирование (пик)Peak load testing
  • При проверке аварийного восстановленияDisaster recovery testing
  • Сторонняя служба тестированияThird-party service testing

Тестирование — это итеративный процесс.Testing is an iterative process. Протестируйте приложение, измерьте результат, проанализируйте и устраните все возникающие сбои и повторите процесс.Test the application, measure the outcome, analyze and address any failures that result, and repeat the process.

Выполните тестирование путем внедрения ошибкиPerform fault injection testing

Тестирование посредством внесения ошибок, проверьте отказоустойчивость системы во время сбоев либо путем инициирования фактических сбоев, либо путем их имитации.For fault injection testing, check the resiliency of the system during failures, either by triggering actual failures or by simulating them. Ниже приведены некоторые стратегии, позволяющие вызывать сбои.Here are some strategies to induce failures:

  • Завершение работы экземпляров виртуальной машины (VM).Shut down virtual machine (VM) instances.
  • прекращение работы процессов;Crash processes.
  • Завершите срок действия сертификатов.Expire certificates.
  • Измените ключи доступа.Change access keys.
  • Завершите работу службы DNS на контроллерах домена.Shut down the DNS service on domain controllers.
  • Ограничьте доступные системные ресурсы, такие как ОЗУ или количество потоков.Limit available system resources, such as RAM or number of threads.
  • Отключите диски.Unmount disks.
  • Повторно разверните виртуальную машину.Redeploy a VM.

План тестирования должно предусматривать возможных точек сбоя определены на этапе проектирования, помимо распространенных ошибок:Your test plan should incorporate possible failure points identified during the design phase, in addition to common failure scenarios:

  • Протестируйте приложение в среде, как можно ближе к рабочей среде, максимально.Test your application in an environment as close to production as possible.
  • Сбои при тестировании в сочетании.Test failures in combination.
  • Измерьте время восстановления и убедитесь, что ваши бизнес-требованиям.Measure the recovery times, and be sure that your business requirements are met.
  • Убедитесь, что сбои не каскадируются и обрабатываются изолированно.Verify that failures don't cascade and are handled in an isolated way.

Дополнительные сведения о сценарии сбоев, см. в разделе сбоя и аварийное восстановление для приложений Azure.For more information about failure scenarios, see Failure and disaster recovery for Azure applications.

Тестирование при пиковых нагрузкахTest under peak loads

Нагрузочное тестирование имеет решающее значение для обнаружения сбоев, которые происходят только под нагрузкой, таких как базы данных серверной части перегрузку или регулирования службы.Load testing is crucial for identifying failures that only happen under load, such as the back-end database being overwhelmed or service throttling. Тестирование для пиковой нагрузки и ожидаемое увеличение пиковой нагрузки, используя рабочие данные или искусственные данные, как можно ближе к рабочих данных максимально.Test for peak load and anticipated increase in peak load, using production data or synthetic data that is as close to production data as possible. Ваша цель состоит в том, как ведет себя приложение в реальных условиях.Your goal is to see how the application behaves under real-world conditions.

Проведение аварийного восстановленияConduct disaster recovery drills

Начните с хорошего плана аварийного восстановления и проверить его периодически, чтобы убедиться, что оно работает.Start with a good disaster recovery plan, and test it periodically to make sure it works.

Для виртуальных машин в Azure, можно использовать Azure Site Recovery для репликации и выполнить аварийного восстановления без влияния на рабочие приложения или текущую репликацию.For Azure Virtual Machines, you can use Azure Site Recovery to replicate and perform disaster recovery drills without affecting production applications or ongoing replication.

Отработка отказа и восстановления размещения тестированияFailover and failback testing

Тестирование отработки отказа и восстановления размещения, чтобы убедиться, что зависимые службы в приложении восстановят работу синхронизировано во время аварийного восстановления.Test failover and failback to verify that your application's dependent services come back up in a synchronized manner during disaster recovery. Изменения систем и операций могут повлиять на функции отработки отказа и восстановления размещения, но влияние может быть незамечен до сбой основной системы, или перегрузке.Changes to systems and operations may affect failover and failback functions, but the impact may not be detected until the main system fails or becomes overloaded. Тестирование отработки отказа перед они необходимы для компенсации за это реальной ошибкой.Test failover capabilities before they are required to compensate for a live problem. Кроме того, убедитесь, что зависимые службы отработка отказа и восстановление размещения в правильном порядке.Also be sure that dependent services fail over and fail back in the correct order.

Если вы используете Azure Site Recovery для репликации виртуальных машин, выполнять аварийное восстановление периодически, выполнив тестовую отработку отказа для проверки стратегии репликации.If you are using Azure Site Recovery to replicate VMs, run disaster recovery drills periodically by doing test failovers to validate your replication strategy. Тестовая отработка отказа не влияет на текущую репликацию виртуальных Машин или рабочую среду.A test failover does not affect the ongoing VM replication or your production environment. Дополнительные сведения см. в разделе выполнение отработки аварийного восстановления в Azure.For more information, see Run a disaster recovery drill to Azure.

Имитационное тестированиеSimulation testing

Имитационное тестирование подразумевает создание небольших, реальных ситуаций.Simulation testing involves creating small, real-life situations. Моделирование демонстрации эффективности решения в плане восстановления и выделить все проблемы, которые не были обработаны должным образом.Simulations demonstrate the effectiveness of the solutions in the recovery plan and highlight any issues that weren't adequately addressed.

При выполнении имитационное тестирование, следуйте рекомендациям.As you perform simulation testing, follow best practices:

  • Провести моделирование таким образом, чтобы не нарушали фактическую деятельность компании, но подчас реальной ситуации.Conduct simulations in a manner that doesn't disrupt actual business but feels like a real situation.
  • Убедитесь, что моделируемые сценарии являются полностью управляемыми.Make sure that simulated scenarios are completely controllable. Если план восстановления, произошла ошибка, ситуацию можно восстановить нормальный режим работы без ущерба.If the recovery plan seems to be failing, you can restore the situation back to normal without causing damage.
  • Проинформируйте руководство о когда и как будет выполняться имитация.Inform management about when and how the simulation exercises will be conducted. Ваш план подробно описать временные рамки и затрагиваемые ресурсы.Your plan should detail the time frame and the resources affected during the simulation.

Проверку работоспособности подсистемы балансировки нагрузки и диспетчеров трафикаTest health probes for load balancers and traffic managers

Настройка и проверка пробы работоспособности для подсистемы балансировки нагрузки и диспетчеров трафика.Configure and test health probes for your load balancers and traffic managers. Убедитесь, что конечная точка работоспособности проверяет важные части системы и реагирует соответствующим образом.Ensure that your health endpoint checks the critical parts of the system and responds appropriately.

  • Для диспетчера трафика Azure, проверке работоспособности определяется, следует ли выполнить отработку отказа в другой регион.For Azure Traffic Manager, the health probe determines whether to fail over to another region. Конечная точка работоспособности должна проверять любые критические зависимости, которые развертываются в одном регионе.Your health endpoint should check any critical dependencies that are deployed within the same region.
  • Для Azure Load Balancer, проверке работоспособности определяется, следует ли удалять виртуальную Машину из ротации.For Azure Load Balancer, the health probe determines whether to remove a VM from rotation. Конечная точка работоспособности должны сообщать о работоспособности виртуальной машины.The health endpoint should report the health of the VM. Не включайте в развертывание другие уровни или внешние службы.Don't include other tiers or external services. В противном случае при сбое вне виртуальной машины подсистема балансировки нагрузки удалит виртуальную машину из ротации.Otherwise, a failure that occurs outside the VM will cause the load balancer to remove the VM from rotation.

Инструкции по реализации мониторинга работоспособности в приложении см. в описании шаблона мониторинга конечной точки работоспособности.For guidance on implementing health monitoring in your application, see Health Endpoint Monitoring pattern.

Тестирование системы мониторингаTest monitoring systems

Включите мониторинг систем в плане тестирования.Include monitoring systems in your test plan. Автоматизированных систем отработки отказа и восстановления размещения зависят от того, правильность работы отслеживания и инструментирования.Automated failover and failback systems depend on the correct functioning of monitoring and instrumentation. Панелей мониторинга для визуализации системные оповещения о работоспособности и оператор также зависит от того, наличие точной мониторинга и инструментирования.Dashboards to visualize system health and operator alerts also depend on having accurate monitoring and instrumentation. Если происходит сбой этих элементов, они пропускают важную информацию или сообщают неточные данные, поэтому оператор может не понять, что система работает неправильно.If these elements fail, miss critical information, or report inaccurate data, an operator might not realize that the system is unhealthy or failing.

Включить сторонние службы в сценарии тестированияInclude third-party services in test scenarios

Если приложение имеет зависимости от сторонних служб, указать расположение и как эти службы может произойти сбой, и что в силу этих сбоев окажет на приложения.If your application has dependencies on third-party services, identify where and how these services can fail and what effect those failures will have on your application. Имейте в виду уровня службы соглашение об уровне службы независимых производителей и влияние, возможно, во-первых, на ваш план аварийного восстановления.Keep in mind the service-level agreement (SLA) for the third-party service and the effect it might have on your disaster recovery plan.

Сторонняя служба может не обеспечивать возможности мониторинга и диагностики, поэтому важно для входа свои вызовы и сопоставлять их с работоспособности приложений и ведения журналов с использованием уникального идентификатора диагностики.A third-party service might not provide monitoring and diagnostics capabilities, so it's important to log your invocations of them and to correlate them with your application's health and diagnostic logging using a unique identifier. Дополнительные сведения о методиках мониторинга и диагностики см. в разделе руководство по мониторингу и диагностике.For more information on proven practices for monitoring and diagnostics, see Monitoring and diagnostics guidance.

Дальнейшие действияNext steps