Qué es una página de estado y qué debe llevar
Una página de estado es una página alojada aparte de tu servicio que muestra si cada parte de él está funcionando ahora mismo, más un registro de las incidencias actuales y pasadas. Su trabajo es responder "¿eres tú o soy yo?" sin que nadie tenga que abrir un ticket de soporte.
Qué va en una página de estado
Una página de estado tiene tres capas, y la mayor parte del valor está en las dos primeras.
La capa superior es el estado actual de cada componente que listas. Los componentes son las piezas que un cliente puede distinguir: el sitio web, la API, el panel, los inicios de sesión, el flujo de pago, el backend de una app móvil. El estado suele ser una escala corta en lugar de binaria, para que puedas decir "degradado" para un servicio que va lento pero responde, en lugar de elegir entre una marca verde equivocada y una cruz roja que es peor.
La capa intermedia es el flujo de incidencias. Cada incidencia es una entrada corta con una hora de inicio, una descripción llana de lo que van a notar los clientes, y actualizaciones que se añaden a medida que cambia la situación, terminando con una nota de resolución. Las incidencias pasadas siguen visibles, que es lo que convierte la página en un registro y no en un interruptor de luz.
La capa inferior es el historial: el uptime de los últimos 30 o 90 días por componente. Es la parte menos urgente y la que más a menudo leen las personas que te están evaluando.
Pública o privada
Una página de estado pública está abierta a cualquiera que tenga el enlace, y es la opción correcta cuando tus clientes son el público general o cuando publicas un SLA. También absorbe el tráfico durante una caída de personas que ni siquiera son clientes.
Una página de estado privada está restringida a clientes con sesión iniciada o a una audiencia interna. Los equipos la usan cuando la lista de componentes expondría la arquitectura interna, cuando las incidencias involucran a clientes empresariales concretos, o cuando la página cubre sistemas internos que ningún externo debería estar enumerando. La contrapartida es que cualquiera que no pueda acceder a ella va a contactar con soporte en su lugar.
Elijas la que elijas, aloja la página lejos de la infraestructura sobre la que informa. Una página de estado que se cae con el servicio es peor que no tener ninguna, porque su silencio durante una caída se lee como una afirmación de que no pasa nada.
Escribir una incidencia
Una entrada de incidencia se escribe para un cliente, no para los ingenieros que la están arreglando. Eso significa el síntoma primero, la causa después, si es que se llega a dar.
- Abre la incidencia en cuanto hayas confirmado el problema, aunque todavía no sepas la causa. "Estamos investigando informes de errores en el pago" publicado en el minuto dos vale más que una explicación completa en el minuto noventa.
- Di qué va a ver un cliente y qué puede hacer al respecto, incluida una solución alternativa si la hay.
- Actualiza con un ritmo que anuncies por adelantado, y publica la actualización incluso cuando sea "todavía sin cambios". El silencio se lee como abandono.
- Cierra con una hora de resolución y, para cualquier cosa larga o grave, una nota corta de lo que pasó después.
Haz que el estado del componente coincida con la incidencia. Una incidencia abierta en un componente que todavía muestra verde es la forma más rápida de perder la confianza en la página. Si el fallo de fondo es un servidor rechazando peticiones, 503 Service Unavailable es la respuesta que probablemente te estén citando tus clientes.
Mantenimiento programado
El trabajo planificado va en la misma página, anunciado con antelación con una ventana y un impacto esperado. Publicarlo por adelantado convierte una caída en una cita: los clientes que vieron el aviso no abren tickets, y los que no lo vieron al menos pueden encontrar la explicación mientras está pasando.
Distingue el mantenimiento de una incidencia visualmente y en el registro, y mantén honesta la ventana anunciada. Una ventana de mantenimiento que se pasa de tiempo con regularidad entrena a la gente a ignorar la siguiente.
Por qué reduce la carga de soporte
Durante una caída, la cola de soporte se llena con la misma pregunta hecha muchas veces. Una página de estado la responde una vez, en una dirección a la que puedes apuntar desde tu respuesta automática de soporte, el estado de error de tu app y tus cuentas sociales. Eso convierte una hora de triaje repetitivo en un enlace.
El efecto secundario está en la confianza. Publicar incidencias cuesta menos de lo que parece, porque los clientes que notaron la caída ya saben que ocurrió. Lo que están juzgando es si se lo contaste.
De dónde viene el estado
Una página de estado solo es tan buena como la monitorización que hay detrás. Si un humano tiene que notar una caída antes de que cambie la página, la página siempre va a ir por detrás de los clientes que la leen, así que los estados de los componentes deberían impulsarlos comprobaciones que se ejecutan de forma continua desde fuera de tu red. HostTracker aloja páginas de estado alimentadas por su propia monitorización, que comprueba desde más de 300 puntos de control en 158 ciudades con 13 tipos de monitor, así que el estado de un componente sigue los resultados de las comprobaciones en lugar de depender de que alguien se acuerde de actualizarlo. Para ver cómo son esas comprobaciones, consulta la guía de la comprobación HTTP, y el resto de la sección de conceptos de monitorización para los términos que la rodean.