Objetivos de nivel de servicio que frenan un despliegue, y los que solo decoran un panel

La secuencia habitual es esta. Alguien decide que el equipo necesita objetivos de nivel de servicio. Abre la herramienta de monitorización, busca una métrica que ya exista y encuentra el tiempo de actividad de las máquinas. Fija el objetivo en el 99,9 por ciento porque tres nueves suenan serios. El número acaba en un panel, se mantiene verde once meses y al duodécimo hay una caída seria que el panel también muestra en verde, porque las máquinas estuvieron encendidas todo el rato.

El fallo no es el número. Es que el indicador se eligió desde lo que era fácil de medir y no desde lo que siente el usuario, y que nada del proceso de entrega lo consulta jamás. Un objetivo que no puede cambiar una decisión es un adorno con coste de mantenimiento.

El indicador nace del usuario, no de la métrica que ya tienes

Pregunta qué está intentando hacer un usuario y qué significa para él "ha funcionado". En una API, el usuario es una aplicación cliente y la respuesta es "mi petición obtuvo una respuesta correcta lo bastante rápido". En un proceso por lotes es "el dato de ayer estaba en el almacén antes de que yo abriera el informe".

La disponibilidad del servidor no responde a nada de eso. Una máquina puede estar encendida mientras la aplicación devuelve errores 500, mientras su dependencia está caída, mientras las respuestas tardan nueve segundos o mientras la cola que hay detrás lleva cuatro horas de retraso. El tiempo de actividad es una propiedad de tu infraestructura. El indicador tiene que ser una propiedad de la interacción.

Mide en el punto más cercano al usuario que controles. La pasarela suele ser el sitio correcto; la instrumentación de la propia aplicación es la segunda opción, porque no puede contar las peticiones que nunca le llegaron.

Define el evento bueno y el evento malo con precisión dolorosa

Aquí es donde la mayoría de documentos se quedan vagos y quedan inservibles seis meses después. Escríbelo como una proporción y di exactamente qué va en el numerador y qué en el denominador.

Mal: "99,9 por ciento de disponibilidad". Bien: "la proporción de peticiones HTTP a /api/v1/*, excluyendo /health, que devuelven un estado distinto de 5xx y terminan en menos de 400 ms, medidas en la pasarela, por minuto".

Después resuelve por escrito los casos límite, porque aparecen en el primer incidente. ¿Un 429 es un evento malo? ¿Se excluyen los 4xx, y esa exclusión tapa los 400 que provocaste tú con un cambio de esquema incompatible? ¿Cuenta una ventana de mantenimiento, teniendo en cuenta que "planificada" es una propiedad de tu calendario y no del día del usuario? ¿Entra el tráfico sintético en el denominador, manteniendo la proporción sana a las tres de la mañana cuando no hay usuarios reales?

El objetivo sale de lo que el negocio tolera, no del número de nueves más bonito

No empieces por los nueves. Empieza por el rendimiento medido del último trimestre y por la pregunta: ¿por debajo de qué nivel los clientes lo notan, se quejan o se van?

Después calcula qué te compra el siguiente nueve. Pasar de 99,9 a 99,99 divide entre diez el fallo permitido, y eso normalmente significa multirregión activo-activo, un proceso de despliegue más duro y otra guardia. Merece la pena en la autorización de pagos; no la merece en un panel de administración interno.

Dos reglas que ahorran discusiones. El objetivo tiene que estar claramente por debajo de tu mejor mes, o no hay presupuesto que gastar y el mecanismo nace muerto. Y si tienes un acuerdo de nivel de servicio con clientes, el objetivo interno va más estricto que él, para enterarte tú antes de que te lo facturen.

El presupuesto de error es el mecanismo de decisión, o todo esto es teatro

El presupuesto es el complemento aritmético del objetivo: un 99,9 por ciento sobre 30 días son unos 43 minutos de fallo permitido. Lo que lo hace útil es acordar por adelantado qué cambia cuando se agota.

La política que instalamos con clientes es corta. Por encima de la mitad del presupuesto, se despliega con normalidad y se hacen los experimentos arriesgados. Por debajo de un cuarto, no hay despliegues no esenciales en ese servicio y el trabajo de fiabilidad sube a la cabeza del backlog. Agotado, congelación de funcionalidad hasta que se recupere, con una persona concreta que puede saltárselo y registro de cada excepción.

La gracia no es castigar. Es que "¿lanzamos este cambio arriesgado?" deja de ser un pulso entre quien quiere velocidad y quien quiere estabilidad, y pasa a ser una consulta contra un número que ambos acordaron el trimestre pasado.

Usa una ventana móvil, de 28 o 30 días, no un mes natural. El mes natural concede una amnistía a medianoche del día uno, así que una semana mala el día 29 queda perdonada dos días después. Una ventana móvil mantiene el incidente en el denominador cuatro semanas, que es más o menos lo que debe durar la lección.

Cuando el presupuesto se agota

Tres casos, tres respuestas. Quemado en un incidente grande: el presupuesto hizo su trabajo, así que congela, arregla la causa concreta y reanuda. Quemado en un goteo constante de fallos pequeños: la causa suele ser una dependencia o un recurso saturado, y el arreglo es capacidad o un cortacircuitos, no heroicidades. Quemado todos los meses: el objetivo está mal o la arquitectura no lo soporta, así que o lo bajas con el negocio delante o financias el trabajo que lo haría alcanzable. Ignorar en silencio un presupuesto permanentemente agotado le enseña a la organización que el objetivo es ficción.

Lo que se olvida

• Tres o cuatro objetivos valen más que treinta. Un objetivo por endpoint es una hoja de cálculo, no una política. Presupuesta los recorridos que generan ingresos o que bloquean trabajo, y monitoriza el resto sin presupuestarlo.
• El indicador necesita su propia fiabilidad. Si la tubería de métricas pierde datos, el objetivo mejora solo. Alerta sobre la ausencia de datos como condición aparte.
• Las dependencias se comen tu presupuesto. Sobre un servicio gestionado con un acuerdo del 99,9, un objetivo del 99,99 encima es una aritmética que no ganas sin redundancia entre regiones o proveedores.
• La latencia necesita un umbral, no una media. Una media de 200 ms esconde a un diez por ciento de usuarios en cuatro segundos. Cuenta las peticiones que pasan la raya.
• Revisa los objetivos cada trimestre. Un objetivo que nadie ha tocado en dos años es un fósil.

Cuando los objetivos existen deben gobernar también la política de avisos, que es el tema de las alertas que la gente sí atiende: la velocidad de quema de un presupuesto es mucho mejor disparador que un umbral fijo sobre una gráfica. Montamos ambas cosas en la fase de fiabilidad de un proyecto cloud.

Qué hacer esta semana

Coge tu recorrido de usuario más importante y escribe una frase que defina el evento bueno y el evento malo, nombrando el punto de medida. Después consulta los últimos 30 días y calcula la proporción real. Sabrás enseguida si el objetivo que ibas a elegir es ambicioso, trivial o ya está roto, y esa hora de trabajo es todo el cimiento.