En la revisión de agosto de 2026 de la guía del examen Cloud Digital Leader, el dominio 6, "Escalamiento con las operaciones de Google Cloud", bajó a alrededor del 10%, pero ganó muchos apartados nuevos y detallados. Pregunta cómo medir el rendimiento y la fiabilidad de un sistema mediante la latencia, el tráfico, la saturación y los errores; cómo diseñar para la resiliencia con redundancia, replicación, infraestructura escalable y copias de seguridad; Google Cloud Observability, de Cloud Monitoring a Cloud Profiler, y, en el lado de los costos, las políticas de cuotas, las reglas de umbral de presupuesto, los informes de Cloud Billing, Dynamic Workload Scheduler y el papel de las personas, los procesos y la tecnología.
Este artículo empieza por los términos básicos de operaciones y recorre después las cuatro señales doradas, SLI, SLO y SLA con los presupuestos de errores, el diseño para la resiliencia, las herramientas de observabilidad y los controles y prácticas de FinOps que mantienen los costos bajo control. Las definiciones básicas de SLI, SLO y SLA, DevOps, y los presupuestos y descuentos por compromiso de uso se tratan primero en Gestión de costos y excelencia operacional.
---
Términos básicos de operaciones: excelencia operacional, fiabilidad y alta disponibilidad
La guía del examen te pide reconocer los términos fundamentales de las operaciones en la nube. Los tres suenan parecidos, pero se centran en cosas distintas.
| Término | Significado | Ejemplo | |------|------|------| | Excelencia operacional | La capacidad de operar los sistemas con eficiencia y seguir mejorándolos | Automatización de despliegues, supervisión, mejoras después de los incidentes | | Fiabilidad | Lo constante que es un sistema al comportarse como se espera | Los usuarios obtienen el resultado correcto cada vez que hacen una solicitud | | Alta disponibilidad | La capacidad de seguir prestando servicio aunque haya fallos, normalmente expresada como porcentaje de tiempo activo | El servicio continúa en otras zonas cuando una zona se cae |
Cada 9 de más en una cifra de disponibilidad reduce a una décima parte el tiempo de inactividad permitido.
| Disponibilidad | Inactividad permitida al mes (aprox.) | |------|------| | 99% | 7 horas y 18 minutos | | 99.9% | 43 minutos y 50 segundos | | 99.99% | 4 minutos y 23 segundos | | 99.999% | 26 segundos |
Consejo para el examen: Cuanto más alto es el objetivo de disponibilidad, mayores son el costo y la complejidad. No todos los servicios necesitan un 99.999%; fijar un objetivo que encaje con el negocio forma parte de la excelencia operacional.
---
Las cuatro señales doradas: qué medir
No se pueden poner cientos de indicadores en el salpicadero de un coche. El conductor mira lo esencial: la velocidad, el combustible y la temperatura del motor. La práctica de SRE de Google dice que, si solo puedes medir cuatro métricas de un servicio de cara al usuario, te centres en la latencia, el tráfico, los errores y la saturación. La guía del examen también cita estas cuatro como la forma de medir el rendimiento y la fiabilidad de un sistema.
!Las cuatro señales doradas, latencia, tráfico, errores y saturación, medidas como SLI y comparadas con los SLO
| Señal | Qué observa | Ejemplo | |------|------|------| | Latencia | El tiempo que se tarda en atender una solicitud | El 95% de las solicitudes de pago se responden en menos de 300 milisegundos | | Tráfico | Cuánta demanda entra en el sistema | Solicitudes por segundo, usuarios simultáneos | | Errores | El porcentaje de solicitudes que fallan | Porcentaje de respuestas de error del servidor (5xx), resultados incorrectos | | Saturación | Lo lleno que está el sistema | Uso de CPU, memoria, disco y colas |
La saturación es especial porque avisa antes de que empiecen los problemas. Las otras tres empeoran solo cuando los usuarios ya se ven afectados, pero, cuando la saturación se acerca a su límite, puedes añadir capacidad antes de que se produzca una caída.
Consejo para el examen: "La velocidad de respuesta que perciben los usuarios" es la latencia, "el volumen de solicitudes que recibe el servicio" es el tráfico y "si los recursos están cerca de su límite" es la saturación.
---
SLI, SLO, SLA y presupuestos de errores
SLI, SLO y SLA son las herramientas que convierten las señales doradas en cifras que se pueden gestionar. El orden es medir, fijar un objetivo y hacer una promesa a los clientes.
| Término | Función | Ejemplo | |------|------|------| | SLI (indicador de nivel de servicio) | El valor que realmente se mide | Este mes se completaron con éxito el 99.95% de las solicitudes | | SLO (objetivo de nivel de servicio) | El objetivo interno que fija el equipo | Al menos el 99.9% de las solicitudes con éxito a lo largo de un mes | | SLA (acuerdo de nivel de servicio) | La promesa contractual a los clientes, con compensación si se incumple | Por debajo del 99.5%, parte de la tarifa se devuelve como créditos |
El SLO se fija más estricto que el SLA. Así queda un margen para seguir cumpliendo la promesa a los clientes aunque se incumpla ligeramente el objetivo interno.
Presupuesto de errores: cuánto fallo se permite
El presupuesto de errores es el 100% menos el SLO. Si el SLO es del 99.9%, el presupuesto de errores es del 0.1%, lo que significa que se permiten unos 43 minutos de inactividad al mes, o 1.000 fallos de cada millón de solicitudes.
Si queda presupuesto: seguir adelante con cambios arriesgados, como lanzar funciones nuevas y hacer experimentos Si se agota el presupuesto: detener los lanzamientos y centrarse en mejorar la estabilidad
Así, un equipo de desarrollo que quiere "lanzar rápido" y un equipo de operaciones que dice "primero la estabilidad" pueden ponerse de acuerdo con datos y no por intuición. SRE lo combina con los análisis posteriores sin culpa, que se centran en las causas y las soluciones en lugar de culpar a las personas, y con el principio de automatizar el trabajo manual repetitivo.
Consejo para el examen: Si "el presupuesto de errores se agotó", la respuesta correcta es dejar de lanzar funciones nuevas y centrarse en mejorar la fiabilidad. Si preguntan "¿cuál es el presupuesto de errores con un SLO del 99.9%?", la respuesta es 0.1%.
---
Diseñar infraestructura y procesos resilientes
Un avión tiene dos o más motores para poder seguir volando si uno se detiene. La guía del examen cita la redundancia, la replicación, la infraestructura escalable y las copias de seguridad como formas de diseñar para la resiliencia.
| Técnica | Significado | Ejemplos en Google Cloud | |------|------|------| | Redundancia | Varios componentes cumplen la misma función para que el sistema siga funcionando si uno se detiene | Grupos de instancias administrados con máquinas virtuales repartidas entre zonas, balanceo de cargas | | Replicación | Mantener copias de los datos sincronizadas de forma continua en otras ubicaciones | Configuración de alta disponibilidad de Cloud SQL (una instancia en espera en otra zona), Spanner multirregional, Cloud Storage multirregional | | Infraestructura escalable | Añadir y quitar recursos automáticamente según la carga | Ajuste automático de escala, Cloud Run, Cloud Load Balancing | | Copias de seguridad | Guardar aparte una copia de un momento concreto para recuperarse tras errores o ransomware | Copias de seguridad automáticas de Cloud SQL, instantáneas de disco, Backup and DR Service |
La replicación y las copias de seguridad son distintas. Como la replicación mantiene las copias sincronizadas en tiempo real, si alguien elimina datos por error, la eliminación también se replica. Una copia de seguridad es una copia de un momento pasado, así que permite deshacer ese tipo de errores.
Al planificar la recuperación ante desastres, se fijan primero dos objetivos.
| Objetivo | Pregunta | Ejemplo | |------|------|------| | RTO (objetivo de tiempo de recuperación) | ¿En cuánto tiempo tras un fallo debe volver el servicio? | Recuperarse en menos de 4 horas | | RPO (objetivo de punto de recuperación) | ¿Cuántos datos se pueden perder como máximo? | Recuperar los datos hasta los últimos 15 minutos |
Consejo para el examen: "Devolver al estado de ayer los datos eliminados por error" es una copia de seguridad. "La base de datos sigue funcionando aunque se detenga una zona" es la replicación con una instancia en espera en otra zona (una configuración de alta disponibilidad).
---
Google Cloud Observability: cinco herramientas para ver dentro de los sistemas
La guía del examen pregunta cómo modernizar las operaciones con Google Cloud Observability (antes Stackdriver y operations suite) y nombra cinco herramientas.
| Herramienta | Qué hace | Pregunta que responde | |------|------|------| | Cloud Monitoring | Recopila métricas, paneles, alertas y comprobaciones de tiempo de actividad | ¿Está sano el sistema ahora mismo? | | Cloud Logging | Recopila, guarda, busca y analiza registros | ¿Qué pasó? | | Cloud Trace | Sigue la latencia de cada tramo mientras una solicitud pasa por varios servicios | ¿Dónde se ralentizó? | | Cloud Profiler | Analiza de forma continua y con poca sobrecarga qué código usa más CPU y memoria en las aplicaciones en ejecución | ¿Qué código consume más recursos? | | Error Reporting | Recopila los errores de las aplicaciones, los agrupa por tipo y avisa de los nuevos | ¿Qué errores son nuevos? |
Cloud Debugger, que puedes ver en material antiguo, dejó de funcionar el 31 de mayo de 2023, así que ya no está en la lista.
Consejo para el examen: "Encontrar qué tramo de los microservicios ralentiza la respuesta" es Cloud Trace, y "encontrar qué funciones usan más CPU para reducir costos" es Cloud Profiler.
---
La otra cara de las operaciones: controles que mantienen los costos a raya
Escalar las operaciones significa controlar los costos, no solo la fiabilidad. La guía del examen cita las políticas de cuotas, las reglas de umbral de p