Una revisión del nivel de servicio debe explicar qué experiencia tuvieron los usuarios, cómo se compara con el objetivo acordado y qué debería hacer el equipo a continuación. Un porcentaje en verde no basta. Quien escucha necesita saber qué se ha contado, a qué periodo corresponde y si un grupo reducido de usuarios tuvo una experiencia mucho peor de lo que sugiere la cifra principal.
Empieza con una afirmación que se pueda examinar: «El servicio de envío de solicitudes de soporte cumplió su objetivo de éxito, pero un solo incidente concentró la mayoría de los fallos. Recomendamos investigar esa vía de fallo antes de endurecer el objetivo». Después, muestra el cálculo y el proceso afectado. Es una apertura más útil que una captura de un panel con doce cifras sin explicar.
Puedes convertir las notas aprobadas de la revisión en una presentación editable con la herramienta de Presenti para crear presentaciones a partir de texto. Utiliza tus sistemas de monitorización y soporte como fuentes de evidencia. Presenti ayuda a organizar y editar las diapositivas; no recoge la telemetría del servicio ni determina si se ha cumplido un SLO.
Define el servicio, la medida y el periodo
Delimita la revisión: una tarea del usuario, el servicio que la permite y el intervalo del informe. «Fiabilidad de la plataforma» es demasiado amplio si los datos solo cubren el envío de solicitudes. Que una solicitud se envíe correctamente no demuestra que también hayan funcionado el inicio de sesión, la búsqueda y las notificaciones.
Conviene explicar tres términos en la primera diapositiva de resultados o en un pequeño glosario junto a ella. La explicación de Google SRE sobre los objetivos de nivel de servicio distingue entre la medida, el objetivo y el acuerdo:
| Concepto | Significado | Qué mostrar |
|---|---|---|
| SLI: indicador de nivel de servicio | Una medida cuantitativa del comportamiento del servicio. | El resultado medido y cómo se ha calculado. |
| SLO: objetivo de nivel de servicio | El objetivo fijado para esa medida durante un periodo definido. | El umbral, el alcance y el intervalo temporal acordados. |
| SLA: acuerdo de nivel de servicio | Un acuerdo que contempla consecuencias si no se cumplen los compromisos de servicio. | El acuerdo aplicable y sus propias condiciones de medición, si la revisión incluye el cumplimiento contractual. |
No etiquetes el resultado de un SLO interno como «cumplimiento del SLA» solo porque los porcentajes se parecen. El acuerdo puede tener otro alcance, otras exclusiones u otro periodo de cálculo. Separa el resultado operativo de la evaluación contractual: una diapositiva, por sí sola, no demuestra un incumplimiento contractual ni el derecho a una compensación.
Ejemplo desarrollado: un servicio de envío de solicitudes
El servicio, los registros y las cifras siguientes son ficticios. Sirven para mostrar cómo preparar la revisión; no son datos de rendimiento de Presenti ni un caso real de un cliente.
Una plataforma de soporte está revisando si sus clientes pudieron enviar nuevas solicitudes. El SLO acordado exige una tasa de éxito del 99,90 % para este periodo fijo de 28 días. La ficha de medición debe aparecer junto al resultado, no quedar escondida en un anexo.
| Campo | Definición utilizada |
|---|---|
| Tarea del usuario | Enviar una nueva solicitud de soporte y recibir un identificador de solicitud utilizable. |
| Periodo | Desde el 1 de septiembre a las 00:00 UTC hasta el 29 de septiembre a las 00:00 UTC, sin incluir este último instante: 28 días completos. |
| Evento incluido | Un intento de envío de producción autenticado y bien formado, admitido por la pasarela. Cada intento tiene su propio identificador de petición. |
| Evento correcto | La solicitud se almacena y el cliente que la envía recibe un identificador utilizable. |
| Tráfico excluido | Comprobaciones de estado, tráfico de prueba identificado y peticiones que no cumplen las reglas de inclusión acordadas previamente. Estas reglas se fijaron antes del periodo revisado. |
| Evidencia | Una exportación de la pasarela conservada sin cambios, cruzada con los resultados del servicio mediante el identificador de petición; la presentación incluye la versión de la consulta y la hora de extracción. |
| Límite de cobertura | Este SLI no mide los fallos que ocurren antes de que la petición llegue a la pasarela. |
El denominador cuenta intentos de envío, no clientes. Según esta definición, cada reintento es un nuevo intento. Si un cliente realiza diez intentos de envío en total, la revisión contiene diez eventos, no diez clientes afectados. Mantén esa distinción tanto en la etiqueta del gráfico como en las notas del presentador.
El límite de cobertura también importa. Una página de inicio de sesión averiada podría impedir que los clientes llegaran a la pasarela mientras el SLI siguiera pareciendo saludable. Señala esa carencia junto al resultado y utiliza evidencia adicional para analizar el recorrido completo. No mejores el porcentaje excluyendo peticiones fallidas una vez terminado el periodo.
Muestra el cálculo del presupuesto de error, no solo el color
La guía de Google para implementar SLO describe los indicadores basados en eventos como el número de eventos correctos dividido entre el total. Si el objetivo es inferior al 100 %, la diferencia determina la proporción permitida de eventos fallidos. Este es el cálculo para el periodo completo de nuestro ejemplo.
| Magnitud | Cálculo | Resultado |
|---|---|---|
| Intentos incluidos | Recuento de identificadores de petición dentro del alcance | 2.000.000 |
| Intentos correctos | Resultados satisfactorios confirmados | 1.998.600 |
| Intentos fallidos | 2.000.000 − 1.998.600 | 1.400 |
| Tasa de éxito medida | 1.998.600 ÷ 2.000.000 × 100 | 99,93 % |
| Intentos fallidos permitidos | 2.000.000 × (1 − 0,9990) | 2.000 |
| Presupuesto consumido | 1.400 ÷ 2.000 × 100 | 70 % |
| Margen no utilizado en el periodo | 2.000 − 1.400 | 600 intentos |
Se cumplió el objetivo de éxito: el 99,93 % supera el 99,90 %. El margen es de 0,03 puntos porcentuales. El equipo consumió el 70 % de los fallos permitidos, no el 70 % de todas las peticiones.
Describe con precisión los 600 intentos restantes. Corresponden al periodo ya cerrado; no autorizan a causar 600 fallos el mes siguiente. Un SLO de producción con ventana móvil requiere su propio cálculo para la ventana vigente. Del mismo modo, un presupuesto basado en eventos no es un margen de inactividad medido en minutos. Un minuto de mucho tráfico y otro de poco tráfico pueden generar cantidades muy distintas de intentos fallidos.
Conserva los valores sin redondear en la hoja de origen y aplica un criterio de redondeo uniforme en las diapositivas. Si el resultado está cerca del umbral, evita que el redondeo convierta un incumplimiento en un aparente éxito. Guarda la consulta y el periodo con la diapositiva para que otra persona pueda reproducir el resultado.
Explica a quién afectaron los fallos
En los registros ficticios, un solo incidente explica 1.200 de los 1.400 intentos fallidos. Esos 1.200 intentos están asociados a 140 identificadores de cuenta distintos. Por tanto, el incidente consumió el 60 % del presupuesto de error total del periodo: 1.200 dividido entre 2.000. Los otros 200 fallos consumieron un 10 % adicional.
La diapositiva de impacto puede llevar un titular útil: «Un incidente consumió la mayor parte del presupuesto de error y afectó a 140 cuentas». Los datos no permiten afirmar que «140 personas no pudieron trabajar» ni que «se perdieron 1.200 solicitudes». Una cuenta puede tener varios usuarios, distintos intentos pueden corresponder a la misma solicitud deseada y el recuento de fallos no demuestra si finalmente se creó la solicitud.
Muestra el proceso afectado junto a la cifra. En este ejemplo, los clientes no podían obtener de forma fiable la confirmación de su solicitud durante el incidente. Los registros de soporte pueden ayudar a explicar qué hicieron después, pero unas pocas conversaciones no permiten describir el comportamiento de todas las cuentas afectadas.
Un pequeño panel de impacto puede contener tres líneas:
- Observado: 1.200 intentos fallidos vinculados al incidente; 140 identificadores de cuenta distintos en esos registros.
- Aún sin determinar: cuántas solicitudes deseadas se abandonaron en lugar de enviarse correctamente en un intento posterior.
- Siguiente análisis: conciliar los intentos con las solicitudes finalmente creadas antes de comunicar un número de abandonos.
Por eso deben mostrarse juntos el resultado global y el impacto sobre los usuarios. Cumplir el objetivo responde a una pregunta; la interrupción concentrada en un proceso concreto responde a otra. Ninguna debe ocultar la otra.
Convierte el resultado en una decisión sobre fiabilidad
La revisión no consiste en elegir el objetivo más alto posible. Pregunta qué acción resolvería el problema observado, qué evidencia la respalda y qué otro trabajo habría que posponer. Proponer un cambio del 99,90 % al 99,99 % no mejora por sí mismo el servicio.
En el ejemplo, la persona responsable del servicio puede comparar estas opciones:
| Opción | Qué aborda | Evidencia necesaria antes de ampliar el compromiso |
|---|---|---|
| Investigar la vía que concentra los fallos | El incidente responsable de 1.200 intentos fallidos. | Un fallo reproducible y una prueba que compare posibles mitigaciones; la coincidencia temporal no basta para atribuir una causa. |
| Ampliar la medición antes de la pasarela | El punto ciego entre el navegador del cliente y el SLI actual. | Una propuesta acotada que explique la cobertura, el tratamiento de los datos y el esfuerzo de implementación. |
| Endurecer ahora el SLO | Un compromiso de fiabilidad más exigente. | Evidencia de que el nuevo objetivo responde a las necesidades de los usuarios y un plan acordado para el trabajo adicional. |
Las dos primeras opciones responden a hallazgos concretos. La tercera exige una decisión aparte sobre expectativas y coste. No rebajes el objetivo sin explicarlo para que el informe salga en verde, ni lo eleves solo para que la diapositiva parezca más ambiciosa.
Si tu organización ya tiene una política de presupuesto de error, indica qué acción exige y quién puede aprobar una excepción. Si no existe, presenta la política como una propuesta. Quien expone no debe inventarse una suspensión automática de los lanzamientos y dar a entender que ya ha sido acordada.
Prepara una revisión de seis diapositivas que siga siendo útil después
La presentación principal puede ser breve porque el detalle queda en el paquete de evidencias. Asigna una función a cada diapositiva:
- Resultado y decisión: un 99,93 % de éxito frente al 99,90 %; un incidente concentrado; el trabajo concreto cuya autorización solicitas.
- Alcance de la medición: tarea del usuario, fechas, eventos incluidos y correctos, fuente y carencia de cobertura.
- Presupuesto: numerador, denominador, fallos permitidos y cálculo del 70 % consumido.
- Impacto sobre los usuarios: proceso afectado, los 140 identificadores de cuenta observados y lo que sigue sin saberse.
- Opciones: acciones alternativas, evidencia que necesita cada una y trabajo que desplazarían.
- Registro de la decisión: responsable, alcance aprobado, próxima revisión y evidencia que se espera para entonces.
Guarda las exportaciones de métricas y los detalles de las consultas con la presentación, pero evita copiar datos personales de clientes en las diapositivas. Para una audiencia más amplia, utiliza un resumen del impacto sin información identificativa. Si se propone cambiar una definición, preséntala como una versión futura y mantén el resultado actual asociado a la definición con la que se calculó.
El registro de decisión de la reunión ficticia podría quedar así:
Se aprueba una investigación de la vía de fallo de confirmación de solicitudes con una dedicación de dos jornadas de ingeniería, bajo la responsabilidad de la persona que dirige el servicio. Deberá aportar una reproducción, opciones de mitigación y resultados de pruebas; todavía no se afirma que vaya a reducir los fallos futuros. El SLO de éxito del 99,90 % se mantiene. En la siguiente revisión se presentará también una propuesta acotada para medir los fallos de envío anteriores a la pasarela. Cualquier implementación que exceda la investigación requerirá una decisión de capacidad independiente.
Ese registro da a la siguiente reunión un punto de partida concreto. El equipo revisará evidencia procedente de un trabajo definido, en vez de presentar el mismo porcentaje verde y repetir la misma promesa.
