Página de estado: o que é e porque a tua agência devia ter uma para cada cliente

São dez e meia da manhã e o site de um cliente está em baixo. Já sabes, já percebeste que é do alojamento, e já abriste o pedido de apoio. O que estás a fazer neste momento, no entanto, é a responder à terceira mensagem a perguntar se já está resolvido.

Durante uma falha, o trabalho não é resolver a falha. É resolver a falha enquanto três pessoas perguntam se já está resolvida — e cada resposta é tempo tirado ao problema.

O que é uma página de estado.

Uma página de estado é um endereço fixo, público, onde qualquer pessoa vê se um serviço está a funcionar sem ter de perguntar a ninguém. Costuma ter três coisas: o estado actual de cada serviço vigiado, os incidentes abertos com a hora a que começaram, e o histórico dos últimos dias ou meses.

Já usaste dezenas sem lhes chamar isso. Quando o teu alojamento vai abaixo, a primeira coisa que fazes é abrir a página que ele mantém para isso. Quando o Slack fica estranho, idem. É o reflexo de qualquer pessoa técnica, e o que ele revela é o valor da coisa: o que se quer, no meio de uma falha, é uma fonte que não é outra pessoa.

O que ela resolve numa agência.

Três coisas, e a terceira é a menos óbvia.

Corta as perguntas pela raiz. Em vez de responder a cada mensagem, respondes uma vez e mandas o link. As perguntas seguintes vão à página em vez de irem a ti. Numa agência com quarenta sites, isto é a diferença entre uma manhã perdida e uma manhã com uma falha.

Torna o teu trabalho visível quando não há falhas. É o problema estrutural de quem factura manutenção: o sucesso é invisível. Um mês em que nada correu mal parece, do lado de lá, um mês em que ninguém fez nada. Uma página que mostra 99, vírgula qualquer coisa por cento durante trinta dias é a prova permanente de que alguém está a olhar.

Muda a leitura que o cliente faz das falhas. Um incidente escrito, datado e fechado parece controlo. O mesmo incidente contado ao telefone, à pressa, parece uma desculpa. É rigorosamente a mesma falha — o que muda é ter sido publicada por ti antes de ser descoberta por eles.

O que deve estar lá, e o que não deve.

O erro mais comum é encher a página. Uma com dezassete componentes é um painel interno com outro nome, e quem a abre não sabe qual das dezassete linhas responde à pergunta que tem.

Deve lá estar:

• O estado de cada coisa que o cliente reconhece. “Site”, “loja”, “área reservada”. Não “balanceador”, não “base de dados”, não “fila de envio”.
• A hora a que o incidente começou. Sem isto, a página diz “há um problema”, que é o que a pessoa já sabia.
• Uma frase em português sobre o que se passa. “O alojamento está com uma falha e já abrimos um pedido de apoio.” Chega. Ninguém quer o traceback.
• O histórico. É a parte que trabalha nos 29 dias em que não há nada a acontecer.

Não deve lá estar: percentis, gráficos com legenda, códigos de estado em bruto, nem — e isto é uma decisão a tomar antes e não durante — a identificação de quem teve a culpa. Uma página que aponta o dedo ao alojamento em cada incidente ensina o cliente a duvidar da tua escolha de alojamento.

O nível a que quase toda a gente tropeça: o domínio.

Uma página alojada em alguma-ferramenta.com/estado/cliente-42 passa uma mensagem completamente diferente de uma em estado.cliente.pt. A primeira diz “revendemos uma ferramenta”. A segunda diz “isto é nosso”.

Se estás a avaliar ferramentas com este objectivo, o domínio próprio é a primeira pergunta a fazer, e frequentemente é a que separa o plano gratuito do plano pago. A segunda pergunta é quantas o plano permite — com uma carteira de trinta clientes, um limite de três não serve para nada.

E se quiseres uma hoje, com pouco.

Não precisas de uma ferramenta dedicada para ter a versão que resolve 80% do problema. O que precisas é de um endereço fixo que exista, que o cliente saiba de cor, e que não esteja alojado no mesmo sítio que o site que pode cair.

A versão mínima honesta é uma página estática num alojamento diferente, com o estado escrito à mão durante um incidente e o histórico como uma lista de datas. É trabalho manual e não escala para trinta clientes — mas para o cliente que mais te liga, resolve na semana em que a montares.

Duas coisas a não fazer: não a alojes no mesmo servidor do site (uma página que cai com o serviço que descreve é pior do que não existir), e não prometas actualizações em tempo real se as vais escrever à mão. Uma página desactualizada durante uma falha destrói exactamente a confiança que devia construir.

Onde a De Olho está nisto.

Vale dizê-lo com todas as letras: a De Olho não vai ter páginas de estado no lançamento. É a peça em que várias ferramentas concorrentes estão à nossa frente, está na lista do que queremos fazer, e não tem data. Escrevemos sobre o assunto na mesma porque a pergunta é legítima e porque a resposta útil não depende de nós.

Se isto é o teu requisito principal, escolhe uma ferramenta por ela e não esperes por nós. Há dedicadas a isso, algumas com plano gratuito utilizável. A página com o detalhe do que vamos fazer, e quando está escrita com a etiqueta “em breve” precisamente para não haver dúvida.

O que uma página de estado não faz.

Não reduz o tempo de falha em um único minuto. Não substitui a mensagem que escreves ao cliente quando o incidente é grande — uma página é o canal de consulta, não o canal de aviso, e comunicar downtime a clientes é outro trabalho, com regras próprias e um relógio diferente. E não protege de nada: se o site está em baixo há duas horas e a página o diz com precisão, continua a estar em baixo há duas horas.

O que ela faz é tirar-te de cima o trabalho de ser o intermediário entre uma dúvida e uma resposta que já existe. Nas horas em que isso acontece, é bastante.