AZ-104
Deep Dive
La continuidad del negocio (BC) es el marco más amplio que engloba DR. Asegura que las operaciones críticas puedan continuar durante y después de un incidente. El AZ-104 evalúa cómo Azure soporta una estrategia BCDR y las arquitecturas que garantizan resiliencia.
Contenido
Business Continuity es el proceso de asegurar que las funciones críticas de negocio puedan continuar durante y después de un desastre. Es más amplio que DR: DR cubre la recuperación de TI, BC cubre también los procesos de negocio, el personal, los clientes y la comunicación.
BC vs DR
Tipos de incidentes
Ciclo de BCM
El Business Impact Analysis (BIA) identifica los procesos críticos del negocio, cuantifica el impacto de su interrupción y establece prioridades de recuperación. Es el punto de partida para definir RTO y RPO.
Qué identifica el BIA
Critical Business Functions (CBF)
Procesos que si fallan causan impacto catastrófico. Ej: procesamiento de pagos, sistema de control de manufactura, soporte médico urgente.
Maximum Tolerable Downtime (MTD)
Tiempo máximo que puede estar caído un proceso antes de daño irreversible al negocio. El RTO debe ser menor que el MTD.
Work Recovery Time (WRT)
Tiempo necesario para recuperar el trabajo acumulado durante el downtime (ej: procesar pedidos pendientes). RTO + WRT ≤ MTD.
Dependencies
Qué sistemas, proveedores, personas o datos necesita cada proceso crítico. Una DB caída puede detener múltiples procesos.
Clasificación de sistemas
Resultado del BIA: clasificar cada sistema por criticidad para priorizar inversión en DR.
Tier 1 — Crítico — RTO < 1h, RPO < 15 min
Sistema de pagos, core banking, sistema de control médico. Inversión máxima en BC.
Tier 2 — Importante — RTO < 8h, RPO < 1h
ERP, CRM, email. Impacto significativo pero no catastrófico si cae unas horas.
Tier 3 — Normal — RTO < 24h, RPO < 4h
Intranet, reporting, herramientas internas. Impacto operativo pero tolerable.
Tier 4 — Bajo — RTO días, RPO diario
Sistemas de archivo, reporting histórico. Solo backup básico necesario.
| Servicio Azure | Función en BCDR | RTO | RPO | Scope |
|---|---|---|---|---|
| Azure Backup | Copia de seguridad y restauración de VMs, DBs, archivos | Horas | Horas-días | Archivo + restore |
| Azure Site Recovery | Replicación de VMs para DR cross-región | Minutos | 30 seg - 5 min | DR de VMs |
| SQL Failover Groups | Failover automático de Azure SQL | < 30 seg | < 5 seg | DR de SQL |
| Storage GRS/GZRS | Replicación async de blobs a región paired | Horas (Microsoft-initiated) | ~15 min de lag | DR de storage |
| Traffic Manager | Failover DNS automático entre endpoints | 1-3 min | N/A (routing) | DR de endpoint |
| Azure Front Door | Failover de tráfico global en el edge | < 30 seg | N/A (routing) | DR de app global |
| Availability Zones | HA dentro de región ante fallo de zona | < 1 seg | 0 | HA intrarregional |
| Availability Sets | Distribución de VMs en fault/update domains | 0 (otras VMs siguen) | 0 | HA de VMs |
Single-región con Availability Zones
SLA 99.99%VMs en múltiples zonas, Load Balancer zone-redundant, SQL zone-redundant. Protege contra fallo de datacenter. NO protege contra fallo de región completa.
Componentes clave
Multi-región activo-pasivo (warm standby)
RTO 15-60 min, RPO ~0Región primaria activa + región secundaria con capacidad reducida. ASR para VMs, SQL Geo-Replication. Traffic Manager para failover.
Componentes clave
Multi-región activo-activo
RTO ~0, RPO ~0Ambas regiones reciben tráfico simultáneamente. Front Door o Traffic Manager distribuyen. DB en sync bilateral. Failover es transparente.
Componentes clave
Backup + Restore (low cost)
RTO horas, RPO horasSolo Azure Backup. Sin réplica activa. Para sistemas no críticos con budget limitado.
Componentes clave
Regulaciones que imponen requisitos de BC/DR
PCI-DSS
Plan documentado de DR, backups cifrados, testing anual del plan
HIPAA (sanidad)
Plan de contingencia, backup, DR y procedimientos de emergencia documentados
ISO 22301
Estándar de BC — proceso completo de BCM, BIA, planes y auditorías
GDPR
Capacidad de restaurar datos personales en tiempo apropiado tras incidente
SOC 2
Controles de disponibilidad, incluye DR y pruebas regulares
SLA contractual vs SLA de Azure
El SLA de Microsoft para servicios Azure es un compromiso financiero — si no se cumple, ofrecen créditos de servicio. No garantizan que tu aplicación tenga 99.99% — eso depende de cómo la has diseñado.
SLA de Azure = disponibilidad del recurso
Azure VM en AZ: 99.99% → si la VM está indisponible más de 52 min/año, Microsoft da crédito.
SLA de tu aplicación = composite SLA
Tu app usa VM (99.99%) + SQL (99.99%) + LB (99.99%). Composite SLA = 99.99% × 99.99% × 99.99% ≈ 99.97%.
| Servicio / Concepto | Para qué sirve | Diferencia clave |
|---|---|---|
| Azure Backup | Backups y restauración | Múltiples recovery points históricos. RPO = frecuencia de backup. |
| Azure Site Recovery | DR — replicación continua de VMs | No es backup — no hay puntos históricos múltiples. RPO = 30 seg. |
| Recovery Services Vault | Contenedor para Backup y ASR | Soporta Backup + ASR. El más completo y más común en el examen. |
| Backup Vault | Contenedor para Backup de PaaS modernos | Solo Backup (no ASR). Para Blobs, Disks, PostgreSQL, AKS. |
| RTO | Tiempo máximo de inactividad tolerable | Mide downtime del SISTEMA. RTO < MTD. |
| RPO | Pérdida máxima de datos tolerable (en tiempo) | Mide pérdida de DATOS. RPO determina frecuencia de backup/replicación. |
| Failover | Activar el sistema secundario cuando el primario falla | Puede ser automático (TM, SQL Failover Groups) o manual (ASR). |
| Failback | Volver al sistema primario cuando se recupera | En ASR: requiere Re-protect antes. Nunca hacer failback apresurado. |
| Test Failover (ASR) | Probar el DR sin impacto en producción | VMs de test en VNet aislada. Producción no se interrumpe. |
| Soft Delete | Retener datos de backup tras eliminación | 14 días de retención adicional. Protege contra borrado accidental/malicioso. |
| Availability Zones | HA intrarregional (zona de DC falla) | NO protege contra fallo de región completa. |
| Region Pairs | DR cross-región geográficamente separadas | Para desastres regionales. GRS, ASR y CRR usan región paired. |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa de servicios financieros necesita garantizar que su aplicación de pagos pueda recuperarse de un desastre regional con RTO < 30 minutos y RPO < 5 minutos, cumpliendo con PCI-DSS. ¿Cuál es la combinación de servicios más adecuada?