Semana 9 · Módulo 9 de 12

Fiabilidad y operaciones — Well-Architected, alta disponibilidad, DR, SRE y observabilidad

Aprenderás a diseñar sistemas que sigan funcionando cuando algo falla (alta disponibilidad y recuperación ante desastres), a medir la fiabilidad como lo hace Google (SLI, SLO, presupuesto de errores) y a operar en producción con Google Cloud Observability. Es el bloque que conecta el apartado 1.2 con toda la sección 6 del examen.

Reparto de la semana

Por qué importa

El examen no pregunta «¿qué es un SLO?». Pregunta cosas como: «La aplicación de pedidos debe tolerar la caída de una zona, el negocio acepta perder como mucho 5 minutos de datos y recuperarse en una hora, y el presupuesto es ajustado: ¿qué diseñas?». Para contestar necesitas tres herramientas mentales:

1. Traducir requisitos de negocio a números: disponibilidad (99,9 % frente a 99,99 %), RTO, RPO, latencia.
2. Conocer qué ofrece cada servicio: qué es zonal, qué es regional, qué se replica solo y qué tienes que replicar tú.
3. Saber operar: cómo detectas un problema (observabilidad), cómo decides si puedes desplegar (presupuesto de errores) y cómo aprendes de un fallo (postmortem).

La guía del examen dice que el Well-Architected Framework está presente, implícita y explícitamente, en todos los objetivos. La sección 6 entera (12,5 %) va de operaciones, y el apartado 1.2 (alta disponibilidad, escalabilidad, backup) aparece en muchísimas preguntas de diseño y en los casos de estudio.

Google Cloud Well-Architected Framework

El Well-Architected Framework (WAF, antes llamado Architecture Framework) es el conjunto de recomendaciones de Google para diseñar y operar cargas en su nube. Se organiza en seis pilares, cada uno con unos principios. Los nombres de los principios cambian con el tiempo; los siguientes son los que figuran en la documentación a fecha de septiembre de 2026.

Además de los pilares, el WAF tiene perspectivas transversales (cross-pillar perspectives), por ejemplo la de AI and ML y la de servicios financieros, que aplican los seis pilares a un tipo de carga o sector.

Operational excellence a fondo (apartado 6.1)

Este pilar tiene un apartado propio en el examen. Sus cinco principios, explicados:

1. Ensure operational readiness and performance using CloudOps. Antes de pasar a producción defines SLO, montas monitorización completa, haces pruebas de rendimiento y planificas la capacidad. «Operational readiness» significa que el equipo sabe operar el servicio el día 1: runbooks, alertas, guardias, dashboards.
2. Manage incidents and problems. Observabilidad para detectar pronto, procedimientos claros de respuesta (roles, escalado, comunicación), revisiones posteriores (postmortems) y acciones preventivas. Distingue incidente (algo que está afectando ahora al servicio: hay que restaurarlo) de problema (la causa subyacente, que puede provocar incidentes repetidos: hay que eliminarla).
3. Manage and optimize cloud resources. Dimensionar bien (right-sizing), autoescalar y vigilar el coste. Aquí se solapa con el pilar de costes.
4. Automate and manage change. Infraestructura como código, CI/CD, despliegues progresivos, cambios pequeños y reversibles. Menos trabajo manual, menos errores humanos. Lo desarrollas en el módulo 10.
5. Continuously improve and innovate. Retrospectivas, métricas de entrega, adopción de nuevas capacidades del proveedor.

Reliability a fondo

La idea de fondo del pilar de fiabilidad es que la fiabilidad se define desde el usuario, no desde la máquina. Una VM al 100 % de CPU no es un problema si los usuarios reciben respuestas rápidas; un servicio con todas las VMs «verdes» sí lo es si el 5 % de los pagos falla. De ahí salen los SLI y SLO (más abajo). El resto de principios son técnicas para cumplir esos objetivos: redundancia, escalado horizontal, observabilidad, degradación elegante, pruebas de recuperación (ante fallos y ante pérdida de datos) y postmortems.

Alta disponibilidad

Zonas, regiones y el radio de impacto

Recuerda del módulo 1: una región (p. ej. europe-southwest1, Madrid) tiene varias zonas (dominios de fallo independientes: europe-southwest1-a, -b, -c). Cada recurso de Google Cloud es zonal, regional o global/multirregional, y eso determina qué fallo sobrevive:

Cuanto más amplio el alcance, más caro y más complejo (replicación, consistencia, latencia entre regiones). El arquitecto elige el mínimo alcance que cumple el requisito.

SLA de Google y SLA compuestos

Cada servicio publica un SLA (Service Level Agreement): un compromiso contractual de disponibilidad mensual con créditos si Google no lo cumple. Algunos valores a fecha de septiembre de 2026 (regiones del nivel Premium, salvo México y Estocolmo, que tienen valores menores):

Fíjate en dos detalles que el examen adora: Cloud SQL sin HA (una sola zona) no tiene SLA, y una VM suelta tiene un SLA menor que varias VMs en varias zonas. Consulta siempre la página cloud.google.com/<producto>/sla porque las cifras cambian.

Traducción a minutos (mes de 30 días = 43.200 minutos):

Componentes en serie: si una petición necesita que funcionen A y B y C, las disponibilidades se multiplican y el total es peor que el peor componente.

Ejemplo: balanceador (99,99 %) → MIG multizona (99,99 %) → Cloud SQL Enterprise con HA (99,95 %):

0,9999 × 0,9999 × 0,9995 ≈ 0,9993 → 99,93 %, unos 30 minutos de caída posibles al mes.

Componentes en paralelo (redundancia): si basta con que funcione A o B, la indisponibilidad se multiplica:

1 − (1 − a) × (1 − b)

Ejemplo: dos pilas regionales independientes de 99,93 % cada una: 1 − 0,0007 × 0,0007 ≈ 99,99995 %. En la práctica el total queda limitado por lo que sigue en serie (el balanceador global, 99,99 %; la base de datos, si es compartida) y por la calidad del failover: el cálculo supone fallos independientes y conmutación perfecta, algo que nunca es del todo cierto.

Redundancia y failover

• Activo-activo: todas las réplicas sirven tráfico. El balanceador reparte y, si una cae, deja de enviarle peticiones (health checks). Aprovecha toda la capacidad, pero necesitas que los datos se puedan escribir en varios sitios o que la escritura esté centralizada.
• Activo-pasivo: una réplica sirve y otra espera. Más sencillo con bases de datos, pero el failover tarda (detección + promoción + cambio de DNS o de endpoint) y pagas capacidad ociosa.
• Health checks: el balanceador y los MIG (autohealing) necesitan comprobaciones de salud bien diseñadas. Un health check demasiado superficial (solo «el proceso responde») no detecta que la base de datos está caída; uno demasiado profundo puede sacar del servicio todas las instancias a la vez por un fallo de una dependencia.
• Evita puntos únicos de fallo (SPOF) en todas las capas: DNS (Cloud DNS es global y con SLA alto), balanceador, cómputo, datos, conectividad híbrida (dos túneles de HA VPN o dos conexiones de Interconnect en dominios de disponibilidad distintos, del módulo 4).

Piezas de alta disponibilidad por capa, en resumen:

Degradación elegante

Graceful degradation: cuando una parte falla o hay sobrecarga, el sistema sigue ofreciendo algo, aunque sea menos. Técnicas:

• Servir contenido en caché o estático si el backend no responde (Cloud CDN, respuestas por defecto).
• Desactivar funciones no esenciales (recomendaciones, búsqueda avanzada) y mantener las críticas (checkout).
• Load shedding: rechazar parte de las peticiones (HTTP 429/503) para proteger el resto, en lugar de caer entero.
• Circuit breakers y timeouts: no esperar indefinidamente a una dependencia caída.
• Reintentos con backoff exponencial y jitter para errores transitorios, con límite, para no provocar una «tormenta de reintentos».
• Colas (Pub/Sub) para desacoplar: si el consumidor cae, los mensajes esperan.

Escalabilidad y rendimiento

• Escalado horizontal (más instancias) antes que vertical (máquina más grande): es el principio del WAF y lo que permite autoescalar sin parada. Requiere que el servicio sea sin estado (stateless): la sesión, en Memorystore o Firestore; los ficheros, en Cloud Storage.
• Autoescalado: MIG (por CPU, capacidad de servicio del balanceador, métricas de Cloud Monitoring o por programación), GKE (HPA para pods, cluster autoscaler para nodos; Autopilot lo gestiona), Cloud Run (por peticiones concurrentes; puedes fijar min-instances para evitar arranques en frío).
• Planificación de capacidad: el autoescalado no crea capacidad de la nada. Revisa cuotas del proyecto y, para picos previstos (Black Friday), usa reservas de Compute Engine o solicita aumentos de cuota con antelación.
• Latencia: acerca los datos al usuario (Cloud CDN, réplicas de lectura, regiones cercanas), usa el nivel de red Premium, cachea (Memorystore) y elige bases de datos según el patrón de acceso (módulo 5).
• Pruebas de rendimiento y benchmarking: mide antes de optimizar. Establece una línea base (latencia p50/p95/p99, throughput) y compárala tras cada cambio.

Recuperación ante desastres (DR)

RTO y RPO

• RTO (Recovery Time Objective): el tiempo máximo aceptable que la aplicación puede estar caída tras un incidente grave.
• RPO (Recovery Point Objective): el periodo máximo aceptable de datos perdidos. Un RPO de 15 minutos significa que puedes perder, como mucho, los últimos 15 minutos de escrituras.

flowchart LR
  A["Último backup o punto replicado"] -->|"RPO: datos que puedes perder"| B["Desastre"]
  B -->|"RTO: tiempo hasta volver a servir"| C["Servicio restaurado"]

Regla de oro de la guía de Google: cuanto menores son el RTO y el RPO, más cuesta y más compleja es la solución. Por eso el primer paso es preguntar al negocio cuánto le cuesta cada hora caída y cada hora de datos perdidos, y clasificar las aplicaciones por niveles (no todas necesitan lo mismo).

Patrones: cold, warm y hot

La guía de DR de Google usa una analogía con ruedas de coche: cold es no llevar rueda de repuesto y llamar a la grúa; warm es llevar rueda de repuesto y cambiarla tú; hot son neumáticos run-flat, con los que sigues circulando.

Los rangos son orientativos para razonar; cada caso depende de la tecnología de datos elegida.

Piezas de Google Cloud para backup y DR

Backup and DR Service merece atención porque aparece cada vez más:

• Servicio gestionado de copias con una consola centralizada y gobierno por políticas.
• Protege, entre otros, instancias de Compute Engine y discos, Filestore, VMs de Google Cloud VMware Engine, Cloud SQL y AlloyDB, y bases de datos autogestionadas en VMs (Oracle, SQL Server, SAP HANA, MySQL, PostgreSQL).
• Backup vaults: almacenamiento de copias con inmutabilidad e indelebilidad (tipo WORM) y un periodo mínimo de retención obligatorio. Son la defensa frente a ransomware o frente a un administrador que borra las copias: ni siquiera un propietario del proyecto puede eliminar una copia antes de tiempo.
• Backup plans: definen frecuencia, ventana y retención, y se asocian a los recursos.

Probar el DR

Un plan de DR que no se ha probado no existe. El WAF incluye dos principios explícitos: probar la recuperación ante fallos y probar la recuperación ante pérdida de datos. En la práctica: simulacros periódicos (DR drills), restauraciones reales de backups a un entorno aislado, medir el RTO real (lo harás en el lab 19) y automatizar el procedimiento con IaC y runbooks.

SRE: fiabilidad como disciplina de ingeniería

Site Reliability Engineering (SRE) es la forma en que Google opera sus servicios: tratar las operaciones como un problema de software. Conceptos que el examen da por sabidos:

SLI, SLO y SLA

• SLI (Service Level Indicator): una medida cuantitativa de lo que percibe el usuario. Normalmente un cociente: peticiones buenas / peticiones totales. Ejemplos: proporción de peticiones HTTP que no devuelven 5xx; proporción de peticiones servidas en menos de 300 ms; frescura de los datos.
• SLO (Service Level Objective): el objetivo interno para un SLI en un periodo. «El 99,9 % de las peticiones en una ventana móvil de 28 días devuelve una respuesta correcta».
• SLA (Service Level Agreement): el contrato con el cliente, con consecuencias económicas. Siempre más laxo que el SLO: el SLO es tu margen de seguridad para no incumplir el SLA.

flowchart LR
  SLI["SLI: lo que mides"] --> SLO["SLO: tu objetivo interno"]
  SLO --> SLA["SLA: lo que prometes por contrato (más laxo)"]

Nunca se busca el 100 %: es imposible, carísimo y el usuario no lo nota (su propio móvil o su wifi fallan más).

Presupuesto de errores

El error budget es 1 − SLO. Con un SLO del 99,9 % en 30 días, el presupuesto es el 0,1 %: unos 43 minutos de indisponibilidad total, o el 0,1 % de las peticiones fallidas.

Sirve para tomar decisiones sin discusiones:

• Queda presupuesto → el equipo puede desplegar novedades y asumir riesgos.
• Presupuesto agotado → se congelan los cambios no urgentes y se dedica el esfuerzo a fiabilidad hasta recuperarlo.

Es el mecanismo que alinea a desarrollo (quiere velocidad) y operaciones (quiere estabilidad).

Burn rate y alertas

El burn rate (tasa de consumo) mide lo rápido que gastas el presupuesto. Un burn rate de 1 lo agota justo al final del periodo; uno de 10 lo agota en una décima parte (en 3 días si el periodo es de 30).

Cloud Monitoring recomienda combinar dos alertas sobre el SLO (usan el selector select_slo_burn_rate):

Toil

El toil es trabajo operativo manual, repetitivo, automatizable, reactivo y sin valor duradero (reiniciar a mano un servicio cada semana, crear cuentas a mano). SRE limita el toil (Google habla de mantenerlo por debajo del 50 % del tiempo del equipo) y lo elimina con automatización.

Gestión de incidentes

• Roles claros: Incident Commander (coordina y decide), Operations lead (aplica cambios), Communications lead (informa a interesados y clientes).
• Prioridad 1: mitigar, no encontrar la causa. Primero se restaura el servicio (revertir el despliegue, desviar tráfico a otra región, escalar) y después se investiga.
• Documento de incidente vivo con la cronología.
• Escalado a Google (Customer Care) si la causa puede estar en la plataforma; consulta antes el Service Health / Personalized Service Health para ver incidencias conocidas de Google Cloud.

Postmortems sin culpa

Tras un incidente relevante se redacta un postmortem sin culpa (blameless): cronología, impacto, causa raíz y factores contribuyentes, qué fue bien, qué fue mal y acciones con responsable y fecha. Sin culpables: si una persona pudo romper producción con un comando, el fallo es del sistema que lo permitió. Es uno de los principios del pilar de fiabilidad.

Google Cloud Observability (apartado 6.2)

Google Cloud Observability (antes Stackdriver y luego Cloud Operations suite) agrupa los productos de monitorización, registro y diagnóstico.

flowchart TB
  APP["Aplicación y recursos (VMs, GKE, Cloud Run...)"] -->|"métricas"| MON["Cloud Monitoring"]
  APP -->|"logs"| LOG["Cloud Logging"]
  APP -->|"trazas (OpenTelemetry)"| TRA["Cloud Trace"]
  APP -->|"perfiles de CPU y memoria"| PRO["Cloud Profiler"]
  LOG -->|"excepciones agrupadas"| ERR["Error Reporting"]
  LOG -->|"métricas basadas en logs"| MON
  MON --> AL["Alertas, SLO, dashboards, uptime checks"]

Cloud Monitoring

• Métricas: miles de métricas del sistema llegan solas (CPU de VM, peticiones de Cloud Run, latencia del balanceador). Para métricas dentro del sistema operativo de una VM (memoria, disco, procesos) y logs de aplicaciones, instala el Ops Agent. Tus métricas propias son custom metrics (vía API u OpenTelemetry).
• Metrics scope: un proyecto puede ver las métricas de varios proyectos (útil para un proyecto central de monitorización).
• Dashboards: predefinidos por servicio y personalizados. Se pueden definir como código (JSON) y crear con gcloud monitoring dashboards create.
• Uptime checks: comprobaciones HTTP(S), TCP o ICMP desde varias regiones del mundo (mínimo 3) contra una URL, una IP o un recurso. Verifican disponibilidad desde fuera. Para recorridos de usuario completos existen los synthetic monitors.
• Alerting policies: condición (umbral, ausencia de datos, consulta PromQL, tasa de consumo de SLO) + canales de notificación (correo, SMS, Slack, PagerDuty, webhooks, Pub/Sub) + documentación para quien recibe la alerta.
• SLO monitoring: defines un servicio (Cloud Monitoring reconoce como candidatos los servicios de GKE y Cloud Run, y también App Engine, Istio y Cloud Service Mesh), un SLI (availability, latency u otra métrica; request-based o windows-based) y un objetivo sobre un periodo de cumplimiento (rolling o calendar).

Estrategias de alertado:

• Alerta por síntomas, no por causas. Avisa cuando el usuario sufre (errores, latencia, SLO en riesgo), no cuando una VM tiene la CPU al 90 %. Las causas van a dashboards para diagnosticar.
• Alertas por burn rate del SLO en lugar de umbrales fijos de error: menos falsos positivos y relación directa con el impacto.
• Cada alerta que despierta a alguien debe ser accionable y llevar un enlace a su runbook. Las no urgentes, a ticket.
• Evita la fatiga de alertas: si una alerta salta y nadie hace nada, bórrala o conviértela en ticket.

Cloud Logging

Arquitectura en tres piezas: los logs entran por la Logging API, el Log Router los evalúa contra los sinks y cada sink los envía a un destino.

• Cada proyecto tiene dos sinks y dos buckets de sistema:
  • _Required: recibe los registros de auditoría de actividad de administración, eventos del sistema y Access Transparency. Retención fija de 400 días, sin coste de retención y no se puede cambiar ni desactivar.
  • _Default: recibe todo lo demás (incluidos los Data Access audit logs si los activas). Retención por defecto de 30 días, configurable en proyectos.
• Buckets de logs definidos por el usuario: retención entre 1 y 3650 días, región elegida al crearlos (no se puede cambiar después), CMEK opcional.
• Destinos de un sink: otro bucket de logs, BigQuery (analizar y cruzar con datos de negocio), Cloud Storage (archivo barato a largo plazo), Pub/Sub (integración con SIEM de terceros como Splunk) u otro proyecto.
• Aggregated sinks: a nivel de carpeta u organización con --include-children, para centralizar los logs de todos los proyectos (patrón típico de auditoría y cumplimiento).
• Al crear un sink se genera una writer identity (cuenta de servicio) a la que debes dar permiso de escritura en el destino.
• Exclusion filters: descartan logs ruidosos para ahorrar coste (por ejemplo, logs de health checks).
• Observability Analytics (antes Log Analytics): consulta los logs (y las trazas) con SQL tras actualizar el bucket; puedes crear un dataset vinculado de BigQuery para consultarlos desde BigQuery sin copiarlos.
• Métricas basadas en logs (log-based metrics): convierten entradas de log en métricas de Monitoring (contador o distribución) para dashboards y alertas.

Precio orientativo (septiembre de 2026): el almacenamiento de logs cuesta 0,50 USD/GiB e incluye 30 días de retención, con los primeros 50 GiB por proyecto y mes gratis. Consulta cloud.google.com/stackdriver/pricing.

Cloud Trace, Cloud Profiler y Error Reporting

Managed Service for Prometheus y OpenTelemetry

• Google Cloud Managed Service for Prometheus: Prometheus gestionado a escala global. Recoge métricas en formato Prometheus (sobre todo en GKE, donde se activa la recolección gestionada), las guarda 24 meses y permite consultarlas con PromQL y seguir usando Grafana y alertas PromQL. Es la respuesta cuando el enunciado dice «ya usamos Prometheus y no queremos operarlo» o «queremos una vista global de varios clústeres».
• OpenTelemetry (OTel): estándar abierto para instrumentar métricas, trazas y logs. Google lo recomienda para instrumentar aplicaciones (el Ops Agent y el OpenTelemetry Collector pueden enviar datos a Google Cloud). Evita el vendor lock-in: instrumentas una vez y puedes cambiar de backend.

Soporte de soluciones desplegadas (apartado 6.4)

Planes de Cloud Customer Care

Tiempos de primera respuesta objetivo según las Technical Support Services Guidelines y la documentación de Premium Support a septiembre de 2026 (enlaces en «Documentación»). Los precios dependen del gasto mensual: consúltalos en cloud.google.com/support.

Prioridades de caso: P1 servicio inutilizable en producción; P2 uso muy degradado; P3 uso parcialmente degradado; P4 impacto bajo o consultas. Asignar la prioridad correcta y adjuntar contexto (proyecto, recurso, hora, mensajes de error, pasos de reproducción) acorta mucho la resolución.

Otras piezas de soporte operativo: Service Health / Personalized Service Health (incidencias de Google que afectan a tus proyectos, con alertas), Active Assist / Recommender (recomendaciones de tamaño, seguridad y coste) y los runbooks propios.

Control de calidad y fiabilidad en producción (apartados 6.5 y 6.6)

Control de calidad

Medidas que el examen reconoce como buenas prácticas:

• Pruebas automatizadas en el pipeline (unitarias, integración, extremo a extremo), con un entorno de staging lo más parecido a producción. Se detalla en el módulo 10.
• Despliegues progresivos (canary) con análisis de métricas antes de ampliar, y rollback rápido.
• Revisiones de código y análisis estático; en infraestructura, policy as code para validar antes de aplicar.
• Métricas de entrega DORA: frecuencia de despliegue, tiempo de entrega de cambios, tasa de cambios fallidos y tiempo de recuperación. Miden a la vez velocidad y estabilidad.
• Revisiones post-lanzamiento y seguimiento de los SLO como indicador de calidad percibida.

Pruebas de carga

Objetivo: comprobar que el sistema cumple los SLO con la carga esperada y descubrir su punto de ruptura. Buenas prácticas:

• Probar en un entorno de preproducción representativo, o en producción con cuidado y tráfico sintético marcado.
• Incluir los arranques en frío y el tiempo de autoescalado: un MIG tarda minutos en añadir VMs.
• Revisar cuotas antes de la prueba (una prueba de carga puede agotarlas).
• Herramientas habituales: Locust, JMeter, k6. Google publica una arquitectura de referencia de pruebas de carga distribuidas con Locust sobre GKE.
• Para eventos críticos, Premium Support incluye pruebas de carga en su Event Management Service.

Ingeniería del caos

Chaos engineering: inyectar fallos controlados para comprobar que el sistema se degrada y recupera como esperas. Método: define el estado estable (los SLI), formula una hipótesis («si cae una zona, el MIG regional absorbe el tráfico sin romper el SLO»), inyecta el fallo con un radio de impacto limitado, observa y corrige. Ejemplos en Google Cloud: parar instancias de un MIG, simular la caída de una zona drenando backends, inyectar latencia o errores con políticas de fault injection de Cloud Service Mesh o Istio, o usar herramientas de terceros. Empieza en preproducción y ten siempre un botón de parada.

Pruebas de penetración

Regla que el examen pregunta: no hace falta avisar a Google para hacer pruebas de penetración sobre tus propios recursos de Google Cloud. Condiciones: cumplir la Acceptable Use Policy y los Terms of Service, y que las pruebas solo afecten a tus proyectos, nunca a otros clientes ni a la infraestructura de Google. Si encuentras una vulnerabilidad de la plataforma, se comunica por el Vulnerability Reward Program de Google. Complementa con Web Security Scanner (de Security Command Center) para vulnerabilidades web comunes en App Engine, GKE y Compute Engine.

Troubleshooting y análisis de causa raíz

Método de diagnóstico que funciona en la práctica y en el examen:

1. Delimita el impacto: ¿qué usuarios, qué región, desde cuándo? Mira los SLO y los uptime checks.
2. ¿Qué ha cambiado? La mayoría de incidentes siguen a un cambio: despliegue, configuración, cuota, certificado caducado. Revisa los Admin Activity audit logs y el historial de despliegues (Cloud Deploy, revisiones de Cloud Run).
3. Mitiga primero: revertir, desviar tráfico, escalar.
4. Correlaciona métricas, logs y trazas en la misma ventana temporal (Logs Explorer, Metrics Explorer, Trace).
5. Descarta la plataforma: Personalized Service Health.
6. Causa raíz: técnicas como los 5 porqués y la distinción entre causa desencadenante y factores contribuyentes.
7. Postmortem con acciones.

Herramientas específicas útiles: Connectivity Tests (Network Intelligence Center) para averiguar por qué un paquete no llega (firewall, rutas), VPC Flow Logs y Firewall Rules Logging, Query Insights de Cloud SQL para consultas lentas, y el serial console de Compute Engine cuando una VM no arranca.

Gemini Cloud Assist en operaciones

Gemini Cloud Assist es el asistente de IA integrado en la consola de Google Cloud. En operaciones te interesan sobre todo:

• Investigations: analiza logs, métricas y cambios recientes para proponer causas raíz de un problema; puede lanzarse desde una alerta y, si hace falta, escalar el caso a Customer Care con el contexto de la investigación.
• Optimización de costes en lenguaje natural (incluido FinOps Hub) y detección de anomalías de coste.
• Diseño de arquitecturas con Application Design Center y generación de comandos gcloud, manifiestos kubectl y Terraform.
• Resolución de problemas de bases de datos (Cloud SQL, Spanner, BigQuery).

En el examen, Gemini Cloud Assist aparece como la herramienta para acelerar el troubleshooting y el análisis de causa raíz o para ayudar al diseño. Recuerda que no sustituye a la observabilidad: necesita buenos logs y métricas para razonar.

Trampas típicas del examen

• Cloud SQL sin HA no tiene SLA. Si piden disponibilidad, HA regional como mínimo.
• Una réplica de lectura no es HA: la HA de Cloud SQL es la standby síncrona en otra zona; la réplica entre regiones es para lectura y DR (promoción manual o advanced DR).
• Snapshots ≠ backup inmutable: para protección frente a borrado malicioso, backup vaults con retención obligatoria.
• SLA ≠ SLO: el SLA es contractual y más laxo; el objetivo interno es el SLO.
• Serie empeora, paralelo mejora: multiplica disponibilidades en serie; multiplica indisponibilidades en paralelo.
• «Alertar cuando la CPU supere el 80 %» casi nunca es la mejor respuesta si el enunciado habla de experiencia de usuario: alerta por síntomas / burn rate del SLO.
• «Retención de logs de auditoría de años» → Cloud Storage; el bucket _Required guarda 400 días y no se modifica.
• «Métrica a partir de un mensaje de log» → log-based metric.
• «Latencia entre microservicios» → Trace; «qué función consume CPU» → Profiler; «nuevas excepciones» → Error Reporting.
• «Ya usamos Prometheus y Grafana» → Managed Service for Prometheus.
• Pentesting: no se avisa a Google; solo tus proyectos, cumpliendo la AUP.
• Mitigar antes que diagnosticar durante un incidente.
• Toil → automatizar; incidentes repetidos → postmortem sin culpa con acciones.
• «Evento de lanzamiento con apoyo de Google» → Premium Support + Event Management Service.

Resumen

• El WAF tiene seis pilares: operational excellence, security (privacy and compliance), reliability, cost optimization, performance optimization y sustainability. La excelencia operativa gira en torno a CloudOps, incidentes, recursos, automatización del cambio y mejora continua.
• La disponibilidad se diseña por capas y alcance (zonal, regional, multirregional). En serie las disponibilidades se multiplican; en paralelo, las indisponibilidades.
• DR: define RTO y RPO con el negocio y elige cold (backup y restauración), warm o hot según coste. Snapshots, machine images, discos regionales, replicación asíncrona, réplicas entre regiones, Spanner multirregional y Backup and DR Service con backup vaults.
• SRE: SLI (medida) → SLO (objetivo) → SLA (contrato). El presupuesto de errores decide cuándo se despliega y cuándo se congela.
• Alerta por síntomas y por burn rate: fast burn (10x, 1-2 h) y slow burn (2x, 24 h).
• Cloud Logging: _Required (400 días fijos), _Default (30 días configurables), sinks a buckets, BigQuery, Cloud Storage o Pub/Sub; aggregated sinks para la organización; Observability Analytics para SQL.
• Trace para latencia distribuida, Profiler para CPU/memoria del código, Error Reporting para excepciones, Managed Service for Prometheus para PromQL, OpenTelemetry para instrumentar.
• Customer Care: Standard (sin P1), Enhanced (P1 en 1 h) y Premium (P1 en 15 min, TAM, Event Management).
• Fiabilidad en producción: pruebas de carga, caos con radio de impacto limitado, pentesting sin avisar a Google, y troubleshooting empezando por «qué ha cambiado».

Practica lo aprendido

Documentación oficial para ampliar

• Google Cloud Well-Architected Framework
• Well-Architected Framework — Operational excellence pillar
• Well-Architected Framework — Reliability pillar
• Disaster recovery planning guide
• Backup and DR Service overview
• Alerting on your burn rate (SLO monitoring)
• Cloud Logging — Configure log buckets
• Google Cloud Observability pricing
• Technical Support Services Guidelines (tiempos de respuesta)
• Libros de SRE de Google (gratuitos)