O que é uma página de status e o que deve constar nela

O que entra em uma página de status

Uma página de status tem três camadas, e a maior parte do valor está nas duas primeiras.

A camada superior é o estado atual de cada componente que você lista. Componentes são as partes que um cliente consegue diferenciar: o site, a API, o painel, os logins, o fluxo de pagamento, o backend de um aplicativo móvel. O estado geralmente é uma escada curta em vez de um binário, então você consegue dizer "degradado" para um serviço que está lento mas respondendo, em vez de escolher entre um tique verde que está errado e uma cruz vermelha que é pior.

A camada intermediária é o feed de incidentes. Cada incidente é uma entrada curta com um horário de início, uma descrição simples do que os clientes vão perceber, e atualizações anexadas conforme a situação muda, terminando com uma nota de resolução. Incidentes passados continuam visíveis, o que é o que transforma a página em um registro em vez de um interruptor.

A camada inferior é o histórico: uptime nos últimos 30 ou 90 dias por componente. É a parte menos urgente e a que é mais lida por pessoas avaliando você.

Pública ou privada

Uma página de status pública está aberta a qualquer um com o link, e é a escolha certa quando os seus clientes são o público geral ou quando você publica um SLA. Também absorve tráfego durante uma indisponibilidade vindo de pessoas que nem são clientes.

Uma página de status privada é restrita a clientes logados ou a uma audiência interna. As equipes a usam quando a lista de componentes exporia a arquitetura interna, quando incidentes envolvem clientes empresariais nomeados, ou quando a página cobre sistemas internos que nenhum estranho deveria estar enumerando. A troca é que qualquer um que não conseguir alcançá-la vai contatar o suporte em vez disso.

Qual você escolher, hospede a página longe da infraestrutura sobre a qual ela reporta. Uma página de status que cai junto com o serviço é pior do que nenhuma página de status, porque o silêncio dela durante uma indisponibilidade é lido como uma afirmação de que nada está errado.

Escrevendo um incidente

Uma entrada de incidente é escrita para um cliente, não para os engenheiros consertando. Isso significa o sintoma primeiro, a causa depois, se tanto.

1. Abra o incidente assim que você tiver confirmado o problema, mesmo que ainda não saiba a causa. "Estamos investigando relatos de erros no checkout" postado no minuto dois vale mais do que uma explicação completa no minuto noventa.
2. Diga o que um cliente vai ver e o que ele pode fazer a respeito, incluindo uma solução alternativa se houver uma.
3. Atualize em um ritmo que você declara antecipadamente, e poste a atualização mesmo quando for "ainda sem mudanças". Silêncio é lido como abandono.
4. Encerre com um horário de resolução e, para qualquer coisa longa ou grave, uma nota curta sobre o que aconteceu depois.

Combine o estado do componente com o incidente. Um incidente aberto em um componente ainda mostrando verde é o jeito mais rápido de perder confiança na página. Se a falha subjacente é um servidor recusando requisições, 503 Service Unavailable é a resposta que os seus clientes provavelmente estão citando para você.

Manutenção agendada

Trabalho planejado pertence à mesma página, anunciado com antecedência com uma janela e um impacto esperado. Postá-lo com antecedência transforma uma indisponibilidade em um compromisso: clientes que viram o aviso não abrem chamados, e os que não viram pelo menos conseguem encontrar a explicação enquanto está acontecendo.

Distinga manutenção de um incidente visualmente e no registro, e mantenha a janela anunciada honesta. Uma janela de manutenção que regularmente estoura treina as pessoas a ignorar a próxima.

Por que isso reduz a carga de suporte

Durante uma indisponibilidade, a fila de suporte se enche com uma pergunta feita muitas vezes. Uma página de status a responde uma vez, em um endereço que você pode apontar a partir do seu autorresponder de suporte, do estado de erro do seu aplicativo e das suas redes sociais. Isso converte uma hora de triagem repetitiva em um link.

O efeito secundário é sobre confiança. Publicar incidentes custa menos do que parece, porque os clientes que perceberam a indisponibilidade já sabem que ela aconteceu. O que eles estão julgando é se você contou a eles.

De onde vem o status

Uma página de status só é tão boa quanto o monitoramento por trás dela. Se um humano precisa perceber uma indisponibilidade antes de a página mudar, a página sempre vai estar atrás dos clientes que a leem, então os estados dos componentes deveriam ser conduzidos por verificações que rodam continuamente de fora da sua rede. A HostTracker hospeda páginas de status alimentadas pelo próprio monitoramento dela, que verifica a partir de mais de 300 pontos de verificação em 158 cidades, em 13 tipos de monitor, então o estado de um componente segue os resultados da verificação em vez de depender de alguém lembrar de atualizar. Para como são essas verificações, veja o guia de verificação HTTP, e o restante da seção de conceitos de monitoramento para os termos ao redor.