Preparación para la Certificación Microsoft AZ-305
Diseña cargas de trabajo confiables en Azure
Convierte los requisitos empresariales en objetivos de confiabilidad, arquitectura resistente y recuperable, operaciones observables y soluciones deliberadamente simples.
Tiempo de estudio sugerido: 88 minutos • Nivel intermedio • Reescritura original completa con resumen conciso de cada tema
Por João Ricardo Dutra••Contenido original completo
1. Trata la confiabilidad como una capacidad de la carga
El pilar Confiabilidad de Well-Architected analiza si una carga sigue disponible, resiste errores y vuelve a un estado saludable tras una interrupción. Indisponibilidad, dependencias degradadas, implementaciones defectuosas, capacidad agotada y corrupción de datos son riesgos normales en sistemas distribuidos. Un diseño confiable detecta problemas, contiene el impacto, mantiene los recorridos prioritarios con la calidad acordada y se recupera de manera predecible.
La confiabilidad no es un complemento de infraestructura. Código, datos, recursos de , entrega, supervisión y respuesta a incidentes deben sostener las mismas promesas empresariales. Cada medida introduce costo o complejidad; por eso el arquitecto necesita requisitos explícitos y no una petición indefinida de disponibilidad permanente.
Requisitos empresariales, resistencia, recuperación, operaciones y simplicidad forman un solo sistema.
Resumen del tema
Diseña confiabilidad en código, infraestructura, datos y operaciones, y mídela frente a promesas empresariales cuantificables.
2. Usa cinco principios conectados
Principios y pregunta central.
Principio
Pregunta arquitectónica
Requisitos empresariales
¿Qué flujos importan y qué objetivos medibles de servicio y recuperación necesitan?
Resistencia
¿Cómo conservará la carga funcionalidad completa o reducida durante un error?
Recuperación
¿Cómo volverán los componentes y el estado a una condición confiable?
Operaciones
¿Cómo verán, anticiparán, probarán y aprenderán los equipos?
Simplicidad
¿Qué componentes, código propio y procesos se pueden eliminar o estandarizar?
Los principios dependen entre sí. Redundancia sin supervisión puede ocultar una réplica rota; recuperación sin simulacros es solo un documento; escalado sin objetivo puede elevar el costo sin proteger el recorrido correcto. Equilibra confiabilidad con Eficiencia del rendimiento y Optimización de costos.
Resumen del tema
Aplica los cinco principios como un marco único y registra cada equilibrio de costo, rendimiento y operación.
3. Inicia el diseño de Contoso Insurance con requisitos
Una aseguradora ficticia crea una aplicación web para tramitar reclamaciones. La propuesta combina ,, servicios de AI, y Aplicaciones lógicas. Antes de elegir niveles o replicación, el equipo define experiencia, datos, flujos, cumplimiento, presupuesto y restricciones.
La aplicación se divide en flujos de usuario y sistema. Presentar y aprobar una reclamación recibe la mayor criticidad porque médicos y pacientes dependen de ello. Los componentes de apoyo heredan objetivos apropiados en vez de recibir todos el diseño más costoso.
Resumen del tema
Comienza con expectativas empresariales compartidas y alcanzables y con la criticidad de los flujos; después selecciona servicios e inversión.
4. Define objetivos para flujos, componentes y carga completa
Establece objetivos de nivel de servicio y recuperación para componentes, flujos importantes y carga completa. Las métricas convierten la intención en aceptación comprobable y muestran si la arquitectura cabe en el presupuesto. Disponibilidad, latencia, errores, rendimiento, RTO, RPO, tiempo medio de recuperación y duración del estado degradado son medidas útiles.
Los flujos de cumplimiento necesitan resultados inequívocos. El sistema de supervisión es una dependencia y un control, pero no uno de los ámbitos empresariales para los que el ejercicio pide objetivos de confiabilidad de la carga. Separa objetivos de herramientas de medición.
Cada objetivo permanece trazable desde el resultado hasta el recurso que sostiene el flujo.
Resumen del tema
Asocia objetivos medibles a flujos críticos, componentes de apoyo y carga integral, y prueba comportamiento normal y recuperación.
5. Comprende compromisos y restricciones de plataforma
Los contratos de nivel de servicio cambian según servicio, nivel, región, topología y característica. Consulta los de Microsoft para servicios en línea para confirmar disponibilidad garantizada; precio, preguntas frecuentes y documentación general no son el compromiso contractual. Considera límites, cuotas, capacidad regional, mantenimiento y exclusiones.
Si los datos críticos requieren un RTO de 30 segundos, el equipo puede evaluar el nivel crítico para la empresa de con replicación geográfica activa. Aun necesita supervisión, conmutación probada, tratamiento de conexiones, análisis de pérdida y capacidad secundaria. Comprar el nivel no demuestra el RTO.
Resumen del tema
Basa la promesa en el aplicable, límites, cuotas, capacidad y una topología ensayada.
6. Mapea todas las dependencias internas y externas
Documenta infraestructura, , funciones, datos, identidad, , certificados, redes, terceros y procesos de otros equipos. Para cada dependencia registra flujos, objetivo, error, , tolerancia a antigüedad, propietario y escalación. Así aparecen errores en cascada y consecuencias posteriores.
La reclamación usa un conjunto de referencia mantenido por otro departamento. Su disponibilidad es menor; la aplicación acepta cierta antigüedad, pero no ausencia. Una caché local elimina la dependencia en tiempo de ejecución y un trabajo en segundo plano actualiza los datos. Una actualización nocturna solo sirve si la tolerancia lo permite.
Desacoplar modifica el error, pero introduce decisiones de actualidad y conciliación.
Resumen del tema
Incluye todas las dependencias y usa caché, cola, aislamiento o alternativa solo cuando el equilibrio de coherencia sea aceptable.
7. Diseña el flujo de reservas de Contoso Air para resistir
Una aerolínea ficticia usa ,,, Aplicaciones lógicas y . La compra del billete es el flujo más importante, por lo que el equipo concentra mejoras donde el error produce mayor daño empresarial y al cliente.
La puerta de pago externa es muy disponible, pero puede devolver errores transitorios por red o picos concurrentes. El diseño síncrono obliga a reenviar pagos. La solución debe mejorar la experiencia sin duplicar cargos ni perder pedidos.
Resumen del tema
Prioriza resistencia según criticidad e impacto, aunque el punto débil sea un servicio externo muy disponible.
8. Analiza los modos de error antes de probar fallos
Para cada error describe desencadenante, componente, , intensidad, duración, señal, efecto y recuperación. Incluye procesos temporales, saturación, limitación y pérdida de zona o región. Clasifica probabilidad e impacto para invertir en los riesgos principales.
Un ejercicio DDoS u otra prueba disruptiva necesita primero análisis de modos de error. Define frontera prevista, protecciones, condiciones de parada, aprobaciones, telemetría y recuperación segura.
La prueba es segura y útil cuando se conocen límites y comportamiento esperado.
Resumen del tema
Usa análisis de modos de error para clasificar riesgos y definir experimentos controlados antes de inyectar fallos.
9. Crea autoprotección con reintento y aislamiento
La autoprotección evita que una dependencia defectuosa consuma el sistema. Límites modulares, tiempos de espera, reintento, , bulkheads, nivelación, idempotencia y degradación controlada afrontan riesgos distintos. Reintenta solo operaciones seguras y errores transitorios; aumenta la espera, usa variación y limita intentos.
separa al cliente del procesamiento de pago. Un trabajador reintenta fallos temporales y, al alcanzar el máximo, deja de presionar la puerta y conserva o transfiere el mensaje. Correlación, deduplicación, mensajes dañados, visibilidad y conciliación son imprescindibles.
La cola protege el flujo y la dependencia mientras conserva el trabajo.
Resumen del tema
Combina reintento limitado, aislamiento, idempotencia, contrapresión y una ruta duradera de error; nunca reintentes sin límite.
10. Agrega redundancia en las capas adecuadas
La redundancia puede cubrir energía, instalaciones, zonas, regiones, réplicas, instancias, red, funciones, procesos y personas. Elige activo-activo o activo-pasivo según coherencia, conmutación, capacidad, costo y madurez. Las colas amortiguan demanda y reducen acoplamiento.
El nivel premium de puede usar zonas de disponibilidad en regiones admitidas. La recuperación geográfica ofrece configuración secundaria; distingue replicación de de datos de mensajes y confirma el comportamiento vigente. Solo los simulacros prueban la redundancia.
Cada capa atiende un diferente.
Resumen del tema
Usa replicación geográfica cuando el modelo lo permita y prueba el comportamiento exacto de conmutación del servicio.
11. Prepara la plataforma analítica de Contoso para recuperarse
Una solución ficticia ingiere SQL Server local con y usa ,, y . Un proceso Windows heredado vive en una VM. Como es interna y no crítica, se acepta una región y reconstrucción en otra tras un desastre.
La elección solo es válida cuando objetivos, datos, infraestructura, identidades, red, secretos, capacidad y procedimiento permiten reconstruir en el tiempo prometido.
Resumen del tema
Una arquitectura de región única puede ser correcta cuando reconstrucción probada y protección de datos cumplen objetivos explícitos.
12. Crea y ensaya un plan completo de recuperación
El plan cubre cada componente y el sistema: autoridad, detección, declaración, comunicación, conmutación, validación, conmutación por recuperación, reversión, integridad y cierre. Mantén el runbook disponible y registra propietarios, dependencias, credenciales, automatización, capacidad, y terceros.
El equipo escribió una reconstrucción, pero no la ensayó. Una caída real reveló pasos ausentes. Debe actualizarla y adelantar el simulacro. El tiempo medio para restaurar una base desde copia es una métrica directamente útil.
Un documento se convierte en capacidad después de ensayos realistas.
Resumen del tema
Documenta, automatiza, asigna y ensaya conmutación y retorno; valida RTO con tiempos reales de restauración.
13. Recupera datos con estado desde un punto confiable
Cada componente con estado necesita un método que cumpla RPO y RTO. Las copias deben ser inmutables cuando corresponda, coherentes, aisladas del mismo dominio, retenidas y restauradas con regularidad. Replicar reduce RPO, pero puede copiar corrupción; no sustituye puntos independientes.
Bases superiores a 4 TB quedan en con SQL Server 2022. Copia de seguridad automatizada protege todas. Las críticas también usan el vínculo de Instancia Administrada hacia . Confirma dirección, conmutación, retorno, política, versión y región actuales. Convertir de una a varias regiones es otro ejemplo.
Resumen del tema
Combina copias restaurables y replicación adecuada; valida coherencia, inmutabilidad, compatibilidad, conmutación y retorno.
14. Agrega autorreparación automatizada
La autorreparación usa señales y automatización limitada para reiniciar, restablecer imagen, reemplazar o redirigir. Reduce tiempo y error manual, pero necesita período de gracia, límites, protección de estado, escalación y observabilidad.
El proceso Windows puede usar . La extensión de estado de aplicación informa la salud y las reparaciones automáticas reinician, restablecen o reemplazan según configuración. Acciones de también pueden reiniciar la aplicación. evalúa cumplimiento y recomienda; no son la acción directa.
Recuperar datos y reparar componentes resuelven partes distintas.
Resumen del tema
Activa reparación con señales confiables, limita la automatización, protege estado y escala cuando falle repetidamente.
15. Opera los microservicios de Contoso University con visibilidad
Una universidad ficticia usa cinco servicios con ,,,,, y . Una solicitud cruza capas; todos los recursos verdes por separado no prueban que la matrícula funcione.
Operaciones necesita ver el recorrido integral, dependencias y errores activos. La visibilidad compartida acelera triaje, causa raíz, análisis posterior y prioridades.
Resumen del tema
Supervisa flujos entre límites de servicio, no solo la salud aislada de los recursos.
16. Correlaciona telemetría en un sistema observable
Instrumenta la aplicación y combina telemetría con registros y métricas. captura comportamiento y envía señales a un área de trabajo de Analytics en . Identificadores enlazan una misma solicitud entre capas, colas y bases.
El modelo cubre síntomas del usuario, saturación, dependencias, implementaciones, transacciones y automatización. Retención, acceso, costo, muestreo y datos sensibles también son diseño.
La observabilidad explica cuándo, dónde y por qué se degradó el flujo.
Resumen del tema
Hacer observable una carga exige emitir y correlacionar telemetría accionable del recorrido completo con gobernanza.
17. Anticipa problemas con alertas accionables y capacidad
Una alerta debe requerir propietario y respuesta. Prioriza por flujo y urgencia, elimina duplicados e incluye contexto y runbook. Señales informativas quedan en paneles si nadie debe actuar.
La universidad prevé un pico al inicio del período. Prepara web y bases para escalar horizontalmente y prioriza matrícula, temarios y compras. Capacidad previa y escalado por métricas deben probarse contra cuotas, límites, dependencias, retraso y costo.
Resumen del tema
Combina capacidad y escalado probados con alertas priorizadas, accionables y con propietario.
18. Prueba confiabilidad antes y dentro de producción
Ejercita fallos, modo degradado, recuperación y umbrales en preproducción y, con controles, en producción. Un ejercicio de mesa prueba decisiones; carga prueba demanda; simular el error de un componente demuestra operación degradada.
La matrícula estacional usa certificados de cliente. Transacciones sintéticas mensuales recorren el flujo y avisan de errores o expiración. El caos entra en el ciclo de desarrollo con hipótesis, alcance, parada, telemetría y resultados para validar autoprotección y descubrir acoplamiento.
Resumen del tema
Usa transacciones sintéticas y caos controlado para probar recorridos, degradación y recuperación antes de un incidente.
19. Simplifica la carga de Contoso Travel
Una empresa ficticia adquiere Node.js en VM locales y AWS. Una función de comentarios casi no se usa porque los clientes prefieren redes sociales. Cada función extra suma código, dependencias, riesgo, supervisión y soporte.
El equipo la elimina de la primera versión. La base menor reduce costo sin vulnerar requisitos. Simplificar no es quitar a ciegas: puede crear un punto único de error, así que verifica objetivos.
Resumen del tema
Conserva solo componentes justificados por resultados, sin eliminar la redundancia necesaria.
20. Estandariza el ciclo de desarrollo
El equipo usa bibliotecas solapadas, estilos inconsistentes y canalizaciones sin puertas automáticas. Las grandes versiones exigen reversión o correcciones urgentes, movilizan a todos y dañan reputación y experiencia.
Estandariza lenguajes, marcos, bibliotecas, patrones, nombres, estilo, documentación, pruebas e implementación. Formato, análisis, seguridad, regresión y puertas detectan desvíos. Documenta herramientas para revisión y solución de problemas.
Resumen del tema
Estandarizar herramientas, documentación y pruebas reduce variación y vuelve repetibles las entregas y los incidentes.
21. Prefiere capacidades administradas a carga personalizada
El equipo mueve Node.js de VM a . La instrumentación automática de reemplaza código propio; escalado automático, integración con y redundancia de zona cubren requisitos cuando están disponibles. Se reduce el código propio, pero la aplicación no se vuelve automáticamente .
La plataforma elimina código indiferenciado y conserva controles explícitos.
Resumen del tema
Usa funciones probadas de plataforma cuando cumplan el requisito y reserva ingeniería propia para valor empresarial diferenciado.
22. Revisa la decisión completa de confiabilidad
Clasifica flujos y fija objetivos medibles de disponibilidad y recuperación.
Valida , límites, cuotas, capacidad y dependencias internas y externas.
Analiza modos de error y crea autoprotección limitada y redundancia por capas.
Protege estado con copias probadas y replicación adecuada; ensaya conmutación y retorno.
Correlaciona telemetría, dirige alertas accionables y prueba degradación con sintéticos y caos.
Elimina componentes injustificados, estandariza el ciclo y prefiere capacidades administradas.
En el examen conecta requisito, modelo de error, capacidad de , evidencia de prueba y propietario operativo. Réplica, cola, sondeo o alerta solo sirve cuando satisface el objetivo y se entienden sus equilibrios.
Una arquitectura confiable es un acuerdo probado continuamente entre objetivos, resistencia, estado recuperable, operaciones observables y simplicidad disciplinada.
