Manutenção e monitoração com o mínimo de impacto ao usuário

Quando temos um estabelecimento físico e nos deparamos com um problema que necessita de reparo ou alguma reforma não é de bom grado deixar o “defeito” à mostra aos clientes. Queremos passar a imagem perfeita.

Problemas todos temos, há inúmeras ações preventivas como Unit Testing (inglês) e afins, porém dado o dano, é imperativo que toda operação seguinte transcorra com a maior cautela e menor aparência possível para minimizar quaisquer impactos com o relacionamento com o cliente.

Visão geral da falha

Uma falha é quando o conteúdo (input) passado para uma operação (função) não possui forma de ser tratado dentro da mesma, causando um erro, uma excessão à regra. Em caso de falha é como um incêndio: Precisamos primeiro acalmar as pessoas e evacuar o local para reduzir as casualidades.

Evitando que o usuário tenha contato com a mensagem de erro

Além de ser anti-estético também é uma falha de segurança. As mensagens de erro contém informações valiosas para o desenvolvedor localizar a falha entretanto também são valiosas para um usuário experiente mal-intencionado.

Reportando o erro aos desenvolvedores

Use um “error handler” (gerenciador de erros) de acordo com sua linguagem de programação que se encarregue de interceptar os erros e repassar aos desenvolvedores. Algumas das opções são:

File Logging (monitoramento passivo)

Consiste em gravar os erros em um arquivo de texto para análise forense. É imperativo que estes registros sejam monitorados constantemente.

SQL Logging (monitoramento passivo)

Consiste em gravar os erros em um banco de dados (MySQL, PostgreSQL, Sqlite etc) para análise forense. É imperativo que estes registros sejam monitorados constantemente.

E-mail Logging (monitoramento ativo)

O gerenciador envia o erro para contas de email previamente configuradas.

SMS Logging (monitoramento ativo)

Algumas operadoras de celular fornecem serviços de SMS via webservice ou alguma intervenção HTTP. Este tipo de gerenciamento consiste em enviar a mensagem de erro por mensagem de texto SMS para números de celulares. NOTA: Algumas operadoras fornecem serviço de SMS através de uma conta de e-mail, podendo assim usar o modelo de E-Mail Logging)

I.M. Logging (monitoramento ativo)

Temos inúmeras classes que implementam o protocolo MSNP9 e MSNP12 do Windows Live Messenger além do XMPP (Jabber/Google Talk). Neste modelo, as mensagens de erro são enviadas diretamente para contas de mensageiros instantâneos.

Screen Logging (monitoramento ativo)

Este é o que reporta as mensagens de erro na tela durante a execução da página. Deve ser habilitado somente para ambiente de desenolvimento.

O que enviar como mensagem de erro

Tudo que for possível sobre o estado do ambiente onde o erro foi gerado é importante. Em termos de web: As informações do servidor, os headers de request do browser, a sessão do usuário, o que foi enviado tanto por GET quanto por POST, os cookies e a cor da meia do usuário. Em PHP seriam as variaveis $_SERVER, $_REQUEST, $_SESSION, $_GET, $_POST e $_COOKIE respectivamente. (Ainda não fomos capazes de detectar o último item)

O polimorfismo comportamental

O sistema deve ser “duas caras”: se comportar de uma maneira quando no ambiente de desenolvimento quanto no de produção sem que seja necessária pilhas de configuração. Uma boa prática é deixar os módulos de logging encapsulados entre ifs de checagem de ambiente. Esta checagem pode ser tanto automática (por distinção do host) ou manual (por setagem de uma variável ou constante que defina o ambiente em vigor). Assim, o sistema saberá se enviará o erro na tela ou para os desenvolvedores ou ambos de forma natural.

Error reporting além da aplicação

Além de erros gerados durante o funcionamento da aplicação precisamos também monitorar erros 404 [página não encontrada] (decorrentes de linkagens errôneas) e 500 [erro interno do servidor] (que pode ser decorrente de N casualidades). O core do servidor web Apache fornece as diretivas ErrorDocument onde pode-se colocar scripts que façam o encaminhamento das informações de debug (página que estava tentando ser acessada que não foi encontrada etc) para os desenvolvedores da forma apropriada.

Combatendo a falha

Em caso de falha, mesmo que os erros estejam sendo omitidos do usuário, as coisas não funcionarão como esperado podendo gerar dados errôneos causando ainda mais prejuízo. Se você não tem um ambiente de testes / desenvolvimento (cenário muito comum) certamente precisará ecoar texto na tela para fins de debug (dumps de variáveis, sinalização de checkpoints etc). Precisamos de alguns passos para realizar o combate:

Colocando o serviço em modo de manutenção

Precisamos redirecionar todo o tráfego (exceto o proveniente da equipe de manutenção) para um local com uma mensagem indicando que o serviço está ativo mas encontra-se suspenso para manutenção e será retomado em instantes para minimizar a bounce rate (taxa de rejeição) que é alta no caso dos usuários se depararem diretamente com mensagens de erro. Tal rejeição pode ser crucial em varejistas na perda da venda para o concorrente.

NOTA: Um exemplo é o Submarino que frequentemente presenteia seus usuários com mensagens de erro do Asp.NET.

Para realizamos esta operação quando sob um servidor web Apache precisamos estar com permissão de AllowOverride Options para o diretório raiz da aplicação no seu arquivo de configuração do servidor além de estarmos com o módulo de Url Rewriting mod_rewrite instalado no mesmo (muito comum na maioria dos hostings).

Basta a simples colocação de um arquivo (de preferência html estático) e um .htaccess com o código abaixo na raiz do servidor.

1
2
3
4
5

Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REQUEST_URI} !/em-manutencao.html$
RewriteCond %{REMOTE_HOST} !^200\.200\.200\.200 # IP da equipe de manutenção
RewriteRule $ /em-manutencao.html [R=302,L] # arquivo com a mensagem de manutenção

Podemos ligar e desligar o modo de manutenção apenas modificando a diretiva RewriteEngine on para RewriteEngine off.

Note que além do envio do header 302 (Movido temporariamente) você deve manter meta tags de noindex para não afetar sua indexação no google.

Como debugar?

Bom, aí vai de desenvolvedor para desenvolvedor. A minha técnica consiste em diversas operações.

Análise da mensagem

Começo pela análise forense das informações de erro que me foram passadas que costumam mostrar o problema em 80% dos casos. Ler atentamente a mensagem de erro pode dizer tudo o que você precisa saber.

Olhando para o paciente

Com a experiência conseguimos ver alguns erros só de olhar, assim como um médico experiente. Identifico depois o bloco onde o erro foi localizado e o observo por erros de lógica e falhas aparentes.

Checkpoints

Em algumas vezes (principalmente quando mexendo em códigos de terceiros) preciso colocar checkpoints: prints de mensagens com identificadores para saber quando o programa passa por ele para identificar por quais pontos do código aquela regra está passando.

Dumps

Obter dumps (saídas na tela ou texto) de uma função ou variável ajuda muito em ver como está sendo gerada a saída que pode estar conflitando. Em PHP uso muito o var_dump por me mostrar até o tipo do dado em questão visto que no PHP temos o famoso type juggling (conversão de tipo on-the-fly) e pode gerar conflitos.

E aí, qual a sua boa prática de monitoração e debug?