O problema das chaves de API que nunca expiram
Uma chave emitida anos atrás, nunca trocada e ainda válida hoje não é uma conveniência. É um risco que ninguém examina de verdade há anos.
Por que uma página de status pública deve ser honesta
Uma página de status existe para responder rapidamente a uma pergunta específica: aquilo de que eu dependo está funcionando agora e, se não estiver, o provedor já sabe disso? É um propósito restrito e útil, e só funciona se a página refletir a realidade de perto o suficiente para ser confiável no dia em que realmente importa, que é o dia em que algo está quebrado. Uma página de status que mostra tudo verde há dois anos seguidos ou está descrevendo um sistema realmente impecável, o que é raro, ou está descrevendo uma página atualizada em um ritmo que tem pouco a ver com o que os clientes estão realmente vivenciando.
O valor de uma página de status se concentra quase inteiramente nos momentos em que é menos conveniente atualizá-la com honestidade: durante um incidente ativo, quando o instinto é esperar para ver se ele se resolve rápido antes de assumir um reconhecimento público. Esse instinto é compreensível e também é exatamente o oposto do que torna uma página de status útil. Um desenvolvedor que consulta uma página de status durante uma falha do lado dele quer saber, o mais cedo possível, se o problema está do lado dele ou do provedor. Uma página que espera para confirmar um incidente até que ele seja totalmente compreendido e resolvido responde a essa pergunta tarde demais para valer muita coisa.
Achamos que a abordagem honesta é tratar a página de status como uma ferramenta operacional colocada à disposição dos clientes, não como uma vitrine de marketing. Isso significa publicar um incidente real quando um incidente real está acontecendo, mesmo antes de todos os detalhes serem conhecidos, e atualizá-lo à medida que o quadro fica mais claro, em vez de manter a página verde até que um resumo limpo e totalmente resolvido esteja pronto para publicação. Um reconhecimento rápido e imperfeito é mais útil para alguém que está depurando o próprio sistema em tempo real do que um reconhecimento polido e atrasado.
Isso se conecta a algo em que pensamos em todo o produto, não só na comunicação de incidentes: dar aos desenvolvedores informações com as quais eles possam agir, o mais próximo possível do tempo real. Os cabeçalhos de cota em cada resposta existem pelo mesmo motivo pelo qual uma página de status deve ser honesta durante um incidente. Os dois têm a ver com não fazer alguém esperar até depois do fato para descobrir algo que teria mudado o que ele fez naquele momento.
Uma página de status com uma entrada amarela ou vermelha de vez em quando não depõe contra o provedor. É a prova de que a página está realmente conectada a algo real. A página que deveria preocupar mais um possível cliente é aquela que nunca mostra nenhuma mancha, porque um sistema com zero incidentes de verdade ao longo de um período significativo é raro o bastante para que a ausência deles na página normalmente diga mais sobre a página do que sobre o sistema.