Cómo crear una página de estado en la que los clientes realmente confíen

La mayoría de las páginas de estado existen. Pocas son de confianza. Una página que siempre está en verde durante las caídas es peor que no tener página, porque enseña a los clientes a dejar de mirarla. Una página de estado de confianza tiene cuatro propiedades: es honesta sobre lo que está roto, es rápida en admitir incidentes, delimita cuidadosamente el impacto y responde a la pregunta «¿esto me afecta?» sin obligar al lector a buscar. Esta guía cubre cómo diseñar una.

Qué quieren realmente los clientes de una página de estado

Dos preguntas motivan cada visita a una página de estado. Los clientes quieren saber si lo que les importa está roto y si alguien se ha dado cuenta. Todo lo demás es decoración.

Si la página responde a ambas preguntas a primera vista, los clientes confían en ella y dejan de llamar a soporte. Si no responde a ninguna, cada incidente produce cinco tickets de soporte adicionales y una lenta pérdida de credibilidad. El diseño visual importa menos que la estructura de lo que se muestra por encima del pliegue.

Las cuatro propiedades de una página fiable

Cuatro propiedades separan una página de estado útil de una de vanidad. Acierte las cuatro y los clientes confiarán en la página durante un incidente real.

• Honestidad. Si algo está roto, se muestra como roto. Si aún no lo sabe, la página indica que está investigando. El verde durante un incidente real destruye la confianza para siempre.
• Rapidez. Los incidentes se publican a los pocos minutos de la detección. Una actualización de estado que va una hora por detrás de las caídas reales se trata como texto de marketing.
• Claridad de alcance. El cliente puede saber, en segundos, si el incidente afecta a lo que usa. La región, el área del producto y la gravedad son las tres dimensiones que hay que etiquetar.
• Lenguaje sencillo. Las actualizaciones se redactan con la misma voz que utilizaría para explicar el incidente a un amigo, no en prosa corporativa en voz pasiva.

Actualizaciones de incidentes que funcionan

La mayoría de las plantillas de páginas de estado adoptan por defecto un tono pasivo y cauteloso. «Estamos investigando informes de latencia elevada». Esto se lee como evasión. El patrón que genera confianza es el inverso: nombre lo que está roto, nombre el impacto en el usuario, nombre lo que está haciendo al respecto.

Una buena primera actualización se lee así: «Los inicios de sesión están fallando para aproximadamente el 30% de los clientes en regiones de la UE. Nuestro failover de base de datos está en curso, ETA 10 minutos». Una buena resolución se lee así: «Los inicios de sesión están restaurados. La causa raíz fue un script de failover bloqueado. Hemos añadido un watchdog para que esto no pueda quedarse atascado en silencio de nuevo». Ambas son cortas. Ambas nombran el impacto, la acción y el seguimiento.

Delimitar correctamente el alcance del impacto

Una única página de estado global es la abstracción incorrecta una vez que tiene más de una línea de producto o región. Al cliente con un despliegue solo en EE. UU. no le importa que su región de la UE tenga latencia elevada.

• Divida su página por componente: la API, el panel, la ingesta, la facturación, etc. Muestre el estado por componente, no un único indicador global.
• Añada una dimensión de región o entorno donde corresponda. Marque explícitamente la región afectada durante los incidentes.
• Muestre los incidentes de los últimos 90 días debajo del estado en vivo. La vista histórica es la que los visitantes consultan para decidir si usted es lo bastante fiable como para apostar por él.
• Si lo ofrece, exponga un feed RSS o JSON para que los clientes interesados puedan suscribirse en sus propias herramientas.

Mantenimiento programado sin el silencio

El mantenimiento programado es la parte más fácil de acertar en la página de estado y una de las más omitidas. Publique la ventana con 48 horas de antelación, resuma qué se verá afectado y qué no, y publique una actualización de seguimiento confirmando la finalización.

Trate el mantenimiento programado con el mismo tono que las actualizaciones de incidentes. Nombre la ventana. Nombre los servicios afectados. Nombre el impacto. Una publicación de mantenimiento limpia evita anticipadamente un ticket de soporte. Una imprecisa genera una docena.

La fiabilidad de la propia página de estado

Aloje la página de estado en un lugar independiente de su infraestructura principal. Si su página de estado devuelve el mismo error de base de datos que su panel durante una caída de la base de datos, la propia página pasa a formar parte del incidente. Una página de estado que se carga desde un proveedor distinto, una región distinta o una CDN estática es la pequeña dosis de disciplina arquitectónica que se rentabiliza la primera vez que tiene una caída real. La mayoría de los equipos descubren esto por las malas.