El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
Argumentos para mantener honesta una página de estado pública
Una página de estado existe para responder rápido a una pregunta concreta: ¿funciona ahora mismo aquello de lo que dependo y, si no, lo sabe ya el proveedor? Es un propósito limitado y útil, y solo funciona si la página refleja la realidad con suficiente fidelidad como para confiar en ella el día en que de verdad importa, que es el día en que algo está roto. Una página de estado que lleva dos años seguidos en verde describe o bien un sistema realmente impecable, algo poco común, o bien una página que se actualiza con un calendario que tiene poco que ver con lo que viven realmente los clientes.
El valor de una página de estado se concentra casi por completo en los momentos en que menos cómodo resulta actualizarla con honestidad: durante un incidente en curso, cuando el instinto es esperar a ver si se resuelve rápido antes de reconocerlo públicamente. Ese instinto es comprensible y también es justo lo contrario de lo que hace útil una página de estado. Un desarrollador que consulta una página de estado durante una caída en su lado quiere saber, lo antes posible, si el problema es suyo o del proveedor. Una página que espera a confirmar un incidente hasta que está totalmente entendido y resuelto responde a esa pregunta demasiado tarde como para que sirva de mucho.
Creemos que lo honesto es tratar una página de estado como una herramienta operativa puesta a disposición de los clientes, no como un escaparate de marketing. Eso significa publicar un incidente real cuando está ocurriendo un incidente real, incluso antes de conocer todos los detalles, y actualizarlo a medida que el panorama se aclara, en lugar de mantener la página en verde hasta tener listo un resumen limpio y totalmente resuelto. Un reconocimiento temprano y sin pulir es más útil para quien está depurando su propio sistema en tiempo real que uno pulido y tardío.
Esto conecta con algo que tenemos en cuenta en todo el producto, no solo en la comunicación de incidentes: dar a los desarrolladores información sobre la que puedan actuar, lo más cerca posible del tiempo real. Los encabezados de cuota en cada respuesta existen por el mismo motivo por el que una página de estado debería ser honesta durante un incidente. Ambos buscan no hacer esperar a nadie hasta después de los hechos para saber algo que habría cambiado lo que hizo en ese momento.
Una página de estado con alguna entrada amarilla o roja de vez en cuando no es un punto en contra del proveedor. Es la prueba de que la página está conectada a algo real. La página que más debería preocupar a un posible cliente es la que nunca muestra ninguna mancha, porque un sistema con realmente cero incidentes durante un periodo significativo es tan poco común que su ausencia en la página suele decir más de la página que del sistema.