La lección anterior te dio el marco que dice cómo debería estar hecha una arquitectura. Esta cubre la otra mitad del oficio, que se aprende mucho más despacio y casi siempre pagando: cómo se hacen mal. No con ejemplos abstractos, sino con el catálogo concreto de errores que aparecen una y otra vez en organizaciones de todos los tamaños, contados con su síntoma, con lo que cuesta corregirlos cuando ya están instalados y con la prevención que los habría evitado por una fracción de ese precio.

Hay una asimetría que justifica la lección entera: casi todos estos errores cuestan poco de prevenir y mucho de arreglar. Etiquetar desde el primer día es gratis; retro-etiquetar doscientos recursos son semanas de trabajo. Sacar un secreto a Key Vault antes de escribir la primera línea es media hora; hacerlo después de que haya estado seis meses en el historial del repositorio implica rotarlo, auditar accesos y no poder demostrar que nadie lo usó.

La lección recorre seis familias —coste, seguridad, arquitectura, operación, gobierno y datos—, dedica un apartado a los cuatro errores que el equipo de Contoso sí cometió durante el curso y cómo los detectó, y cierra con las señales de alarma que anticipan cada familia antes de que el problema sea visible en la factura o en un incidente.

Recordatorio: las cifras en euros son orientativas y ficticias, e ilustran órdenes de magnitud, no precios reales.

1. Por qué un catálogo de errores
2. Errores de coste
3. Errores de seguridad
4. Errores de arquitectura
5. Errores de operación
6. Errores de gobierno y organización
7. Errores con los datos
8. Los cuatro errores que Contoso sí cometió
9. Señales de alarma
10. Errores Comunes y Consejos
11. Ejercicios
12. Conclusión

Tres razones por las que estos errores se repiten en organizaciones que ya conocen la teoría:

• La nube castiga tarde. Crear una máquina sobredimensionada no falla: funciona perfectamente y la factura llega treinta días después. Lo que no da error inmediato no se corrige.
• Lo urgente desplaza a lo importante. Nadie planea dejar un secreto en el código: se deja «solo para la demo del jueves» y no vuelve a mirarse.
• El coste del error crece de forma no lineal. Una convención de nombres es trivial con diez recursos, incómoda con cien e inasumible con quinientos.
• Nadie ve el error desde dentro. El equipo que construyó el sistema ha normalizado sus rarezas; por eso las revisiones cruzadas y los catálogos como este encuentran cosas que llevan años a la vista de todos.

Por eso el patrón de las tablas siguientes es siempre el mismo: error → síntoma → coste de arreglarlo tarde → prevención. La columna que más conviene leer es la tercera.

El multiplicador depende casi por completo del momento en que se detecta:

La conclusión operativa no es «hay que ser más cuidadoso», que no es accionable: es mover la detección hacia arriba en la tabla con mecanismos automáticos —directivas, plantillas, análisis en el pipeline, listas de comprobación de diseño—.

El más caro de la lista no es ninguno en concreto: es no tener presupuesto con alerta, porque convierte cualquiera de los anteriores en un problema que se descubre un trimestre tarde.

Merece la pena ver la asimetría con números orientativos. Un disco de 512 GB huérfano cuesta del orden de 40 €/mes: pasa desapercibido. Veinte discos huérfanos acumulados durante dos años de migraciones son unos 19.000 € gastados en nada, y en ese momento nadie sabe ya de quién era cada uno, así que borrarlos exige una investigación que cuesta más horas que el propio ahorro del primer mes. El error no fue el disco: fue no tener etiqueta de propietario y no mirar nunca. La prevención habría costado una directiva y una consulta mensual de diez líneas.

Un matiz sobre el primero, que es el más frecuente: quitar el secreto del código no lo elimina del historial. Si estuvo publicado, hay que considerarlo comprometido y rotarlo, aunque el commit que lo borró parezca resolver el problema.

Y un matiz sobre el sexto, que es el que produce los incidentes más graves con menos sofisticación: los puertos de administración expuestos no los encuentra un atacante, los encuentra un escáner automático. No hace falta ser un objetivo interesante ni tener datos valiosos; basta con tener una dirección IP pública con el puerto 3389 o el 22 abiertos. Por eso la mitigación correcta nunca es «poner una contraseña más larga», sino eliminar la exposición: acceso mediante Bastion, acceso justo a tiempo o red privada, de modo que el puerto simplemente no exista desde internet.

Los dos últimos parecen opuestos y son el mismo error: no ajustar la arquitectura al problema real. Uno peca por defecto y otro por exceso, y ambos se detectan con la misma pregunta —¿qué problema concreto y medido resuelve esta pieza?—.

El acoplamiento síncrono merece un dibujo, porque es el error de arquitectura que más incidentes causa y el más fácil de no ver en un diagrama mal hecho:

En la versión acoplada, un servicio de correo lento bloquea la venta: el cliente ve un error al comprar por culpa de un componente que ni siquiera necesitaba respuesta. Es exactamente la razón por la que Contoso puso sb-contoso-pro entre la confirmación de la reserva y todo lo que ocurre después. La regla es sencilla y se aplica en el diseño, no después: si el llamante no necesita la respuesta para contestar al usuario, no debe esperarla.

De todos ellos, el segundo es el más traicionero porque parece diligencia. Un equipo que alerta de todo cree estar siendo cuidadoso, pero el efecto real es el contrario: cuando llegan doscientos avisos al día, el cerebro humano aprende a ignorarlos, y el día que llega el aviso importante ya nadie lo lee. La fatiga de alertas no se corrige explicando a la gente que mire más: se corrige borrando alertas. Un criterio útil para decidir cuáles sobreviven: una alerta debe describir un síntoma que el usuario nota y llevar asociada una acción concreta que alguien puede ejecutar a las tres de la madrugada. Si no cumple las dos cosas, es un panel, no una alerta.

Un segundo criterio, sobre el despliegue del viernes: el problema no es el día, es la asimetría entre la probabilidad de fallo y la disponibilidad de quien puede arreglarlo. Con reversión probada en segundos —una ranura, un despliegue progresivo— desplegar un viernes deja de ser peligroso. La prohibición del viernes es una tirita; el plan de reversión es la cura.

Los dos últimos están conectados y explican por qué el gobierno falla incluso cuando existe. Si crear un recurso legítimo requiere abrir un ticket y esperar cinco días, la gente encuentra la manera de saltárselo: usa la suscripción de pruebas, pide permisos temporales que nadie retira o crea a mano lo que debería ir en la plantilla. El gobierno que solo prohíbe genera evasión; el que funciona prohíbe lo peligroso y facilita lo correcto, con plantillas Bicep que ya traen las etiquetas, la red y los diagnósticos puestos. Dicho de otra forma: si el camino correcto no es también el camino fácil, la directiva perderá contra el calendario del proyecto.

Dos de estos errores tienen una propiedad que no comparten los demás: son irreversibles en la práctica. Cambiar la clave de partición de un contenedor de Cosmos DB no es una operación de configuración, es crear un contenedor nuevo y migrar los datos con la aplicación en marcha; y elegir el motor equivocado se corrige con una migración de datos en producción, que es el tipo de proyecto que consume trimestres. Todo lo demás en esta lección se arregla con dinero y tiempo; estos dos se arreglan con un proyecto. Por eso son las dos decisiones que más merecen una revisión de diseño formal antes de escribir la primera línea, con la pregunta concreta encima de la mesa: ¿cuál será la consulta más frecuente dentro de dos años, y este diseño la sirve bien?

Advertencia importante: el tratamiento de datos personales está sujeto al RGPD y a normativa sectorial. Nada de lo que aparece en este curso constituye asesoramiento legal: cualquier decisión sobre exportación, retención, anonimización o transferencia de datos personales debe revisarla el equipo legal o de cumplimiento de la organización antes de implementarse.

Ningún equipo aprende esto leyéndolo. Contoso tampoco: estos son los errores reales de la plataforma que has construido, con cómo se detectaron.

Conviene añadir un quinto que no llegó a ser un problema porque se detectó a tiempo, y que ilustra cómo funciona la prevención cuando funciona: al preparar la primera compra de compromisos, alguien propuso reservar tres años sobre el dimensionamiento vigente. Nuria pidió esperar a tener tres meses de uso estable, y la optimización posterior redujo la plataforma de 17.800 € a 12.550 €/mes. Reservar antes habría congelado durante tres años un tamaño que resultó estar un 29 % por encima del necesario. La única razón por la que no fue un error es que existía una regla escrita —optimizar antes de comprometerse— y alguien con autoridad para invocarla.

Lo que tienen en común los cuatro: ninguno fue una mala elección técnica. Cosmos, SQL, App Service y Service Bus eran las piezas correctas. Lo que falló fue el orden y la ausencia de un mecanismo que avisara pronto: presupuesto, informe mensual, directiva, plantilla. Es la lección más transferible de este módulo.

Y una consulta que conviene tener a mano, la que Marta ejecuta cada mes para que el tercer error no vuelva:

Cada familia de errores emite señales antes de convertirse en incidente o en factura. Estas son las que conviene vigilar:

Hay además tres señales transversales, que no pertenecen a ninguna familia y que suelen preceder a problemas de varias a la vez:

• El miedo a desplegar. Si el equipo pospone los despliegues o los agrupa en entregas grandes «para no arriesgar», la causa real es que no hay reversión fiable. Predice incidentes largos.
• La persona imprescindible. Si hay una tarea que solo sabe hacer una persona, esa tarea no está automatizada ni documentada. Predice problemas de operación en cuanto haya vacaciones o una baja.
• La respuesta «eso lo revisamos después». Repetida tres veces sobre el mismo asunto, describe una decisión tomada por omisión. Predice deuda en el pilar que se esté posponiendo, sea cual sea.

Regla general que resume las seis: cuando la respuesta a «¿por qué está esto así?» es «no lo sé» o «siempre ha estado así», hay deuda. No siempre urgente, pero siempre real, y siempre más barata de pagar hoy que dentro de un año.

Sobre el uso de este catálogo, que también tiene su forma de salir mal:

• Usar la lista para señalar culpables. Un catálogo de errores sirve para prevenir, no para auditar personas; en cuanto se convierte en arma, nadie vuelve a reconocer un problema.
• Intentar corregirlo todo a la vez. Prioriza por consecuencia y por coste de corrección: primero lo catastrófico y barato de arreglar.
• Confundir un error con un compromiso. No tener multirregión activo-activo no es un error si está escrito y decidido; sí lo es si nadie lo ha pensado nunca.
• Corregir el caso y no la causa. Borrar el disco huérfano no evita el siguiente; la consulta mensual y la etiqueta obligatoria, sí.
• Prevenir solo con documentación. Lo que se puede impedir con una directiva o una plantilla no debería depender de que alguien recuerde leer una guía.
• Consejo: cuando algo falle, pregunta «¿qué mecanismo lo habría detectado antes?» en lugar de «¿quién lo hizo?». La primera pregunta produce mejoras; la segunda, silencio.
• Consejo: mantén un registro de incidentes y errores propios con la corrección aplicada. Es más útil para tu organización que cualquier lista general, incluida esta.
• Consejo: revisa este catálogo entero una vez al año con el equipo, marcando cada fila en verde, ámbar o rojo. Suele salir alguna sorpresa.
• Consejo: cuando entres en una organización nueva, empieza por cuatro comprobaciones que caben en una mañana y detectan la mayor parte de la deuda grave: ¿se ha restaurado alguna copia?, ¿hay secretos en los repositorios?, ¿quién tiene propietario permanente?, ¿existe presupuesto con alerta? Las respuestas dibujan el resto del mapa.

Ejercicio 1. Una empresa te contrata para revisar su plataforma en Azure y encuentras: una suscripción única con producción y pruebas, tres personas con papel de propietario permanente, secretos en la configuración de las aplicaciones, sin etiquetas, sin presupuesto, copias configuradas pero nunca restauradas, RDP abierto en dos máquinas de administración y una factura de 9.000 €/mes que nadie sabe explicar. Prioriza las intervenciones: ordena los problemas por consecuencia potencial dividida por coste de corrección, justifica el orden y define qué harías en la primera semana, en el primer mes y en el primer trimestre.

Ejercicio 2. Analiza los cuatro errores que cometió Contoso y responde: para cada uno, ¿qué mecanismo concreto —directiva, alerta, plantilla, revisión o consulta— lo habría detectado en la primera semana en lugar de meses después? Después, generaliza: propón el conjunto mínimo de cinco mecanismos que instalarías el primer día de cualquier plataforma nueva para que estos errores no puedan durar.

Ejercicio 3. Un equipo propone migrar su aplicación a AKS porque «así estamos preparados para escalar». La aplicación es un monolito con estado en sesión, 300 usuarios internos, sin picos, desplegado hoy en dos máquinas virtuales. Identifica todos los errores de esta lección que la propuesta contiene o provocaría, formula las preguntas que harías al equipo y propón la alternativa que defenderías, con su justificación por pilares.

Solución 1: el criterio de orden es consecuencia potencial dividida entre coste de corrección, no gravedad teórica. Primera semana —catastrófico y barato—: (1) restaurar una copia en un entorno aparte, porque «copias nunca probadas» equivale a no tener copias y la comprobación cuesta horas; (2) cerrar RDP en las dos máquinas y sustituirlo por Bastion o acceso justo a tiempo, porque un puerto de administración expuesto se explota de forma automatizada y el cierre es inmediato; (3) crear un presupuesto con alertas sobre la factura de 9.000 €, que se hace en diez minutos y detiene el crecimiento a ciegas; (4) activar MFA si no lo estuviera. Primer mes —alto impacto, esfuerzo medio—: (5) sacar los secretos a Key Vault con identidades administradas, empezando por los de producción, con rotación posterior porque deben considerarse comprometidos; (6) reducir los propietarios permanentes a uno de emergencia y pasar el resto a papeles mínimos con PIM; (7) implantar etiquetas obligatorias por directiva y etiquetar lo existente, sin lo cual no se puede empezar a explicar la factura; (8) revisar las cinco partidas mayores de la factura y buscar huérfanos e infrautilización con Advisor y Resource Graph. Primer trimestre —estructural—: (9) separar producción y no producción en dos suscripciones bajo grupos de administración, con la iniciativa de gobierno asignada; (10) pipeline de despliegue con reversión; (11) alertas y panel mínimo de observabilidad; (12) documentar el plano y las decisiones. Justificación del orden: lo de la primera semana evita pérdidas irreversibles —datos, compromiso de identidad— con coste casi nulo; lo del mes elimina las exposiciones más probables; lo del trimestre corrige la estructura, que es lo caro y lo que exige coordinación.

Solución 2: mecanismos que habrían detectado cada error en días. Factura duplicada: un presupuesto con alerta al 80 % sobre la estimación de 8.500 € habría disparado un aviso en las primeras semanas, más la detección de anomalías de Cost Management; el problema no fue estimar mal —estimar mal es normal—, fue no tener un mecanismo que comparara estimación con realidad de forma continua. VM sobredimensionada: una revisión mensual de Advisor con dueño asignado, o una alerta de métrica sobre CPU media por debajo de un umbral durante 14 días; también habría bastado una fecha de caducidad por etiqueta en los recursos creados como prueba. Falta de etiquetas: una directiva en modo denegar sobre centro-coste y propietario en el grupo de administración raíz, más la consulta mensual de Resource Graph del apartado 8; la clave es que la directiva actúa en el momento de la creación, cuando corregir cuesta cero. Orden invertido: un bloqueo de creación manual en producción —permisos de escritura solo para la conexión de servicio del pipeline— convierte el error en imposible en lugar de en detectable. Conjunto mínimo de cinco mecanismos para el primer día de cualquier plataforma: (1) jerarquía de suscripciones con una iniciativa de directivas que exija etiquetas, restrinja regiones, prohíba blobs públicos y obligue a HTTPS; (2) presupuesto con alertas y detección de anomalías; (3) identidades administradas y almacén de secretos como norma, con análisis de secretos en el pipeline; (4) infraestructura como código con despliegue exclusivo por pipeline, sin permisos de escritura manuales en producción; (5) observabilidad mínima con copias probadas: un área de Log Analytics, tres alertas accionables y una restauración de prueba agendada. Con esos cinco, ninguno de los cuatro errores de Contoso puede durar más de una semana.

Solución 3: errores presentes o provocados. Elegir Kubernetes por moda —el motivo declarado, «estar preparados para escalar», no describe ningún problema medido: 300 usuarios internos y sin picos—. Monolito con estado que no escala: la sesión en memoria significa que el escalado horizontal no funciona hoy, así que AKS no resolvería nada; se pagaría el clúster para seguir con una sola instancia útil. Sobrearquitecturar: complejidad de operación —actualizaciones del clúster, redes, cuotas, RBAC de Kubernetes, observabilidad propia— para una carga trivial. Errores de operación derivados: nadie en el equipo opera Kubernetes hoy, de modo que se añade un punto de fallo cuya recuperación depende de conocimiento que no existe. Coste: el clúster con nodos permanentes casi con seguridad cuesta más que las dos máquinas actuales. Preguntas al equipo: ¿qué problema medido resuelve esto —latencia, indisponibilidad, coste, tiempo de entrega—? ¿Qué escalado se prevé y con qué dato de crecimiento? ¿Dónde vive hoy la sesión y quién la va a sacar del proceso? ¿Quién operará el clúster, hará las actualizaciones y estará de guardia? ¿Cuánto cuesta la propuesta al mes frente a la situación actual? Alternativa que defendería: contenerizar la aplicación y desplegarla en App Service o Container Apps, después de sacar el estado de sesión a un almacén externo. Justificación por pilares: fiabilidad, permite varias instancias de verdad y redundancia de zona sin operar nada; excelencia operativa, despliegue con ranura y reversión inmediata, sin actualizaciones de clúster; coste, una fracción del de AKS y con escalado a cero en Container Apps si la carga es interna y horaria; rendimiento, autoescalado suficiente para un crecimiento de un orden de magnitud; seguridad, menos superficie que administrar. Y la observación decisiva: el trabajo valioso de la propuesta —sacar el estado de la sesión— es exactamente el mismo en ambos caminos, así que conviene hacerlo primero y decidir el destino después, con datos.

Ya tienes el catálogo honesto de lo que sale mal, organizado en seis familias y presentado siempre con la misma estructura —error, síntoma, coste de arreglarlo tarde y prevención—, porque la columna del coste es la que convence a una organización de actuar antes. En coste: dimensionar por el pico, huérfanos, no etiquetar, reservar antes de estabilizar, la salida de datos y la ingesta de registros sin control. En seguridad: secretos en el código, propietario para todos, blobs públicos, secretos sin rotar, MFA opcional, puertos de administración abiertos y el panel de Defender que nadie mira. En arquitectura: el lift-and-shift eterno, el monolito con estado, el punto único de fallo, el acoplamiento síncrono, Kubernetes por moda, no diseñar para el fallo y su gemelo opuesto, sobrearquitecturar. En operación: no monitorizar, alertar de todo, no probar las copias, no documentar, el despliegue manual del viernes y la ausencia de plan de reversión. En gobierno: sin convenciones, sin política, suscripción única, permisos temporales eternos y nadie dueño del coste. Y en datos: el motor elegido por costumbre, la clave de partición que en Cosmos DB ya no se cambia, el crecimiento no planificado, la ausencia de ciclo de vida y los datos personales tratados sin base legal —con la advertencia de que eso lo valida el equipo legal, no el equipo técnico—.

Has visto los cuatro errores que Contoso sí cometió —la factura duplicada de 8.500 a 17.500 €, la máquina de desarrollo un año al 3 %, las etiquetas que llegaron tarde y el orden invertido entre recursos y gobierno— con la forma exacta en que se detectaron y lo que tienen en común: ninguno fue una mala elección técnica; fue falta de mecanismo y de orden. Y te llevas las señales de alarma por familia, con la regla que las resume: cuando la respuesta a «¿por qué está esto así?» es «siempre ha estado así», hay deuda esperando.

Queda un asunto que este módulo ha ido rodeando y que no es técnico: Contoso todavía tiene sistemas en Barcelona. La facturación heredada, el directorio local y el mantenimiento de flota siguen en un centro de datos con contrato a punto de vencer, y moverlos no es un proyecto de infraestructura: es un cambio organizativo. La siguiente lección aborda cómo se migra una organización entera con el Cloud Adoption Framework —estrategia, plan, preparación, adopción y gobierno—, con Azure Migrate para el inventario, las seis estrategias de migración, las zonas de aterrizaje, las oleadas y su ventana de corte, la migración de los datos, la vuelta atrás, la gestión del cambio y la retirada del centro de datos con sus costes ocultos.