Administração e Manutenção de Sites em Brasília

O que quebra num site que ninguém abre há um ano

Site raramente para de funcionar de uma vez. Ele vai perdendo pedaço em silêncio, e o dono costuma descobrir pela via mais cara: um cliente avisando que mandou mensagem pelo formulário e nunca teve resposta. Nada disso aparece como aviso no painel: aparece primeiro para quem estava a um passo de virar cliente.

• Plugin desatualizado: cada plugin é código de terceiro rodando dentro do seu site. Quando o autor corrige uma falha, a mudança fica visível no código publicado e costuma ser registrada em bases públicas de vulnerabilidades; quem não aplica a correção fica com uma brecha que outras pessoas já podem conhecer.
• Formulário que parou de enviar: uma atualização no plugin de contato, uma troca no e-mail de destino ou um endurecimento da política antispam do provedor faz a mensagem sumir sem nenhum erro na tela. O visitante acredita que enviou; a empresa acredita que ninguém procurou.
• Versão de PHP fora de suporte: o servidor avança a linguagem, o tema antigo não acompanha, e páginas inteiras passam a devolver erro em vez de conteúdo.
• Tema ou plugin abandonado pelo autor: deixa de receber correção, e a única saída passa a ser substituir a peça, o que fica mais trabalhoso quanto mais tempo se espera.
• Backup inexistente: a ausência só é descoberta no dia em que ele seria a única saída.
• Conteúdo que envelheceu: telefone que não atende mais, endereço antigo, profissional que saiu e continua na página da equipe.

Manutenção contínua e chamado avulso não resolvem o mesmo problema

Suporte sob demanda é reativo: você aciona quando alguma coisa já quebrou, e o diagnóstico começa do zero, porque quem vai atender não acompanhou o que mudou no site nos últimos meses. Boa parte do tempo gasto num chamado avulso é reconstruir contexto: descobrir qual plugin foi instalado, por quem, e o que já tinha dado problema antes.

A administração web funciona no sentido inverso. Quem aplica a atualização é quem conhece a lista de plugins daquele site, sabe qual deles é sensível, testa antes de publicar e tem a cópia da véspera à mão se o teste der errado. É um serviço recorrente por natureza: o que ele acumula é histórico. O site da Denise Ramos, por exemplo, foi criado pela Criattus e desde então segue sob a administração da mesma equipe: é esse histórico que faz uma atualização de rotina ser rotina, e não uma aposta.

Backup só vale pelo dia em que você precisa restaurar

Muito site tem uma cópia guardada dentro da própria conta onde ele roda, e isso passa uma sensação de segurança que não se confirma na hora do aperto. O ponto do backup é sobreviver ao evento que derruba o original, e uma exclusão acidental, uma invasão que cifra arquivos ou uma falha de disco levam junto tudo o que estiver no mesmo lugar, inclusive a cópia.

Três detalhes separam um backup útil de um arquivo que existe só no contrato. Ele precisa ficar fora do servidor do site; precisa guardar mais de uma data, porque um site comprometido pode passar dias assim sem ninguém notar e a cópia de ontem já viria contaminada; e precisa incluir o banco de dados, não só os arquivos, porque é no banco que estão as páginas, os textos, os pedidos da loja e os registros dos formulários. Some-se a isso o único teste que importa: restauração que nunca foi feita não é um plano, é uma suposição.

Antes de consertar, é preciso saber em que camada quebrou

"O site caiu" descreve o sintoma, não a causa. Dentro da aplicação, os motivos mais comuns são os de baixo, e nenhum deles se resolve pelo painel por quem não sabe o que mudou por último.

Quando a origem está abaixo da aplicação: servidor, domínio, DNS ou certificado, o assunto é outro e está tratado na página de hospedagem de sites.

• Erro fatal logo depois de uma atualização, quando duas peças param de conversar entre si e a tela em branco aparece no lugar do site.
• Conflito entre plugins que fazem a mesma coisa, instalados em momentos diferentes por pessoas diferentes.
• Banco de dados indisponível ou corrompido: a estrutura carrega, o conteúdo não.
• Consumo anormal de recursos, seja por ataque, seja por um plugin mal comportado gerando processo sem parar.
• Código injetado: o site abre normalmente para quem está logado e redireciona o visitante que chega pela busca.
• Cache servindo uma versão antiga da página, o que faz a correção já aplicada parecer que não funcionou.

Atualizar não é apertar o botão de atualizar

O painel do WordPress oferece um botão que aplica tudo de uma vez, e é justamente por isso que tanta gente descobre o estrago depois. Atualização de plataforma, tema e plugin muda código em produção, e o efeito colateral quase nunca aparece na página inicial: aparece no formulário, no checkout, na página que depende de um bloco específico ou na área que só o cliente logado enxerga.

A ordem que usamos é a inversa da conveniência: cópia antes, atualização em conjuntos pequenos em vez de tudo de uma vez, verificação das páginas que dependem daquela peça e só então a publicação, com o ponto de retorno pronto caso o resultado saia diferente do esperado. Quando o que muda é conteúdo, e não código, a conferência é outra: em segmento regulado, quem decide o que pode entrar na página é a norma do conselho profissional, assunto tratado a fundo nas páginas de marketing para advogados, marketing para clínicas e médicos e marketing para dentistas.

Atualização automática: o que pode rodar sozinho e o que espera o teste

A página de segurança do WordPress diz com todas as letras que só a versão mais recente da plataforma tem suporte oficial. A equipe de segurança leva correções críticas para versões antigas como cortesia, e elas chegam pelas atualizações automáticas. Na prática, site parado numa versão antiga depende de uma gentileza para continuar protegido, e qualquer mudança nessa política o deixa de fora.

Desde a versão 5.5, o próprio painel permite ligar a atualização automática plugin por plugin e tema por tema. É uma ferramenta boa e perigosa na mesma medida. Faz sentido para correção de segurança do núcleo e para plugin simples, que não mexe em nada que o visitante usa para falar com a empresa. Não faz sentido para as peças de que o negócio depende: formulário, checkout, agendamento, integração com sistema. Essas esperam a cópia, o teste e a conferência das páginas que dependem delas.

O critério é o custo da falha, e não a frequência da atualização. Plugin que quebra um detalhe visual pode atualizar sozinho; plugin que, ao quebrar, faz a loja parar de vender sem aviso precisa de alguém olhando antes e depois.

• Atualização de segurança do núcleo do WordPress: automática
• Plugin sem impacto em contato, venda ou integração: automática, com conferência periódica
• Formulário, checkout, pagamento, frete e agendamento: manual, depois de cópia e teste
• Tema personalizado e plugin com código ajustado para o site: manual, com revisão do que a atualização sobrescreve
• Versão principal nova do WordPress: manual, depois de confirmar compatibilidade de tema e plugins

O primeiro mês de acompanhamento é diagnóstico, não rotina

Site que chega de outro fornecedor não entra em rotina no primeiro dia. Antes disso é preciso saber o que existe: versão da plataforma, lista de plugins e por que cada um está lá, situação real da cópia de segurança, o que foi personalizado direto no código do tema (personalização que uma atualização desavisada apaga) e o que está parado há tempo suficiente para exigir cuidado na hora de mexer.

Esse levantamento é também o que dimensiona o acompanhamento. Um site institucional com formulário de contato ocupa menos a equipe por mês do que um com área restrita, agendamento ou integração com sistema de terceiro, em que cada atualização precisa ser validada ponta a ponta. Loja virtual pede mais ainda: módulo de pagamento e de frete são mantidos por terceiros, atualizam no ritmo deles e exigem teste de compra a cada mudança. Pesa igualmente o quanto o conteúdo se mexe, quem trata o site como catálogo estável demanda menos do que quem publica material novo com frequência. Por isso olhamos o site antes de falar em escopo.

Plugin: como escolher, e quando o melhor é não instalar

Cada plugin instalado é código de outra pessoa rodando dentro do site, com o próprio calendário de atualização e o próprio histórico de falhas. A pergunta certa antes de instalar não é se ele resolve o problema, e sim se o problema justifica mais uma peça para manter por anos.

O diretório oficial de plugins do WordPress mostra, na página de cada um, os sinais que ajudam a decidir: a data da última atualização, o número de instalações ativas, a versão do WordPress com que ele foi testado e o fórum de suporte, onde dá para ver se o autor responde. Plugin sem atualização há muito tempo, testado só com versões antigas e com perguntas sem resposta no fórum é candidato a virar problema. E plugin fechado no diretório deixa de estar disponível para download e não recebe atualização enquanto estiver fechado; ele pode ser reaberto se o autor corrigir o problema, mas vale planejar a substituição.

O erro mais comum nos sites que chegam para manutenção não é o plugin ruim, é o plugin repetido: dois de cache, dois de formulário, três de SEO instalados em épocas diferentes por pessoas diferentes, cada um fazendo parte do trabalho do outro. Enxugar essa lista costuma deixar o site mais rápido e mais fácil de atualizar, sem perder nenhuma função.

• Última atualização recente e compatibilidade declarada com a versão atual do WordPress
• Autor que responde no fórum de suporte
• Uma função por plugin, sem sobreposição com outro já instalado
• Nenhum plugin inativo esquecido na lista: plugin desativado ainda é código no servidor
• Preferência por recurso nativo do WordPress quando ele já resolve

Quem pode fazer o quê no painel: os níveis de usuário do WordPress

O WordPress já vem com níveis de acesso definidos, e usá-los é a medida de segurança mais barata que existe. O administrador tem acesso a todas as funções do site; o editor publica e gerencia posts, inclusive de outros usuários; o autor publica e gerencia os próprios posts; o colaborador escreve os próprios posts, mas não publica; e o assinante só gerencia o próprio perfil.

Na maioria das empresas, quem mexe no conteúdo do dia a dia não precisa ser administrador. A estagiária que publica no blog trabalha bem como autora; a pessoa que revisa tudo antes de sair, como editora. Administrador fica restrito a quem realmente instala, atualiza e configura, porque é a conta que, se for invadida, entrega o site inteiro.

Duas práticas completam o cuidado. Cada pessoa com o próprio login, sem senha de administrador compartilhada por e-mail ou mensagem, para que o registro do que foi alterado diga quem alterou. E revisão da lista de usuários sempre que alguém sai da empresa ou um fornecedor termina o trabalho, porque conta esquecida de ex-funcionário ou de agência antiga é porta aberta que ninguém está vigiando.

O que a manutenção não cobre, e por que isso precisa estar escrito

Contrato de manutenção que não diz o que fica de fora gera atrito garantido. Não porque alguém age de má-fé, mas porque "manutenção" significa coisas diferentes para quem vende e para quem compra, e a diferença só aparece no primeiro pedido.

Manutenção cobre o que mantém o site funcionando como ele foi entregue: atualização de sistema e de componentes, correção de falha, monitoramento, backup, ajuste de conteúdo existente e suporte quando algo quebra. É trabalho recorrente e previsível, e por isso cabe num valor mensal.

O que não cabe é desenvolvimento novo. Página inédita, funcionalidade que não existia, integração com sistema de terceiro, redesenho de seção e migração de plataforma são projeto, com escopo e prazo próprios. Tratar isso como manutenção significa uma de duas coisas: ou o valor mensal embute uma gordura que todo mundo paga e poucos usam, ou o fornecedor entrega menos do que deveria em algum outro lugar.

Também ficam de fora a verba de anúncio, a licença de imagem, a licença de componente pago e o custo de domínio, que são repasses e não serviço. Misturar repasse com honorário impede saber quanto está sendo pago por trabalho.

A fronteira honesta se escreve em uma linha: manutenção mantém o que existe, projeto cria o que não existe. Quando um pedido cai na segunda categoria, o caminho é dizer isso na hora e orçar, e não incluir em silêncio para descontar depois em outro lugar.

Se o problema já aconteceu e você chegou aqui em emergência, a ordem das primeiras horas está em meu site foi invadido, o que fazer. Esta página trata do regime que muda o cenário do próximo evento, que é coisa diferente.

Manutenção é o serviço em que a proximidade pesa menos e a disponibilidade pesa mais: site que cai não espera reunião. O acompanhamento é feito a distância, para clientes de Águas Claras, Taguatinga, do Plano Piloto e de fora do Distrito Federal, sem diferença de tratamento. O que o endereço em Águas Claras muda é a possibilidade de sentar junto quando o problema não é técnico e sim de decisão, do tipo o que entra e o que sai do site no próximo trimestre.