Operational Excellence, Reliability and Customer Care

Resumen

La excelencia operativa es el pilar que convierte la infraestructura cloud en un servicio de negocio confiable. No se trata de tener más herramientas, sino de operar con disciplina: cambiar sin romper, detectar antes de que el cliente lo note, recuperarse con objetivos claros y mejorar cada vez que algo falla. Google Cloud enmarca ese pilar dentro de su Architecture Framework y lo expresa con un vocabulario preciso que el examen evalúa directamente: resiliencia, tolerancia a fallos, alta disponibilidad, recuperación ante desastres, DevOps, Site Reliability Engineering (SRE), indicadores de nivel de servicio (SLI), objetivos (SLO) y acuerdos (SLA).

El SRE es la metodología con la que Google opera sus propios sistemas a escala y que Google Cloud traslada a sus clientes. Su idea central es traducir la confiabilidad en un lenguaje cuantitativo: se definen SLI (lo que se mide), se fija un SLO (lo que se compromete internamente) y se publica un SLA (lo que se acuerda con el cliente, con consecuencias económicas si se incumple). Entre medias, el error budget convierte la fiabilidad en una moneda negociable entre producto e ingeniería: si el presupuesto de errores se agota, se frena el despliegue; si queda holgado, se puede innovar con ritmo.

A la fiabilidad se suma la relación con Google Cloud Customer Care. En un modelo gestionado, el proveedor absorbe la operación de la infraestructura, pero la organización sigue siendo responsable de sus aplicaciones y de su configuración; cuando surge un problema que no se puede resolver con documentación o monitoreo, se abre un caso de soporte y se gestiona hasta la resolución. Saber cómo funciona ese ciclo —y qué información aportar en cada momento— acelera la resolución y reduce el impacto del incidente.

Al finalizar este tema sabrás argumentar qué significa operar con excelencia en la nube, diseñar objetivos de disponibilidad medibles, distinguir un SLI de un SLO y de un SLA, explicar cómo el error budget gobierna el ritmo de cambio y describir el ciclo de vida de un caso con Google Cloud Customer Care.

Objetivos de Aprendizaje

Al terminar este contenido, serás capaz de:

Explicar cómo la modernización de operaciones con Google Cloud cambia el trabajo del equipo: menos operación manual, más automatización, observabilidad y gestión por políticas.
Definir los términos centrales de operaciones cloud: resiliencia, tolerancia a fallos, alta disponibilidad, disaster recovery, RTO, RPO, MTTR y observabilidad.
Argumentar por qué la infraestructura resiliente y fault-tolerant exige redundancia distribuida y no simplemente más capacidad en un único punto.
Comparar estrategias de recuperación ante desastres y relacionarlas con los objetivos de RTO y RPO definidos por el negocio.
Explicar DevOps y su relación con el Site Reliability Engineering como práctica operacional y cultural.
Distinguir SLI, SLO y SLA, e indicar la consecuencia práctica de cada uno para negocio, ingeniería y cliente.
Describir el concepto de error budget y su uso como mecanismo de gobernanza del cambio.
Reconocer el ciclo de vida de un caso de soporte con Google Cloud Customer Care, desde la apertura hasta el cierre, incluyendo severidad, intercambio de información y escalado.
Seleccionar fuentes de información y herramientas de respuesta ante incidentes (monitoreo, logs, paneles, service health) para un caso de negocio dado.
Evaluar la madurez operativa de una organización cloud mediante señales observables: métricas de SLI, frecuencia de incidentes, tiempo de recuperación y calidad de los postmortems.

Contenido Principal

Subtema 1: Modernización de operaciones y vocabulario de operaciones cloud

La modernización de operaciones con Google Cloud consiste en sustituir la operación manual —provisionar a mano, desplegar en ventanas nocturnas, revisar servidores uno a uno— por un modelo donde la infraestructura es declarativa, el despliegue es automatizado, la observabilidad es nativa y los cambios se aplican con frecuencia y bajo control. Los servicios gestionados transfieren al proveedor la operación del hardware y de la plataforma, y liberan al equipo para construir, automatizar y gobernar.

El vocabulario que el examen evalúa y que toda conversación operativa usa:

Término	Definición operativa	Ejemplo en Google Cloud
Resiliencia	Capacidad de absorber fallos y seguir operando	Distribuir entre zonas con balanceo
Tolerancia a fallos (fault tolerance)	Seguir funcionando ante el fallo de un componente, sin interrupción perceptible	Réplicas en varias zonas y failover automático
Alta disponibilidad (HA)	Disponibilidad elevada del servicio ante el tiempo	Grupos de instancias con balanceo y salud configurable
Disaster recovery (DR)	Restauración del servicio tras un desastre regional o de sitio	Réplicas en otra región y planes de restauración
RTO (Recovery Time Objective)	Tiempo máximo aceptable para restaurar el servicio	Definido por el negocio por aplicación
RPO (Recovery Point Objective)	Pérdida máxima aceptable de datos (medida en el tiempo)	Definida por la tolerancia a pérdida de datos
MTTR (Mean Time To Recover)	Tiempo medio de recuperación real	Métrica histórica del equipo
Observabilidad	Capacidad de entender el estado del sistema con sus datos	Métricas, logs, trazas y dashboards
Incidente	Evento que degrada o interrumpe el servicio	Alerta que dispara respuesta coordinada
Toil	Trabajo manual repetitivo sin valor sostenido	Provisiones y correcciones manuales recurrentes

Dos distinciones frecuentes:

Resiliencia frente a tolerancia a fallos. La resiliencia es el objetivo sistémico (sobrevivir al fallo); la tolerancia a fallos es el atributo de diseño que permite seguir operando cuando un componente cae. Un sistema resiliente puede degradarse momentáneamente; un sistema fault-tolerant no debería interrumpirse por un fallo simple.
Alta disponibilidad frente a recuperación ante desastres. La alta disponibilidad gestiona fallos frecuentes y acotados (un nodo, una zona) manteniendo el servicio; la recuperación ante desastres gestiona eventos poco frecuentes y de gran alcance (una región, un corte de red) donde el servicio puede interrumpirse y debe restaurarse.

Subtema 2: Infraestructura resiliente y fault-tolerant

La infraestructura resiliente se diseña asumiendo que los componentes fallan. Google Cloud lo hace posible con una topología de regiones y zonas, con balanceadores de carga que enrutan según salud, con grupos de instancias administradas que reemplazan nodos defectuosos y con servicios gestionados que distribuyen la carga internamente.

Principios de diseño con impacto de negocio:

Distribuir el fallo. Repartir entre zonas dentro de una región para fallos locales; entre regiones para fallos regionales. La redundancia en una sola zona no protege de un fallo de zona.
Sin puntos únicos de fallo. Base de datos única, balanceador único o pipeline único de despliegue concentran el riesgo; cada punto único debe identificarse explícitamente y aceptarse o eliminarse.
Recuperación automática donde sea posible. Grupos de instancias administradas, health checks y autoscaling reemplazan capacidad defectuosa sin intervención humana, reduciendo el MTTR.
Desacoplamiento. Colas, buffers y mensajería evitan que un fallo en un servicio se propague en cascada al resto de la cadena.
Presupuesto de fallos en el diseño. Toda arquitectura impone restricciones (latencia, coste, complejidad); la decisión explícita de qué fallos se toleran y cuáles no es una decisión de negocio, no solo técnica.

Objetivo	Escenario cubierto	Mecanismo típico	Compromiso de coste
Tolerancia a fallo de instancia	Caída de una máquina	Réplicas detrás de balanceador	Bajo
Tolerancia a fallo de zona	Caída de una zona de la región	Distribución multi-zona	Medio
Tolerancia a fallo de región	Caída o indisponibilidad de una región	Multi-región activa	Alto
Recuperación ante desastres	Pérdida de capacidad sostenida en un sitio	Réplicas de respaldo y restauración	Según RTO/RPO

El error de diseño más costoso no es olvidar redundancia: es asumir que la redundancia existe sin haberla probado. Los ejercicios de recuperación (restaurar un backup en un entorno separado, forzar el failover de una región, simular la caída de un clúster) son la única evidencia creíble de que el RTO y el RPO declarados se cumplen.

Ejemplo Práctico

Inspeccionar la configuración de resiliencia de las instancias existentes: distribución de zonas, reinicio y mantenimiento programado:

gcloud compute instances list \
  --format="table(name, zone, status, scheduling.automaticRestart, scheduling.onHostMaintenance)"
gcloud compute regions list --format="table(name, status, zones)"

Y comprobar la presencia de grupos de instancias administradas, que es la señal habitual de un diseño que reemplaza capacidad defectuosa de forma automática:

gcloud compute instance-groups list --format="table(name, region, zone, size)"

Un inventario con instancias repartidas en una sola zona, sin grupos administrados y sin balanceador es la evidencia de que la disponibilidad declarada no está respaldada por arquitectura; ese hallazgo se traduce en una conversación de riesgo con negocio, no en un informe técnico de infraestructura.

Subtema 3: Alta disponibilidad y disaster recovery

El negocio define la disponibilidad que necesita; la arquitectura la traduce en decisiones de redundancia y de recuperación. Los objetivos de negocio se expresan en RTO y RPO, y cada estrategia de recuperación ocupa un punto en el eje entre tiempo de restauración y coste.

Estrategia de DR	Qué se mantiene listo	RTO típico	RPO típico	Coste
Backup y restauración	Copias en almacenamiento	Horas o más	Según frecuencia de backup	El más bajo
Pilot light	Réplica mínima apagada o mínima en la región de respaldo	Minutos a horas	Minutos	Bajo-medio
Warm standby	Réplica reducida pero operativa	Minutos	Segundos a minutos	Medio
Multi-site (activo-activo)	Capacidad completa en varios sitios	Inmediato	Segundos	El más alto

Tres observaciones para una conversación de negocio:

El coste de la disponibilidad no es lineal. Pasar de warm standby a activo-activo puede multiplicar el coste de infraestructura para reducir un RTO que quizá el negocio no exige. La pregunta correcta es cuánto cuesta la indisponibilidad por minuto, no cuál es la arquitectura más robusta posible.
RPO es una decisión de pérdida de datos. Un RPO de una hora significa aceptar perder hasta una hora de transacciones en el peor escenario. Esa cifra la fija negocio, con inputs de regulación, de cliente y de impacto económico.
El DR se prueba, no se documenta. Un plan de DR no validado con ejercicios periódicos es una hipótesis. La excelencia operativa exige medir el tiempo real de recuperación y compararlo con el objetivo.

El Disaster Recovery de Google Cloud y el Architecture Framework de fiabilidad son la referencia para construir estos planes sobre los servicios disponibles: replicación entre regiones, opciones de respaldo de bases de datos gestionadas, y patrones de restauración para almacenamiento y cómputo.

Ejemplo Práctico

Verificar la ubicación y la configuración de los almacenes que sostienen los datos de respaldo, base de cualquier plan de restauración:

gcloud storage buckets list --format="table(name, location, locationType, storageClass)"

Y revisar la política de ciclo de vida aplicada, que determina cuánto tiempo se retienen las copias y a qué clase de almacenamiento transicionan:

gcloud storage buckets describe gs://BUCKET_NAME --format="json(lifecycle.rules)"

Para negocio, el resultado responde a dos preguntas: si las copias existen en una ubicación distinta del entorno productivo (una copia en la misma región no protege de un desastre regional) y si la retención es coherente con el RPO declarado. Una política de ciclo de vida ausente o demasiado corta convierte el plan de DR en una promesa que no se puede cumplir.

Subtema 4: DevOps, SRE, SLI, SLO y SLA

DevOps es un movimiento cultural y práctico que une desarrollo y operaciones para entregar valor con frecuencia y fiabilidad: integración y despliegue continuos, automatización, infraestructura como código y responsabilidad compartida sobre el sistema en producción. No es una herramienta ni un puesto; es una forma de trabajar.

El Site Reliability Engineering (SRE) es la aproximación con la que Google opera sus sistemas y que se materializa como disciplina dentro de DevOps. Su aporte distintivo es convertir la confiabilidad en un sistema cuantitativo:

SLI (Service Level Indicator). La métrica que mide el nivel de servicio real: disponibilidad, latencia percentil, tasa de error, throughput. Sin SLI definido, no hay forma objetiva de discutir fiabilidad.
SLO (Service Level Objective). El compromiso interno sobre el valor que el SLI debe mantener en una ventana de tiempo (por ejemplo, disponibilidad o latencia en un mes). Es la línea que gobierna decisiones internas de producto e ingeniería.
SLA (Service Level Agreement). El acuerdo contractual con el cliente, que suele incluir consecuencias económicas o creditos si se incumple. Un SLA se define siempre por encima del SLO: la organización no debe vivir pegada al límite de su contrato.
Error budget. El margen de indisponibilidad o de errores que el SLO permite. Si se consume, se frena el ritmo de despliegue hasta recuperar fiabilidad; si queda holgado, se puede acelerar. Es el mecanismo que hace negociables la innovación y la estabilidad en la misma mesa.

Concepto	Pregunta	Audiencia	Consecuencia si se incumple
SLI	¿Cómo medimos el servicio?	Ingeniería	No hay señal de calidad
SLO	¿Qué nivel interno exigimos?	Producto e ingeniería	Cambio de ritmo de despliegue
SLA	¿Qué prometimos contractualmente al cliente?	Cliente y negocio	Consecuencias contractuales
Error budget	¿Cuánto margen de error queda?	Producto e ingeniería	Freno o aceleración del despliegue

Tres prácticas que acompañan a estos conceptos y que el examen asocia al SRE:

Postmortems sin culpa. Tras un incidente se documenta la secuencia de causa raíz, se identifican acciones correctivas y se comparte el aprendizaje; el objetivo es mejorar el sistema, no identificar culpables.
Gestión del cambio con frecuencia. Los despliegues pequeños y frecuentes son más fáciles de diagnosticar y revertir que los despliegues grandes y poco frecuentes; el error budget regula el ritmo, no lo elimina.
Reducción de toil. Cada tarea manual repetitiva que se automatiza reduce errores humanos y libera capacidad del equipo para trabajar en fiabilidad y en producto.

La combinación de estas prácticas con los indicadores produce el ciclo que distingue a una organización madura: se mide, se fija un objetivo, se despliega dentro del presupuesto de errores, se responde a los incidentes y se aprende del análisis posterior.

La relación con operaciones es directa: los SLI se alimentan de la observabilidad (métricas, logs y trazas), los SLO se revisan con cadencia, y los incidentes se gestionan con procesos de respuesta, comunicación y mejora (postmortems sin culpa). La madurez operativa se mide, entre otras señales, por la calidad de esos postmortems y por la reducción del MTTR a lo largo del tiempo.

Ejemplo Práctico

Revisar las políticas de alerting activas, que son la traducción operativa de los SLI definidos:

gcloud monitoring alert-policies list \
  --format="table(name, displayName, enabled, conditionDisplayName)"

Y verificar los checks de disponibilidad que sostienen el SLI de disponibilidad de un servicio:

gcloud monitoring uptime list --format="table(name, displayName, resource.label.hostName)"

Una organización madura no tiene alertas por métricas de infraestructura aisladas, sino alertas conectadas a los SLI del servicio que el negocio valora. Si el listado solo muestra alertas de CPU y disco, la señal de negocio (latencia, tasa de error, disponibilidad del flujo de compra, por ejemplo) probablemente no esté cubierta, y el SLO no se estará midiendo.

Subtema 5: Google Cloud Customer Care y ciclo de vida de un caso

Google Cloud Customer Care es el soporte profesional que acompaña a la plataforma. En el modelo de responsabilidad compartida, el proveedor opera la infraestructura y los servicios gestionados, mientras el cliente es responsable de sus aplicaciones, datos y configuración. Customer Care cubre ese límite: ayuda a diagnosticar problemas de uso, de configuración y de plataforma, y da acceso a ingenieros de soporte cuando el caso lo requiere.

Qué ofrece, en términos de negocio:

Canales de soporte según el plan contratado, con niveles de respuesta que escalan desde el soporte básico hasta planes superiores con atención prioritaria.
Casos de soporte como unidad de trabajo: cada problema se abre, se clasifica, se asigna, se actualiza y se cierra con una resolución documentada.
Recursos de autoservicio: documentación, flujos guiados de diagnóstico y estado del servicio, que resuelven una parte alta de los problemas sin abrir un caso.
Salud del servicio y comunicación proactiva sobre eventos que puedan afectar al entorno del cliente.

Ciclo de vida habitual de un caso:

Apertura. Se describe el problema, el impacto de negocio, el alcance (proyectos, regiones, servicios afectados), el momento de inicio, los cambios recientes y la evidencia recogida (mensajes de error, IDs de recursos, ventanas temporales).
Clasificación. Se asigna prioridad o severidad en función del impacto: un servicio de producción caído no se gestiona igual que una consulta de configuración.
Análisis y diagnóstico. El equipo de soporte trabaja con la información aportada; la velocidad de avance depende directamente de la calidad del contexto inicial.
Actualizaciones e intercambio. El caso avanza con preguntas y respuestas; mantener el hilo en el canal del caso, y no en correos paralelos, preserva el historial y habilita el escalado.
Resolución o escalado. Si el caso requiere intervención del equipo de producto o de ingeniería de Google, se escala manteniendo el mismo caso.
Cierre y revisión. Se confirma la resolución, se documenta el resultado y, en incidentes relevantes, se extraen lecciones para el entorno del cliente.

La lección de negocio: la calidad de la información inicial es la palanca más barata para reducir el tiempo de resolución. Un caso abierto con impacto cuantificado, recursos identificados y pasos de diagnóstico ya ejecutados se resuelve más rápido que un caso abierto con "la factura subió y no sabemos por qué".

Fase	Aporta el cliente	Aporta Customer Care	Resultado
Apertura	Contexto, impacto, evidencia	Registro y clasificación	Caso con alcance definido
Diagnóstico	Datos adicionales, acceso a logs	Análisis y pruebas	Causa identificada
Escalado	Validación de hipótesis	Intervención de ingeniería	Solución o workaround
Cierre	Confirmación de resolución	Documentación del caso	Lección incorporada

Ejemplo Práctico

Revisar la configuración de alertas y los errores recientes antes de abrir un caso, para llegar con evidencia:

gcloud logging read 'severity>=ERROR AND timestamp>="-24h"' \
  --limit=20 \
  --format="table(timestamp, resource.type, logName, textPayload)"

Y comprobar el estado reciente de las políticas de alerta, que suelen ser la primera pista del origen:

gcloud monitoring alert-policies list --filter="enabled" \
  --format="table(name, conditionDisplayName, enabled)"

Con esa información —ventana temporal del error, servicios afectados, cambios recientes en despliegues o configuración— el caso se abre con contexto suficiente. La regla operativa es invertir diez minutos en diagnóstico previo antes de abrir el caso: casi siempre reducen horas de intercambio posterior.

Temas relacionados: Cloud Financial Governance and Cost Management, Cost Optimization and Recommender, Sustainability with Google Cloud.

Errores Comunes

Error: Usar los términos SLI, SLO y SLA como si fueran intercambiables. → Solución: Recordar que el SLI mide, el SLO es el compromiso interno que gobierna decisiones, y el SLA es el acuerdo contractual con el cliente, siempre con margen respecto al SLO.
Error: Creer que la alta disponibilidad sustituye a la recuperación ante desastres. → Solución: La HA gestiona fallos frecuentes y acotados manteniendo el servicio; la DR gestiona eventos de gran alcance que pueden interrumpirlo. Los dos planes se diseñan y se prueban por separado, con objetivos distintos.
Error: Declarar RTO y RPO sin haberlos probado con ejercicios de recuperación. → Solución: Ejecutar pruebas periódicas de restauración y de failover, medir el tiempo real y ajustar objetivos o arquitectura; un plan de DR no validado es una hipótesis, no una garantía.
Error: Confundir DevOps con un conjunto de herramientas de despliegue o con un puesto llamado "ingeniero DevOps". → Solución: Tratarlo como cultura y práctica compartida; el SRE aporta la cuantificación de la confiabilidad (SLI/SLO/SLA y error budget) dentro de esa cultura.
Error: Abrir un caso de soporte con descripciones vagas y sin evidencia de diagnóstico previo. → Solución: Aportar impacto de negocio, alcance, ventana temporal, recursos afectados, errores capturados y cambios recientes; la calidad del contexto inicial acelera la resolución y facilita el escalado cuando es necesario.

Puntos para el Examen

🎯 Punto clave 1: La resiliencia, la tolerancia a fallos, la alta disponibilidad y la recuperación ante desastres abordan escenarios distintos. La pregunta típica describe un fallo (una zona, una región, un backup) y pide el concepto o el mecanismo correspondiente; la respuesta correcta depende del alcance del fallo y del tiempo de recuperación exigido.

🎯 Punto clave 2: SLI, SLO y SLA forman una cadena: el SLI es la métrica, el SLO es el objetivo interno y el SLA es el compromiso contractual con el cliente. El error budget es el margen que el SLO permite y que gobierna el ritmo de despliegue cuando se consume.

🎯 Punto clave 3: El SRE es la práctica que cuantifica la confiabilidad y la gestiona como presupuesto compartido entre producto e ingeniería. No es un sinónimo de DevOps: lo sitúa dentro, añadiendo disciplina de medición, objetivos y presupuesto de errores.

🎯 Punto clave 4: RTO y RPO se definen por el negocio, no por ingeniería: el primero mide tiempo de indisponibilidad aceptable, el segundo pérdida máxima aceptable de datos. Cada estrategia de recuperación (backup, pilot light, warm standby, multi-site) ocupa un punto distinto entre coste y rapidez.

🎯 Punto clave 5: El ciclo de un caso con Google Cloud Customer Care va de la apertura con evidencia, pasando por clasificación y diagnóstico, hasta el escalado y el cierre. La variable que más influye en el tiempo de resolución es la calidad de la información aportada al abrirlo.

Recursos Externos

Operational excellence en el Architecture Framework — Principios de diseño y operación de cargas cloud.
Fiabilidad en el Architecture Framework — Patrones de resiliencia, redundancia y disponibilidad.
Disaster Recovery en Google Cloud — Estrategias de recuperación y su relación con RTO y RPO.
Google Cloud Customer Care — Soporte profesional, canales y gestión de casos.
Site Reliability Engineering books — Fundamentos del SRE, incluyendo SLI, SLO, SLA y error budget.

Autoevaluación Rápida

Pregunta: ¿Qué diferencia hay entre un SLI, un SLO y un SLA, y por qué importa para el negocio? Respuesta: El SLI es la métrica que mide el servicio (por ejemplo, latencia o disponibilidad); el SLO es el objetivo interno que fija el nivel aceptable y gobierna decisiones de despliegue; el SLA es el compromiso contractual con el cliente, con consecuencias económicas si se incumple. Importa porque confundirlos lleva a prometer al cliente el nivel interno (sin margen) o a no medir nada; la práctica sana es fijar el SLO con holgura respecto al SLA.
Pregunta: El negocio exige que la aplicación esté disponible en un máximo de quince minutos tras un desastre y no perder más de cinco minutos de datos. ¿Qué conceptos están definiendo y cómo se traducen? Respuesta: Están definiendo RTO (quince minutos de tiempo de restauración) y RPO (cinco minutos de pérdida de datos aceptable). Esos objetivos orientan la elección de estrategia de recuperación: un RTO corto y un RPO muy exigente suelen alejar la decisión del simple backup y acercarla a replicación activa o a warm standby/multi-site, con el coste asociado que implica.
Pregunta: Tras un despliegue se consumió la totalidad del error budget de un servicio. ¿Qué debe pasar y por qué? Respuesta: Debe frenarse o detenerse el ritmo de despliegues hasta recuperar fiabilidad, porque el error budget es el margen que el SLO permite y su agotamiento indica que el servicio está al límite de lo comprometido. La decisión es de producto e ingeniería conjuntamente: priorizar estabilidad frente a nuevas funciones hasta reconstruir el presupuesto.
Pregunta: Un equipo tiene alertas de CPU, disco y memoria, pero no mide latencia ni tasa de error del servicio de compra. ¿Qué le falta? Respuesta: Le faltan SLI conectados al nivel de servicio que el negocio valora. Las métricas de infraestructura no capturan la experiencia del usuario; sin SLI de disponibilidad, latencia o errores, no puede fijar un SLO, ni detectar degradaciones relevantes, ni sostener un SLA. La acción es definir los SLI del flujo de negocio y construir alertas sobre ellos.
Pregunta: ¿Qué información conviene aportar al abrir un caso con Google Cloud Customer Care y por qué? Respuesta: Impacto de negocio cuantificado, alcance (proyectos, regiones, servicios), hora de inicio, recursos afectados, errores capturados, cambios recientes de despliegue o configuración y pasos de diagnóstico ya ejecutados. Ese contexto reduce el intercambio inicial, permite clasificar correctamente el caso y acelera el escalado si hace falta; un caso abierto sin evidencia obliga a reconstruir el diagnóstico desde cero.