Como descobres que o teu site está em baixo antes de um cliente te dizer?
Em resumo
Ser avisado por um cliente custa duas vezes: perdeste as vendas e ficaste com ar de quem não estava a olhar. Saber primeiro exige três coisas: uma verificação que siga aquilo que um cliente faz, um alerta por um canal que não podes falhar, e contenção para ainda acreditares nele ao fim de um mês.
Toda a paragem tem dois custos. O primeiro são as encomendas que não fizeste. O segundo é a frase «o vosso site está em baixo desde ontem», escrita por um cliente que descobriu antes de ti — e essa paga-se em confiança, durante muito mais tempo.
Porque é que o cliente repara antes de ti?
Porque o cliente está a fazer uma coisa concreta: comprar, entrar na conta, pagar. Tu estás a olhar para um painel, ou nem sequer estás a olhar.
As histórias são sempre parecidas. Um site em baixo durante pelo menos um dia, notado só porque um serviço de terceiros sem relação nenhuma calhou mostrar a página por omissão do Apache. Outro, em que o alerta da paragem tinha sido enviado corretamente e tinha aterrado no spam. Em ambos, não foi a vigilância que falhou: foi o reparar.
A página inicial chega?
É o mínimo, e responde a uma pergunta mais estreita do que a maioria das pessoas pensa. Uma página inicial que devolve 200 prova que um servidor web está a responder naquele endereço. Não prova que a entrada na conta funciona, que o cesto junta, que o passo do pagamento carrega, que a pesquisa devolve alguma coisa, nem que o e-mail da encomenda sai de casa.
As falhas que doem a uma loja em linha estão quase todas a jusante da página inicial. Por isso a verificação também tem de ir a jusante: uma sequência guardada que abre uma página, segue uma ligação, submete um passo e espera um código de estado concreto ou uma palavra concreta no ecrã. Se o passo quatro deixar de devolver a página de pagamento, ficas a saber antes de o primeiro cliente desistir.
Mais duas verificações pertencem ao mesmo grupo, porque falham por calendário e não ao acaso: o certificado TLS, contado em dias que faltam, e a data de expiração do próprio domínio. Um certificado expirado é uma paragem total para todos os visitantes, anunciada com semanas de antecedência a quem estivesse a contar.
O que tem de acontecer entre a falha e o teu telefone a tocar?
Cinco coisas: ser confirmada, saber de quem é a culpa da rede, chegar onde tu estás, não se repetir nove vezes, e voltar se te esqueceres. É esta a parte que decide se a vigilância é útil ou apenas barulhenta.
Tem de ser confirmada. Uma única verificação falhada quer dizer muito pouco: um momento lento, um pacote perdido, um soluço de rede algures entre as duas pontas. Exigir que a falha se repita, e pedir a um segundo ponto de observação que concorde, tira a maior parte dos alarmes falsos sem acrescentar atraso digno desse nome.
Tem de saber de quem é a culpa da rede. Se quem perdeu a ligação foi o vigilante e não o vigiado, isso não é uma paragem tua e não pode ser contada como tal. Essas falhas devem ficar de quarentena e ser comunicadas como um aviso da plataforma, não como nove incidentes na tua conta.
Tem de chegar onde tu estás. O e-mail é o registo, não o alarme; é filtrado, arrumado e lido de manhã. Uma mensagem numa conversa chega-te durante o dia. Uma chamada telefónica é o que queres para os dois ou três serviços em que uma hora de silêncio é mesmo cara — e deve respeitar as horas de descanso, para que as que tocam de noite queiram dizer alguma coisa.
Não se pode repetir nove vezes. Quando um servidor vai, vai tudo o que está nele atrás. Um alerta para uma paragem, com uma única mensagem de recuperação, é a diferença entre um alerta que lês e um alerta que silencias.
Tem de voltar se te esqueceres. Um lembrete enquanto o serviço continua em baixo — ao fim de uma hora, ao fim de seis, depois todos os dias — apanha o incidente que foi dado como visto à meia-noite por alguém que a seguir voltou a adormecer.
E os clientes que perguntam na mesma
Enquanto estás a resolver, alguém tem de atender o telefone. Uma página de estado pública, com uma mensagem curta escrita na língua do visitante, transforma vinte interrupções numa ligação — e é também o registo do que aconteceu, que vais querer mais tarde, quando alguém perguntar quanto tempo durou.
O que fazer esta semana
- Faz a lista do que um cliente faz mesmo no teu site: entrar na conta, pesquisar, juntar ao cesto, pagar. São essas as tuas verificações, não a página inicial.
- Constrói uma sequência que percorra o mais valioso desses caminhos e espere uma palavra concreta no último passo.
- Põe os dias que faltam no certificado e a expiração do domínio num sítio onde os vejas.
- Escolhe um serviço que justifique uma chamada às 3 da manhã — só um, escolhido com honestidade — e encaminha-o para uma chamada.
- Escreve a página de estado antes de precisares dela. Ninguém escreve uma boa página de estado durante uma paragem.
O objetivo não é um painel perfeito. É que da próxima vez que alguma coisa se partir, já estejas a resolver quando o primeiro cliente escrever.
O que não te podemos dizer
- Não conseguimos ver se a confirmação de encomenda chegou à caixa de correio do cliente: vemos que o teu site aceitou a encomenda, não o que o fornecedor de correio fez com a mensagem depois disso.
- Não conseguimos concluir um pagamento verdadeiro para o testar: uma transação sintética percorre os passos e pára antes de cobrar seja o que for, por isso o que acontece do lado do banco fica fora da nossa vista.
- Não conseguimos ver uma fila de espera, uma tarefa agendada ou uma importação encravada, a não ser que alguma coisa do teu lado publique um número que possamos ler.
- Não te podemos dizer porque é que se partiu. Dizemos-te o que falhou, quando, a partir de onde, e o que a verificação viu; a causa continua a ser tua para descobrir, mas com uma informação de partida melhor.
As perguntas que se fazem mesmo
Em quanto tempo é que eu ficava a saber?
Depende da frequência com que o site é verificado — de cinco em cinco minutos no plano gratuito até de quinze em quinze segundos — mais uma confirmação curta. Uma falha tem de se repetir em verificações consecutivas e, nos monitores em que o pedires, um segundo ponto de observação tem de a ver também, antes de alguém ser acordado. Um solavanco isolado nunca se transforma numa chamada.
A minha página inicial está bem, mas os clientes não conseguem finalizar a compra. Isso era apanhado?
Só se alguma coisa verificar a finalização da compra. Uma página inicial que devolve 200 prova que o servidor web está a responder, e mais nada. A verificação que apanha isto é uma transação sintética: uma sequência de passos guardada — abrir o produto, juntar ao cesto, chegar ao passo do pagamento — em que cada passo tem de devolver a página esperada. Percorre o caminho que um cliente percorre e pára antes de uma cobrança verdadeira.
E se o alerta for parar ao spam, como da última vez?
Então o alerta não existe. Esta é a maneira mais comum de uma paragem durar um dia inteiro: a mensagem foi enviada e foi filtrada. Usa mais do que um canal para o que interessa — e-mail para ficar registo, uma mensagem numa conversa que já lês de qualquer maneira, e uma chamada telefónica para o punhado de serviços que justificam acordar alguém. Um telefone a tocar é o único canal que não depende de alguém estar a olhar.
Como evito ser acordado por nada?
Obrigando a plataforma a provar a paragem antes de a fazer subir: verificações falhadas consecutivas em vez de uma só, confirmação a partir de um segundo local, e uma regra que diz que, quando foi a nossa própria rede que se partiu, o teu serviço não é dado como em baixo por causa disso. Depois agrupa o que acontece junto — um servidor que cai leva vários monitores atrás de si, e isso deve ser um alerta, não nove.
E o certificado e o domínio?
Os dois falham numa data fixa, o que faz deles as paragens mais fáceis do mundo de evitar e as mais embaraçosas de ter. Vigia os dias que faltam no certificado e a data de expiração do próprio domínio, e trata o aviso como uma tarefa com data marcada, não como uma notificação para dispensar.