Apply suggestions from proofread

Co-authored-by: Jodi Martis <[email protected]>

Author: v-stsavell

articles/reliability/reliability-data-factory.md

@@ -1,6 +1,6 @@
 ---
 title: Reliability in Azure Data Factory
-description: Learn about reliability in Azure Data Factory by using availability zones, multiple-region deployments, and resilient pipeline practices.
+description: Learn about reliability in Azure Data Factory, including availability zones, multiple-region deployments, and resilient pipeline practices.
 author: jonburchel
 ms.author: jburchel
 ms.topic: reliability-article
@@ -22,15 +22,15 @@ You can use Azure Data Factory to create flexible and powerful data pipelines fo
 
 - *Integration runtimes (IRs)*, which connect to data stores and perform activities defined in your pipeline.
 
-- *Data stores that are connected to the data factory.* To help ensure that data stores meet your business continuity requirements, consult their product reliability documentation and guidance.
+- *Data stores that connect to the data factory.* To help ensure that data stores meet your business continuity requirements, consult their product reliability documentation and guidance.
 
 ## Reliability architecture overview
 
 Azure Data Factory consists of multiple infrastructure components. Each component supports infrastructure reliability in various ways. 
 
 The components of Azure Data Factory include:
 
-- **Core Azure Data Factory service**, which manages pipeline triggers and oversees the coordination of pipeline activities. The core service also manages metadata for each component in the data factory. Microsoft manages the core service.
+- **The core Azure Data Factory service**, which manages pipeline triggers and oversees the coordination of pipeline activities. The core service also manages metadata for each component in the data factory. Microsoft manages the core service.
 
 - **[IRs](../data-factory/concepts-integration-runtime.md#integration-runtime-types)**, which perform specific activities within a pipeline. There are different types of IRs.
 
@@ -50,26 +50,26 @@ Your pipeline activities should be *idempotent*, which means that they can be re
 
 To prevent duplicate record insertion because of a transient fault, implement the following best practices:
 
--  *Use unique identifiers* to each record before you write to the database. This approach can help you find and eliminate duplicate records.
+-  *Use unique identifiers* for each record before you write to the database. This approach can help you find and eliminate duplicate records.
 
 -  *Use an upsert strategy* for connectors that support upsert. Before duplicate record insertion occurs, use this approach to check whether a record already exists. If it does exist, update it. If it doesn't exist, insert it. For example, SQL commands like `MERGE` or `ON DUPLICATE KEY UPDATE` use this upsert approach.
 
-- *Use copy action strategies* that are described in [Data consistency verification in copy activity](../data-factory/copy-activity-data-consistency.md).
+- *Use copy action strategies.* For more information, see [Data consistency verification in copy activity](../data-factory/copy-activity-data-consistency.md).
 
 ### Retry policies
 
 You can use retry policies to configure parts of your pipeline to retry if there's a problem, like transient faults in connected resources. In Azure Data Factory, you can configure retry policies on the following pipeline object types:
 
-- [Tumbling window triggers](../data-factory/concepts-pipeline-execution-triggers.md#tumbling-window-trigger).
-- [Execution activities](../data-factory/concepts-pipelines-activities.md#execution-activities).
+- [Tumbling window triggers](../data-factory/concepts-pipeline-execution-triggers.md#tumbling-window-trigger)
+- [Implementation activities](../data-factory/concepts-pipelines-activities.md#execution-activities)
 
-For more information about how to change or disable retry policies for your data factory triggers and activities, see [Pipeline execution and triggers](../data-factory/concepts-pipeline-execution-triggers.md).
+For more information about how to change or disable retry policies for your data factory triggers and activities, see [Pipeline runs and triggers](../data-factory/concepts-pipeline-execution-triggers.md).
 
 ## Availability zone support
 
 [!INCLUDE [AZ support description](includes/reliability-availability-zone-description-include.md)]
 
-Azure Data Factory supports *zone redundancy*, which provides resiliency to failures in [availability zones](availability-zones-overview.md). This section describes how each part of the Azure Data Factory service supports zone redundancy.
+Azure Data Factory supports zone redundancy, which provides resiliency to failures in [availability zones](availability-zones-overview.md). This section describes how each part of the Azure Data Factory service supports zone redundancy.
 
 ### Regions supported
 
@@ -101,7 +101,7 @@ Zone-redundant Azure Data Factory resources can be deployed in [any region that
 
 ### Configure availability zone support
 
-**Azure Data Factory core service:** No configuration required. Azure Data Factory core service automatically supports zone redundancy.
+**Core service:** No configuration required. The Data Factory core service automatically supports zone redundancy.
 
 **IRs:**
 
@@ -119,7 +119,7 @@ Zone-redundant Azure Data Factory resources can be deployed in [any region that
 
 - *Azure IR* scales automatically based on demand, and you don't need to plan or manage capacity.
 
-- *Azure-SSIS IR* requires you to specifically configure the number of nodes that you use. To prepare for availability zone failure, consider *over-provisioning* the capacity of your IR. Over-provisioning allows the solution to tolerate some degree of capacity loss and still continue to function without degraded performance. For more information, see [Manage capacity with over-provisioning](./concept-redundancy-replication-backup.md#manage-capacity-with-over-provisioning).
+- *Azure-SSIS IR* requires you to specifically configure the number of nodes that you use. To prepare for availability zone failure, consider over-provisioning the capacity of your IR. Over-provisioning allows the solution to tolerate some degree of capacity loss and still continue to function without degraded performance. For more information, see [Manage capacity by over-provisioning](./concept-redundancy-replication-backup.md#manage-capacity-with-over-provisioning).
 
 - *SHIR* requires you to configure your own capacity and scaling. Consider over-provisioning when you deploy a SHIR.
 
@@ -131,15 +131,15 @@ During normal operations, Azure Data Factory automatically distributes pipeline
 
 **Detection and response:** The Azure Data Factory platform is responsible for detecting a failure in an availability zone and responding. You don't need to do anything to initiate a zone failover in your pipelines or other components.
 
-**Active requests:** Any pipelines and triggers in progress continue to run, and you won't notice a zone failure. However, activities in progress during a zone failure might fail and be restarted. It's important to design activities to be idempotent, which helps them to recover from zone failures and other faults. For more information, see [Transient faults](#transient-faults).
+**Active requests:** Any pipelines and triggers in progress continue to run, and you don't experience any immediate disruption from a zone failure. However, activities in progress during a zone failure might fail and be restarted. It's important to design activities to be idempotent, which helps them recover from zone failures and other faults. For more information, see [Transient faults](#transient-faults).
 
 ### Failback
 
 When the availability zone recovers, Azure Data Factory automatically fails back to the original zone. You don't need to do anything to initiate a zone failback in your pipelines or other components.
 
 However, if you use the SHIR, you might need to restart your compute resources if they've been stopped.
 
-### Testing for zone failures
+### Test for zone failures
 
 For the core service, and for Azure and Azure-SSIS IRs, Azure Data Factory manages traffic routing, failover, and failback for zone-redundant resources. Because this feature is fully managed, you don't need to initiate or validate availability zone failure processes.
 
@@ -151,11 +151,11 @@ Azure Data Factory resources are deployed into a single Azure region. If the reg
 
 ### Microsoft-managed failover to a paired region
 
-Azure Data Factory supports Microsoft-managed failover for data factories in *paired regions*, except for Brazil South and Southeast Asia. In the unlikely event of a prolonged region failure, Microsoft might initiate a regional failover of your Azure Data Factory instance.
+Azure Data Factory supports Microsoft-managed failover for data factories in paired regions, except for Brazil South and Southeast Asia. In the unlikely event of a prolonged region failure, Microsoft might initiate a regional failover of your Azure Data Factory instance.
 
-Because of data residency requirements in Brazil South and Southeast Asia, Azure Data Factory data is stored in the local region only by using [Azure Storage zone-redundant storage](../storage/common/storage-redundancy.md#zone-redundant-storage). For Southeast Asia, all data is stored in Singapore. For Brazil South, all data is stored in Brazil. 
+Because of data residency requirements in Brazil South and Southeast Asia, Azure Data Factory data is stored only in the local region by using [Azure Storage zone-redundant storage](../storage/common/storage-redundancy.md#zone-redundant-storage). For Southeast Asia, all data is stored in Singapore. For Brazil South, all data is stored in Brazil. 
 
-For data factories in *nonpaired regions*, or in Brazil South or Southeast Asia, Microsoft doesn't perform regional failover on your behalf.
+For data factories in nonpaired regions, or in Brazil South or Southeast Asia, Microsoft doesn't perform regional failover on your behalf.
 
 > [!IMPORTANT]
 > Microsoft triggers Microsoft-managed failover. It's likely to occur after a significant delay and is done on a best-effort basis. There are also some exceptions to this process. You might experience some loss of your data factory metadata. The failover of Azure Data Factory resources might occur at a different time than the failover of other Azure services.
@@ -166,37 +166,37 @@ For data factories in *nonpaired regions*, or in Brazil South or Southeast Asia,
 
 To prepare for a failover, there might be some extra considerations, depending on the IR that you use.
 
-- You can configure *Azure IR* to automatically resolve the region that it uses. If the region is set to *auto resolve* and there's an outage in the primary region, the Azure IR automatically fails over to the paired region. This failover is subject to the limitations described in [Microsoft-managed failover to a paired region](#microsoft-managed-failover-to-a-paired-region). To configure the Azure IR region for your activity execution or dispatch in the IR setup, set the region to *auto resolve*.
+- You can configure *Azure IR* to automatically resolve the region that it uses. If the region is set to *auto resolve* and there's an outage in the primary region, the Azure IR automatically fails over to the paired region. This failover is subject to [limitations](#microsoft-managed-failover-to-a-paired-region). To configure the Azure IR region for your activity implementation or dispatch in the IR setup, set the region to *auto resolve*.
 
-- *Azure-SSIS IR* failover is managed separately from Microsoft-managed failover of the data factory. For more information, see [Alternative multiple-region approaches](#alternative-multiple-region-approaches).
+- *Azure-SSIS IR* failover is managed separately from a Microsoft-managed failover of the data factory. For more information, see [Alternative multiple-region approaches](#alternative-multiple-region-approaches).
 
-- *SHIR* runs on infrastructure that you're responsible for, and so Microsoft-managed failover doesn't apply to SHIRs. For more information, see [Alternative multiple-region approaches](#alternative-multiple-region-approaches).
+- *SHIR* runs on infrastructure that you're responsible for, so a Microsoft-managed failover doesn't apply to SHIRs. For more information, see [Alternative multiple-region approaches](#alternative-multiple-region-approaches).
 
 #### Post-failover reconfiguration
 
-After a Microsoft-managed failover is complete, you can then access your Azure Data Factory pipeline in the paired region. However, after the failover completes, you might need to perform some reconfiguration for IRs or other components. This process includes re-establishing the networking configuration.
+After a Microsoft-managed failover is complete, you can access your Azure Data Factory pipeline in the paired region. However, after the failover completes, you might need to perform some reconfiguration for IRs or other components. This process includes re-establishing the networking configuration.
 
 ### Alternative multiple-region approaches
 
 If you need your pipelines to be resilient to regional outages and you need control over the failover process, consider using a metadata-driven pipeline.
 
-- **Set up source control for your Azure Data Factory** to track and audit any changes made to your metadata. You can use this approach to access your metadata JSON files for pipelines, datasets, linked services, and triggers. Azure Data Factory supports different Git repository types, like Azure DevOps and GitHub. For more information, see [Source control in Azure Data Factory](../data-factory/source-control.md).
+- **Set up source control for Azure Data Factory** to track and audit any changes to your metadata. You can use this approach to access your metadata JSON files for pipelines, datasets, linked services, and triggers. Azure Data Factory supports different Git repository types, like Azure DevOps and GitHub. For more information, see [Source control in Azure Data Factory](../data-factory/source-control.md).
 
-- **Use a continuous integration and delivery (CI/CD) system**, such as Azure DevOps, to manage your pipeline metadata and deployments. You can use CI/CD to quickly restore operations to an instance in another region. If a region is unavailable, you can provision a new data factory manually or through automation. After the new data factory is created, you can restore your pipelines, datasets, and linked services JSON from the existing Git repository. For more information, see [Business continuity and disaster recovery (BCDR) for Azure Data Factory and Azure Synapse Analytics pipelines](/azure/architecture/example-scenario/analytics/pipelines-disaster-recovery).
+- **Use a continuous integration and continuous delivery (CI/CD) system**, such as Azure DevOps, to manage your pipeline metadata and deployments. You can use CI/CD to quickly restore operations to an instance in another region. If a region is unavailable, you can provision a new data factory manually or through automation. After the new data factory is created, you can restore your pipelines, datasets, and linked services JSON from the existing Git repository. For more information, see [Business continuity and disaster recovery (BCDR) for Azure Data Factory and Azure Synapse Analytics pipelines](/azure/architecture/example-scenario/analytics/pipelines-disaster-recovery).
 
 Depending on the IR that you use, there might be other considerations.
 
-- *Azure-SSIS IR* uses a database stored in Azure SQL Database or Azure SQL Managed Instance. You can configure geo-replication or a failover group for this database. The Azure-SSIS database is then located in a primary Azure region with read-write access (the *primary role*) and is continuously replicated to a secondary region with read-only access (the *secondary role*). If the primary region is lost, a failover is triggered, which causes the primary and secondary databases to swap roles.
+- *Azure-SSIS IR* uses a database stored in Azure SQL Database or Azure SQL Managed Instance. You can configure geo-replication or a failover group for this database. The Azure-SSIS database is located in a primary Azure region that has read-write access. The database is continuously replicated to a secondary region that has read-only access. If the primary region is unavailable, a failover triggers, which causes the primary and secondary databases to swap roles.
 
-    You can also configure a dual standby Azure SSIS IR pair that works in sync with Azure SQL Database or Azure SQL Managed Instance failover group.
+    You can also configure a dual standby Azure SSIS IR pair that works in sync with a SQL Database or SQL Managed Instance failover group.
 
     For more information, see [Configure Azure-SSIS IR for BCDR](../data-factory/configure-bcdr-azure-ssis-integration-runtime.md).
 
 - *SHIR* runs on infrastructure that you manage. If the SHIR is deployed to an Azure VM, you can use [Azure Site Recovery](../site-recovery/site-recovery-overview.md) to trigger [VM failover](../site-recovery/azure-to-azure-architecture.md) to another region.
 
 ## Backup and restore
 
-Azure Data Factory enables CI/CD by integrating with source control, which allows you to back up metadata from a data factory instance. This metadata can then be deployed seamlessly into a new environment. For more information, see [Continuous integration and delivery in Azure Data Factory](../data-factory/continuous-integration-delivery.md).
+Data Factory supports CI/CD through source control integration, so that you can back up the metadata of a data factory instance. CI/CD pipelines deploy this metadata seamlessly into a new environment. For more information, see [CI/CD in Azure Data Factory](../data-factory/continuous-integration-delivery.md).
 
 ## Related content