Разработка надежных приложений AzureDesigning reliable Azure applications

Процесс создания надежного приложения в облаке отличается от традиционной разработки приложений.Building a reliable application in the cloud is different from traditional application development. Хотя ранее вы, возможно, приобретали оборудование более высокого уровня для вертикального масштабирования, в облачной среде вы должны выполнять горизонтальное масштабирование.While historically you may have purchased higher-end hardware to scale up, in a cloud environment you scale out instead of up. Вместо того чтобы пытаться предотвратить все возможные сбои, нужно свести к минимуму воздействие сбоя каждого отдельного компонента.Instead of trying to prevent failures altogether, the goal is to minimize the effects of a single failing component.

Надежные приложения отличаются такими характеристиками:Reliable applications are:

  • Устойчивость и восстановление после ошибок для работы с минимальными простоями и потерями данных до необходимости выполнять полное восстановление.Resilient and recover gracefully from failures, and they continue to function with minimal downtime and data loss before full recovery.
  • Высокий уровень доступности и надлежащая работа с максимальной работоспособностью без значительных простоев.Highly available (HA) and run as designed in a healthy state with no significant downtime.

Понимание того, как такие характеристики связаны друг с другом — и как они влияют на затраты — критически важно при создании надежного приложения.Understanding how these elements work together — and how they affect cost — is essential to building a reliable application. Благодаря этому вы сможете оценить, какое время простоев для вас допустимо, рассчитать потенциальные затраты для бизнеса, а также определить необходимые функции для выполнения восстановления.It can help you determine how much downtime is acceptable, the potential cost to your business, and which functions are necessary during a recovery.

В этой статье вкратце рассматривается, как повысить надежность приложения Azure на каждом шаге его разработки.This article provides a brief overview of building reliability into each step of the Azure application design process. В каждом разделе приведена ссылка на подробную статью об интеграции функций для повышения надежности на конкретном шаге процесса.Each section includes a link to an in-depth article on how to integrate reliability into that specific step in the process. Рекомендации по повышению надежности отдельных служб Azure см. в статье Resiliency checklist for specific Azure services (Контрольный список по обеспечению устойчивости для отдельных служб Azure).If you're looking for reliability considerations for individual Azure services, review the Resiliency checklist for specific Azure services.

Разработка для максимальной надежностиBuild for reliability

В этом разделе описываются шесть шагов по созданию надежного приложения Azure.This section describes six steps for building a reliable Azure application. В каждом шаге приведена ссылка на раздел с подробным описанием процесса и терминов.Each step links to a section that further defines the process and terms.

  1. Определите требования. Define requirements. Сформируйте требования к доступности и восстановлению с учетом отдельных потребностей рабочих нагрузок и бизнеса.Develop availability and recovery requirements based on decomposed workloads and business needs.
  2. Следуйте рекомендациям по созданию архитектуры. Use architectural best practices. Следуйте проверенным практикам, определите возможные точки отказа в архитектуре, а также то, как приложение будет реагировать на ошибки.Follow proven practices, identify possible failure points in the architecture, and determine how the application will respond to failure.
  3. Выполните тестирование с моделированием и принудительными переходами на другой ресурс. Test with simulations and forced failovers. Выполните моделирование сбоев, инициируйте принудительный переход на другой ресурс и протестируйте обнаружение таких сбоев и восстановление после них.Simulate faults, trigger forced failovers, and test detection and recovery from these failures.
  4. Обеспечьте согласованность при развертывании приложения. Deploy the application consistently. Разверните выпуск приложения в рабочей среде с использованием надежных и проверенных процессов.Release to production using reliable and repeatable processes.
  5. Отслеживайте работоспособность приложения. Monitor application health. Обнаруживайте сбои, отслеживайте признаки потенциальных сбоев и оценивайте работоспособность приложений.Detect failures, monitor indicators of potential failures, and gauge the health of your applications.
  6. Реагируйте на сбои и аварии. Respond to failures and disasters. Идентифицируйте сбои при их возникновении и определяйте способы реагирования на них на основе утвержденных стратегий.Identify when a failure occurs, and determine how to address it based on established strategies.

Определение требованийDefine requirements

Определите потребности бизнеса и создайте план по повышению надежности, чтобы удовлетворить их.Identify your business needs, and build your reliability plan to address them. Рассмотрим следующее:Consider the following:

  • Определите рабочие нагрузки и уровень потребления ресурсов.Identify workloads and usage. Рабочая нагрузка — это отдельная возможность или задача, которая логически отделена от других задач с точки зрения требований к бизнес-логике и хранению данных.A workload is a distinct capability or task that is logically separated from other tasks, in terms of business logic and data storage requirements. Каждая рабочая нагрузка имеет свои требования к доступности, масштабируемости, согласованности данных и аварийному восстановлению.Each workload has different requirements for availability, scalability, data consistency, and disaster recovery.

  • Составьте план с учетом особенностей потребления.Plan for usage patterns. Особенности потребления также очень важны при определении требований.Usage patterns also play a role in requirements. Определите различия в требованиях в критические и некритические периоды.Identify differences in requirements during critical and non-critical periods. Например, приложение для работы с налоговой документацией не должно стать недоступным прямо перед крайним сроком ее подачи.For example, a tax-filing application can't fail during a filing deadline. Для бесперебойной работы обеспечьте избыточность в нескольких регионах на случай сбоя одного из них.To ensure uptime, plan redundancy across several regions in case one fails. И наоборот, чтобы уменьшить затраты в некритические периоды, вы можете выполнять приложение только в одном регионе.Conversely, to minimize costs during non-critical periods, you can run your application in a single region.

  • Утвердите метрики доступности — среднее время восстановления (MTTR) и среднее время безотказной работы (MTBF).Establish availability metrics — mean time to recovery (MTTR) and mean time between failures (MTBF). MTTR — это среднее время, необходимое для восстановления компонента после сбоя.MTTR is the average time it takes to restore a component after a failure. MTBF — это продолжительность работы, которую можно ожидать от компонента между отключениями.MTBF is how long a component can reasonably expect to last between outages. Используйте эти показатели, чтобы решить, где обеспечить избыточность, а также определить соглашения об уровне обслуживания (SLA) для клиентов.Use these measures to determine where to add redundancy and to determine service-level agreements (SLAs) for customers.

  • Утвердите метрики восстановления — целевое время восстановления (RTO) и целевая точка восстановления (RPO).Establish recovery metrics — recovery time objective and recovery point objective (RPO). RTO — это максимально допустимое время, в течение которого приложение может быть недоступно после инцидента.RTO is the maximum acceptable time an application can be unavailable after an incident. RPO — это максимальная продолжительность потери данных, которая является приемлемой во время аварии.RPO is the maximum duration of data loss that is acceptable during a disaster. Чтобы определить их значения, проведите оценку рисков и убедитесь, что вы хорошо понимаете затраты и риски, связанные с простоями или потерей данных в вашей организации.To derive these values, conduct a risk assessment and make sure you understand the cost and risk of downtime or data loss in your organization.

    Примечание

    Если показатель MTTR любого критически важного компонента в высокодоступной конфигурации превышает значение RTO системы, сбой в системе может привести к недопустимому прерыванию бизнес-процессов.If the MTTR of any critical component in a highly available setup exceeds the system RTO, a failure in the system might cause an unacceptable business disruption. А это значит, что вы не сможете восстановить систему в рамках определенного значения RTO.That is, you can't restore the system within the defined RTO.

  • Определите целевые показатели доступности рабочих нагрузок.Determine workload availability targets. Чтобы обеспечить соответствие архитектуры приложения вашим бизнес-требованиям, определите целевые соглашения SLA для каждой рабочей нагрузки.To ensure that application architecture meets your business requirements, define target SLAs for each workload. Помимо зависимостей приложений, также учитывайте затраты и сложности, связанные с удовлетворением требований к доступности.Account for the cost and complexity of meeting availability requirements, in addition to application dependencies.

  • Изучите соглашения об уровне обслуживания.Understand service-level agreements. В Azure соглашение об уровне обслуживания описывает обязательства корпорации Майкрософт в отношении времени доступности и подключения.In Azure, the SLA describes the Microsoft commitments for uptime and connectivity. Если в SLA для конкретной службы указано 99,9 %, это означает, что вы должны ожидать, что служба будет доступна 99,9 % времени.If the SLA for a particular service is 99.9 percent, you should expect the service to be available 99.9 percent of the time.

    Определите собственные целевые соглашения SLA для каждой рабочей нагрузки решения, чтобы вы могли оценить, в какой мере архитектура удовлетворяет требованиям бизнеса.Define your own target SLAs for each workload in your solution, so you can determine whether the architecture meets the business requirements. Например, если для рабочей нагрузки требуется 99,99 % времени безотказной работы, но она зависит от службы с SLA на уровне 99,9 %, эта служба не может быть единой точкой отказа в системе.For example, if a workload requires 99.99 percent uptime but depends on a service with a 99.9 percent SLA, that service can't be a single point of failure in the system.

Дополнительные сведения о формулировке требований для надежных приложений см. в статье Developing requirements for resilient Azure applications (Формулирование требований для устойчивых приложений Azure).For more information about developing requirements for reliable applications, see Developing requirements for resilient Azure applications.

Следование рекомендациям по созданию архитектурыUse architectural best practices

На этапе разработки архитектуры уделите основное внимание внедрению практик, которые обеспечат удовлетворение бизнес-требований, помогут определять точки сбоя и минимизировать степень их влияния.During the architectural phase, focus on implementing practices that meet your business requirements, identify failure points, and minimize the scope of failures.

  • Выполните анализ режима сбоя (FMA).Perform a failure mode analysis (FMA). FMA позволяет повысить устойчивость приложения на ранней стадии проектирования.FMA builds resiliency into an application early in the design stage. Этот анализ помогает определить типы сбоев, которые могут возникнуть для приложения, потенциальные последствия каждого сбоя и возможные стратегии восстановления.It helps you identify the types of failures your application might experience, the potential effects of each, and possible recovery strategies.

  • Создайте план обеспечения избыточности.Create a redundancy plan. Уровень избыточности каждой рабочей нагрузки зависит от потребностей вашего бизнеса и влияет на общую стоимость приложения.The level of redundancy required for each workload depends on your business needs and factors into the overall cost of your application.

  • Проектируйте для масштабируемости.Design for scalability. Облачные приложения должны поддерживать масштабирование для адаптации к изменениям в потреблении ресурсов.A cloud application must be able to scale to accommodate changes in usage. Начните разработку с отдельных компонентов и предусмотрите в приложении автоматическое реагирование на изменения нагрузки (при возможности).Begin with discrete components, and design the application to respond automatically to load changes whenever possible. Учитывайте ограничения масштабирования в ходе разработки, чтобы вы могли с легкостью расширить их в будущем.Keep scaling limits in mind during design so you can expand easily in the future.

  • Учтите требования подписки и служб.Plan for subscription and service requirements. Вам могут потребоваться дополнительные подписки для подготовки достаточного объема ресурсов, чтобы вы могли удовлетворить требования бизнеса к хранению, подключениям, пропускной способности и т. д.You might need additional subscriptions to provision enough resources to meet your business requirements for storage, connections, throughput, and more.

  • Используйте балансировку нагрузки для распределения запросов.Use load-balancing to distribute requests. Балансировка нагрузки распределяет запросы вашего приложения между работоспособными экземплярами службы, удаляя неработоспособные экземпляры из ротации.Load-balancing distributes your application's requests to healthy service instances by removing unhealthy instances from rotation.

  • Внедрите стратегии обеспечения устойчивости.Implement resiliency strategies. Устойчивость представляет собой возможность восстановления системы после сбоев и продолжения работы.Resiliency is the ability of a system to recover from failures and continue to function. Внедрите конструктивные шаблоны обеспечения устойчивости, например для изолирования критически важных ресурсов, использования компенсирующих транзакций и выполнения асинхронных операций (при возможности).Implement resiliency design patterns, such as isolating critical resources, using compensating transactions, and performing asynchronous operations whenever possible.

  • Внедрите требования к доступности в свой проект.Build availability requirements into your design. Доступность — это доля времени, на протяжении которого система работает надлежащим образом.Availability is the proportion of time your system is functional and working. Примите меры, чтобы обеспечить соответствие уровня доступности приложения вашему соглашению об уровне обслуживания.Take steps to ensure that application availability conforms to your service-level agreement. Например, избегайте единых точек отказа, разделите рабочие нагрузки в зависимости от целевого уровня обслуживания и регулируйте потребление ресурсов пользователей, создающих большую нагрузку.For example, avoid single points of failure, decompose workloads by service-level objective, and throttle high-volume users.

  • Обеспечьте управление данными.Manage your data. Подходы к хранению, резервному копированию и репликации данных имеют большое значение.How you store, back up, and replicate data is critical.

    • Выберите методы репликации для данных приложения.Choose replication methods for your application data. Данные приложения хранятся в разных хранилищах данных и могут иметь разные требования к доступности.Your application data is stored in various data stores and might have different availability requirements. Оцените методы репликации и расположения для каждого типа хранилища данных, чтобы убедиться в том, что они отвечают вашим требованиям.Evaluate the replication methods and locations for each type of data store to ensure that they satisfy your requirements.
    • Задокументируйте и протестируйте процессы отработки отказа и восстановления размещения.Document and test your failover and failback processes. Четко задокументируйте инструкции по отработке отказа в новое хранилище данных и регулярно тестируйте их на точность и простоту выполнения.Clearly document instructions to fail over to a new data store, and test them regularly to make sure they are accurate and easy to follow.
    • Обеспечьте защиту данных.Protect your data. Регулярно создавайте резервные копии данных и проверяйте их, а также убедитесь в том, что ни один пользователь не имеет доступа одновременно к рабочим данным и данным резервных копий.Back up and validate data regularly, and make sure no single user account has access to both production and backup data.
    • Обеспечьте возможность восстановления данных.Plan for data recovery. Убедитесь, что ваша стратегия резервного копирования и репликации позволяет восстановить данные за то время, которое удовлетворяет требованиям уровня обслуживания.Make sure that your backup and replication strategy provides for data recovery times that meet your service-level requirements. Учитывайте все типы данных, которые использует ваше приложение, в том числе ссылочные данные и базы данных.Account for all types of data your application uses, including reference data and databases.

Дополнительные сведения о создании архитектуры надежных приложений см. в статье Architecting Azure applications for resiliency and availability (Разработка архитектуры приложений Azure для максимальной устойчивости и доступности).For more information about architecting reliable applications, see Architecting Azure applications for resiliency and availability.

Тестирование с моделированием и принудительными переходами на другой ресурсTest with simulations and forced failovers

Тестирование надежности требует оценки того, как сквозная рабочая нагрузка выполняется в условиях сбоя, которые возникают только периодически.Testing for reliability requires measuring how the end-to-end workload performs under failure conditions that only occur intermittently.

  • Выполните тестирование для распространенных сценариев сбоя, создавая реальные условия сбоя или моделируя их.Test for common failure scenarios by triggering actual failures or by simulating them. Используйте проверки с внесением ошибок для тестирования распространенных сценариев (в том числе с несколькими сбоями одновременно) и времени восстановления.Use fault injection testing to test common scenarios (including combinations of failures) and recovery time.
  • Определите сбои, которые возникают только под нагрузкой.Identify failures that occur only under load. Протестируйте на максимальную нагрузку, используя данные из рабочей среды или искусственные данные, максимально приближенные к данным из рабочей среды. Это поможет понять, как приложение работает в реальных условиях.Test for peak load, using production data or synthetic data that is as close to production data as possible, to see how the application behaves under real-world conditions.
  • Выполняйте отработку аварийного восстановления.Run disaster recovery drills. Внедрите план аварийного восстановления и периодически тестируйте его.Have a disaster recovery plan in place, and test it periodically to make sure it works.
  • Выполните тестирование отработки отказа и восстановления размещения.Perform failover and failback testing. Убедитесь в том, что зависимые службы приложения выполняют отработку отказа и восстановление размещения в правильном порядке.Ensure that your application's dependent services fail over and fail back in the correct order.
  • Выполните тестирование с моделированием ситуаций.Run simulation tests. Тестирование реальных сценариев поможет определить проблемы, требующие решения.Testing real-life scenarios can highlight issues that need to be addressed. Такие сценарии должны быть управляемыми и не прерывать операции бизнеса.Scenarios should be controllable and non-disruptive to the business. Проинформируйте руководство о наличии планов тестирования с моделированием ситуаций.Inform management of simulation testing plans.
  • Протестируйте проверки работоспособности.Test health probes. Настройте проверки работоспособности для подсистем балансировки нагрузки и диспетчеров трафика, чтобы убедиться в надлежащей работе критически важных компонентов системы.Configure health probes for load balancers and traffic managers to check critical system components. Также протестируйте их на надлежащее реагирование.Test them to make sure that they respond appropriately.
  • Протестируйте системы мониторинга.Test monitoring systems. Убедитесь, что системы мониторинга надлежащим образом предоставляют критически важную информацию и точные данные для определения потенциальных сбоев.Be sure that monitoring systems are reliably reporting critical information and accurate data to help identify potential failures.
  • Включите в сценарии тестирования сторонние службы.Include third-party services in test scenarios. Протестируйте возможные точки отказа, возникающие из-за прерывания работы сторонних служб, а также возможность восстановления.Test possible points of failure due to third-party service disruption, in addition to recovery.

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

Дополнительные сведения о тестировании надежности приложений см. в статье Testing Azure applications for resiliency and availability (Тестирование устойчивости и доступности приложений Azure).For more information about testing for application reliability, see Testing Azure applications for resiliency and availability.

Согласованное развертывание приложенияDeploy the application consistently

Развертывание включает подготовку ресурсов Azure, развертывание кода приложения и применение параметров конфигурации.Deployment includes provisioning Azure resources, deploying application code, and applying configuration settings. Обновление может включать все три задачи или только некоторые из них.An update may involve all three tasks or a subset of them.

После развертывания приложения в рабочей среде обновления могут стать возможными источниками ошибок.After an application is deployed to production, updates are a possible source of errors. Сведите к минимуму число ошибок, используя предсказуемые и повторяющиеся процессы развертывания.Minimize errors with predictable and repeatable deployment processes.

  • Автоматизируйте процесс развертывания приложения.Automate your application deployment process. При возможности автоматизируйте процессы.Automate as many processes as possible.
  • Разработайте процесс выпуска, максимально повышающий уровень доступности.Design your release process to maximize availability. Если процесс выпуска требует, чтобы службы отключались во время развертывания, ваше приложение будет недоступно, пока службы не вернутся в сеть.If your release process requires services to go offline during deployment, your application is unavailable until they come back online. Используйте возможности промежуточной и рабочей среды для платформы.Take advantage of platform staging and production features. Применяйте "сине-зеленые" или ранние выпуски для развертывания обновлений, чтобы в случае сбоя вы могли быстро откатить обновление.Use blue-green or canary releases to deploy updates, so if a failure occurs, you can quickly roll back the update.
  • Составьте план отката развертывания.Have a rollback plan for deployment. Создайте процесс отката, позволяющий вернуться к последней известной рабочей версии и минимизировать время простоя в случае сбоя развертывания.Design a rollback process to return to a last known good version and to minimize downtime if a deployment fails.
  • Ведите журнал развертываний и выполняйте их аудит.Log and audit deployments. Если вы используете промежуточные методы развертывания, в рабочей среде будет существовать несколько версий вашего приложения.If you use staged deployment techniques, more than one version of your application is running in production. Реализуйте надежную стратегию ведения журнала, чтобы получить как можно больше сведений о версии.Implement a robust logging strategy to capture as much version-specific information as possible.
  • Задокументируйте процесс выпуска приложения.Document the application release process. Четко определите и задокументируйте процесс выпуска и убедитесь, что он доступен для всей группы разработки.Clearly define and document your release process, and ensure that it's available to the entire operations team.

Дополнительные сведения о надежности и развертывании приложений см. в статье Deploying Azure applications for resiliency and availability (Развертывание приложений Azure для максимальной устойчивости и доступности).For more information about application reliability and deployment, see Deploying Azure applications for resiliency and availability.

Мониторинг работоспособности приложенийMonitor application health

Внедрите рекомендации по мониторингу и созданию оповещений для приложения, чтобы вы могли обнаруживать сбои и уведомлять оператора о необходимости устранения проблемы.Implement best practices for monitoring and alerts in your application so you can detect failures and alert an operator to fix them.

  • Внедрите проверки работоспособности и функции проверки.Implement health probes and check functions. Регулярно выполняйте их извне приложения, чтобы обнаруживать ситуации с ухудшением работоспособности и производительности приложения.Run them regularly from outside the application to identify degradation of application health and performance.

  • Проверяйте длительные рабочие процессы.Check long-running workflows. Раннее обнаружение проблем позволяет устранить потребность в откате всего рабочего процесса или выполнении множества компенсирующих транзакций.Catching issues early can minimize the need to roll back the entire workflow or to execute multiple compensating transactions.

  • Обеспечьте ведение журналов приложений.Maintain application logs.

    • Используйте возможности ведения журналов приложений в рабочей среде и на границе служб.Log applications in production and at service boundaries.
    • Применяйте семантическое и асинхронное ведение журналов.Use semantic and asynchronous logging.
    • Журналы приложений ведите отдельно от журналов аудита.Separate application logs from audit logs.
  • Ведите статистику удаленных вызовов и передавайте такие данные команде приложения.Measure remote call statistics, and share the data with the application team. Чтобы предоставить рабочей группе мгновенный доступ к данным о работоспособности приложения, создавайте сводку метрик удаленных вызовов, например задержки, пропускной способности и ошибок на уровне 99-го и 95-го процентилей.To give your operations team an instantaneous view into application health, summarize remote call metrics, such as latency, throughput, and errors in the 99 and 95 percentiles. Выполните статистический анализ показателей, чтобы выявить ошибки, возникающие на каждом процентиле.Perform statistical analysis on the metrics to uncover errors that occur within each percentile.

  • Отслеживайте временные исключения и повторения за соответствующий интервал времени.Track transient exceptions and retries over an appropriate time frame. Тенденция увеличения исключений с течением времени указывает на то, что в службе возникла проблема и она может выйти из строя.A trend of increasing exceptions over time indicates that the service is having an issue and may fail.

  • Настройте систему раннего предупреждения.Set up an early warning system. Определите ключевые показатели эффективности (КПЭ) вашего приложения, такие как временные исключения и задержка удаленных вызовов, и установите соответствующие пороговые значения для каждого из них.Identify the key performance indicators (KPIs) of an application's health, such as transient exceptions and remote call latency, and set appropriate threshold values for each of them. Отправьте оповещение операциям при достижении порогового значения.Send an alert to operations when the threshold value is reached.

  • Выполняйте операции с учетом ограничений подписки Azure.Operate within Azure subscription limits. В подписках Azure предусмотрены ограничения на определенные типы ресурсов, такие как количество групп ресурсов, ядер и учетных записей хранения.Azure subscriptions have limits on certain resource types, such as the number of resource groups, cores, and storage accounts. Обеспечьте отслеживание потребления ресурсов по типам.Watch your use of resource types.

  • Отслеживайте сторонние службы.Monitor third-party services. Ведите журнал вызовов и выполняйте его корреляцию с журналом работоспособности приложения и журналом диагностики с помощью уникального идентификатора.Log your invocations and correlate them with your application's health and diagnostic logging using a unique identifier.

  • Обучите нескольких операторов мониторингу приложения и выполнению шагов восстановления вручную.Train multiple operators to monitor the application and to perform manual recovery steps. Обеспечьте постоянную доступность по меньшей мере одного обученного оператора.Make sure there is always at least one trained operator active.

Дополнительные сведения о мониторинге надежности приложения см. в статье Monitoring Azure application health (Мониторинг работоспособности приложения Azure).For more information about monitoring for application reliability, see Monitoring Azure application health.

Реагирование на сбои и аварииRespond to failures and disasters

Разработайте план восстановления и убедитесь, что он охватывает такие ситуации, как восстановление данных, сбои сети, сбои зависимых служб и прерывание работы служб во всем регионе.Create a recovery plan, and make sure that it covers data restoration, network outages, dependent service failures, and region-wide service disruptions. Учитывайте потребности виртуальных машин, хранилища, баз данных и других служб платформы Azure в своей стратегии восстановления.Consider your VMs, storage, databases, and other Azure platform services in your recovery strategy.

  • Подготовьтесь к взаимодействию со службой поддержки Azure.Plan for Azure support interactions. До того как в этом возникнет необходимость, разработайте процедуру обращения в службу поддержки Azure.Before the need arises, establish a process for contacting Azure support.
  • Задокументируйте план аварийного восстановления и тестируйте его.Document and test your disaster recovery plan. Разработайте план аварийного восстановления, в котором описывается влияние сбоев приложения на бизнес.Write a disaster recovery plan that reflects the business impact of application failures. В максимальной степени автоматизируйте процессы восстановления и задокументируйте все шаги, которые требуется выполнять вручную.Automate the recovery process as much as possible, and document any manual steps. Регулярно тестируйте процесс аварийного восстановления для проверки и улучшения плана.Regularly test your disaster recovery process to validate and improve the plan.
  • При необходимости выполняйте отработку отказа вручную.Fail over manually when required. Некоторые системы не могут автоматически выполнять отработку отказа и требуют выполнения перехода на другой ресурс вручную.Some systems can't fail over automatically and require a manual failover. Если приложение переходит на другой ресурс в дополнительном регионе, выполните тест готовности к работе.If an application fails over to a secondary region, perform an operational readiness test. Убедитесь, что основной регион работоспособен и готов снова получать трафик, прежде чем восстанавливать размещение.Verify that the primary region is healthy and ready to receive traffic again before failing back. Определите, какие функции приложения работают ненадлежащим образом и как приложение оповещает пользователей о временных проблемах.Determine what the reduced application functionality is and how the app informs users of temporary problems.
  • Подготовьтесь к сбоям приложения.Prepare for application failure. Подготовьтесь к самым различным сбоям, в том числе к сбоям, которые обрабатываются автоматически, приводят к ограничению функциональности и становятся причиной недоступности приложения.Prepare for a range of failures, including faults that are handled automatically, those that result in reduced functionality, and those that cause the application to become unavailable. Приложение должно оповещать пользователей о временных проблемах.The application should inform users of temporary issues.
  • Выполняйте восстановление после повреждения данных.Recover from data corruption. Если сбой произошел в хранилище данных, выполните проверку на отсутствие несогласованности данных, когда хранилище снова станет доступным, особенно если данные были реплицированы.If a failure happens in a data store, check for data inconsistencies when the store becomes available again, especially if the data was replicated. Восстановите поврежденные данные из резервной копии.Restore corrupt data from a backup.
  • Выполняйте восстановление после сбоя сети.Recover from a network outage. В некоторых ситуациях вы сможете использовать кэшированные данные для локальной работы с ограниченной функциональностью приложения.You might be able to use cached data to run locally with reduced application functionality. В противном случае рассматривайте их как простой приложения или выполните отработку отказа на другой регион.If not, consider application downtime or fail over to another region. Сохраняйте данные в другом расположении до восстановления подключения.Store your data in an alternate location until connectivity is restored.
  • Выполняйте восстановление после сбоя зависимой службы.Recover from a dependent service failure. Определите, какие функции доступны и как приложение должно реагировать.Determine which functionality is still available and how the application should respond.
  • Выполняйте восстановления после прерывания работы служб во всем регионе.Recover from a region-wide service disruption. Прерывания работы служб во всем регионе — это редкость, но вы должны иметь стратегию и для них, особенно в случае с критически важными приложениями.Region-wide service disruptions are uncommon, but you should have a strategy to address them, especially for critical applications. В некоторых ситуациях вы сможете повторно развернуть приложение в другом регионе или перераспределить трафик.You might be able to redeploy the application to another region or redistribute traffic.

Дополнительные сведения о реагировании на сбои и об аварийном восстановлении см. в статье Failure and disaster recovery for Azure applications (Восстановление после сбоев и аварийное восстановление для приложений Azure).For more information about responding to failures and disaster recovery, see Failure and disaster recovery for Azure applications.

Дополнительная информацияNext steps