Quando uma agência gerencia um ou dois sites de clientes, a velocidade com que você responde a um incidente é a métrica mais importante. Se você conhece o ambiente, a solução normalmente está ao seu alcance. Um problema resolvido de forma eficiente pode fortalecer o relacionamento com o cliente. Por isso, responder rapidamente é uma habilidade que você desenvolve e um diferencial do qual pode se orgulhar.
No entanto, o volume de incidentes em um portfólio cresce junto com o próprio portfólio. Com o foco errado, é possível se tornar mais rápido na resolução de problemas sem reduzir a frequência com que eles acontecem. É justamente essa diferença entre a velocidade de resposta e a frequência dos incidentes que revela o verdadeiro custo de uma agência reativa.
Por que responder rapidamente a incidentes é a métrica errada para medir o sucesso
Ambientes com apenas um site conseguem sustentar uma cultura de resolução rápida porque os incidentes são raros e isolados. Conhecer profundamente o ambiente e ter um caminho familiar para a solução faz com que a velocidade de resposta seja uma métrica de desempenho relevante. Essa métrica é conhecida como Tempo Médio de Recuperação ou Reparo (MTTR): o tempo médio necessário para resolver uma falha depois que ela ocorre.
No entanto, à medida que a agência cresce, o Tempo Médio entre Falhas (MTBF) se torna um indicador mais importante da saúde operacional. Enquanto o MTTR mede a velocidade de recuperação, o MTBF mede quanto tempo um sistema permanece em funcionamento antes da próxima falha. Um MTBF alto indica que as falhas são pouco frequentes, enquanto um MTBF baixo significa que sua equipe está em um ciclo quase contínuo de recuperação, independentemente da rapidez com que cada problema é resolvido.
Em resumo, se você otimiza apenas o MTTR, está focando na oficina enquanto o veículo continua quebrando. O MTTR deve indicar a eficiência da recuperação, enquanto o MTBF revela se o ambiente está gerando incidentes desde o início.
O custo de um MTBF baixo em um portfólio em crescimento
Em um portfólio grande, um MTBF baixo por site gera uma fila de suporte que a velocidade de resposta, por si só, não consegue resolver. É comum que diferentes tipos de incidentes ocorram simultaneamente em vários sites:
- Conflitos de atualização de plugins afetam várias instalações ao mesmo tempo quando uma atualização é lançada para um plugin compartilhado usado em todo o portfólio.
- A degradação de desempenho causada por bots pode afetar vários sites de uma vez quando o tráfego automatizado contorna o cache e consome threads PHP sem restrições.
- Erros de implantação introduzem falhas de configuração em ambientes de produção quando os fluxos de trabalho de teste não são seguidos de forma consistente.
- Incidentes na infraestrutura compartilhada de plataformas que não isolam os sites podem se propagar de um site para outros hospedados no mesmo servidor.
Muitos desses problemas geram incidentes que sua equipe não causou e que não consegue evitar dentro desse ambiente. Por isso, ser mais rápido para corrigi-los não é o mesmo que reduzir sua ocorrência.
A Hall é cliente da Kinsta e possui décadas de experiência como agência web. No provedor de hospedagem anterior, períodos recorrentes de indisponibilidade durante picos de tráfego afetavam diretamente a receita de um cliente WooCommerce e consumiam tempo da equipe que deveria estar dedicado ao trabalho para os clientes:
A Kinsta trabalha da mesma forma que nós. Precisamos de excelente desempenho para evitar surpresas e de um ótimo suporte caso algo aconteça. A Kinsta nos permite reduzir as distrações com suporte e aumentar a produtividade.
Os custos que não aparecem nos tickets de incidente
A maioria das agências acompanha o custo direto de um incidente, normalmente as horas gastas por um desenvolvedor ou gerente de contas para diagnosticar e resolver o problema. Esse número é real, mas está longe de mostrar o quadro completo, pois existem custos ocultos:
- Mudança de contexto: um desenvolvedor interrompe um projeto em andamento para resolver um incidente em um site de produção, mas o projeto não para de existir. Pesquisas indicam que são necessários de 15 a 25 minutos para recuperar totalmente o foco após uma interrupção. Isso significa que um único incidente no meio da manhã pode consumir silenciosamente boa parte de um período de trabalho produtivo. Esse custo nunca aparece no chamado do incidente, mas se acumula em cada site do portfólio.
- Confiança do cliente: quando um incidente isolado é tratado e resolvido com transparência, a confiança tende a permanecer sólida. Já um histórico de incidentes recorrentes faz o cliente questionar se o ambiente realmente é confiável. Com o tempo, é a frequência dos incidentes que determina o nível de confiança do cliente.
- Sobrecarga da equipe: uma agência baseada em respostas reativas transforma desenvolvedores seniores na primeira linha permanente de defesa. Como modelo operacional para um portfólio em crescimento, isso aumenta a rotatividade, reduz a capacidade da equipe e agrava ainda mais o problema.
O esforço contínuo de uma equipe para impedir que um portfólio sofra falhas recorrentes costuma ser muito mais um problema da plataforma do que da equipe. A solução é uma infraestrutura que permaneça estável sem exigir intervenção constante. A premiada agência de marketing digital Paramark descreve um cenário semelhante antes de migrar para a Kinsta:
Era necessário um esforço excessivo de administração do sistema para evitar que os sites apresentassem falhas. Alguns dos problemas constantes incluíam o gerenciamento dos recursos do servidor e a limpeza dos arquivos de log. Quando isso não era feito, os sites se tornavam instáveis.
A solução (acompanhar o número de incidentes por site por mês, em vez do tempo de resolução) mostra se o ambiente realmente está melhorando ou se sua equipe apenas está se tornando mais eficiente em administrar um problema contínuo.
Como é prevenir incidentes
A infraestrutura e a plataforma da Kinsta foram desenvolvidas com essa filosofia: reduzir a probabilidade de incidentes, e não apenas o tempo necessário para recuperá-los.
Primeiro, cada site é executado em seu próprio contêiner Linux isolado, com uma pilha de software dedicada. Os recursos não podem atravessar os limites entre contêineres, mesmo entre sites pertencentes à mesma conta da empresa.
Em um portfólio de agência, um incidente em um ambiente individual não afeta o desempenho nem a disponibilidade de qualquer outro site que você gerencia. Em contraste, em plataformas de hospedagem compartilhada, um pico no consumo de recursos de um site pode degradar o desempenho dos demais sites hospedados no mesmo servidor.
Backups automáticos e restauração com um clique
A Kinsta cria backups diários completos de todos os sites e os mantém por, no mínimo, 14 dias. Você pode acessar e restaurar esses backups na tela Backups do MyKinsta, onde também encontra outros dois tipos importantes de backup:
- Os backups gerados pelo sistema são acionados automaticamente antes de operações importantes, como a restauração a partir de um backup existente. Sempre existe um ponto de restauração antes de uma operação ser executada.
- Os backups manuais permitem que você crie até cinco cópias instantâneas adicionais a qualquer momento, às quais você também pode atribuir um nome para identificação.
O botão “Restaurar para” de cada backup permite que você volte a um estado conhecido com poucos cliques. Para agências que usam as Atualizações Automáticas da Kinsta em todo o portfólio, toda atualização agendada é executada com um ponto de restauração gerado pelo sistema já em vigor. O processo agora é “restaurar e investigar”, o que é previsível independentemente do site afetado.
Ambientes de teste e mover seletivamente
Os ambientes de teste da Kinsta oferecem uma cópia separada do site de produção para testar alterações antes que elas cheguem aos clientes. Todo plano da Kinsta inclui um ambiente de teste padrão gratuito por site. Quando uma alteração está pronta para ser implantada, a opção de Mover seletivamente permite controlar exatamente o que será movido para o ambiente de produção.
Para usar o recurso Mover seletivamente, selecione o ambiente de teste no MyKinsta, clique em Mover ambiente e escolha o escopo da implantação (Arquivos ou Banco de dados). Cada escopo também conta com um menu suspenso que permite definir exatamente o que será movido:
A Kinsta cria um backup automático do ambiente de destino antes de cada operação de movimentação. Erros de implantação que chegam aos sites ativos são uma fonte frequente de incidentes. Por isso, um fluxo de trabalho com vários ambientes que utiliza Mover seletivamente e backups automáticos antes da movimentação ajuda a evitar a necessidade de intervenções urgentes em sites ativos.
Proteção contra bots como camada de prevenção de incidentes de desempenho
A Proteção contra bots da Kinsta filtra o tráfego antes que o WordPress processe uma solicitação, reduzindo a carga automatizada no nível da infraestrutura antes que ela afete o desempenho do servidor. Por padrão, a Kinsta bloqueia em toda a plataforma o tráfego classificado como malicioso.
Para configurar a proteção de um site, acesse a tela Proteção contra bots no MyKinsta e clique em Alterar no painel Nível de proteção:
Há quatro níveis de proteção disponíveis, e Bloquear tráfego malicioso é o padrão para todos os sites. Esse nível bloqueia tentativas de DDoS e solicitações originadas de endereços IP associados a fontes de ataque conhecidas. No entanto, você também pode ampliar a proteção para bloquear tráfego automatizado confirmado, aplicar verificações a solicitações classificadas como prováveis bots e a solicitações não classificadas, ou até mesmo aplicar verificações a todo o tráfego não verificado, incluindo visitantes classificados como prováveis humanos.
Ao selecionar vários sites no MyKinsta e clicar em Ações > Alterar proteção contra bots, também é possível aplicar um mesmo nível de proteção a vários sites de uma só vez. A carga gerada por bots pode contornar completamente o cache e consumir threads PHP a cada solicitação, principalmente em sites WooCommerce ou de membros. Ter essa funcionalidade à disposição está se tornando cada vez mais necessário.
Análises como camada de alerta antecipado
O conjunto de análises do MyKinsta oferece visibilidade sobre problemas antes que eles afetem os clientes. Na tela Análises, a aba Desempenho acompanha os tempos de resposta do PHP e o uso de threads PHP ao longo do tempo. Um padrão de aumento no tempo de resposta sem um crescimento correspondente no tráfego humano costuma ser um sinal precoce de carga causada por bots:
Analisar esses gráficos em conjunto leva apenas alguns minutos por site e permite identificar padrões que o monitoramento reativo normalmente não detecta. Por exemplo, ao visualizar o gráfico Visitas em Uso do plano, você pode acompanhar dados como o tráfego humano faturável. Ao compará-lo com o relatório Principais solicitações por visualizações (que inclui todo o tráfego, inclusive solicitações automatizadas), é possível identificar quando a carga gerada por bots está afetando o desempenho do servidor, mesmo que o número de visitas permaneça dentro do esperado.
Mudando o modelo operacional da sua agência para priorizar a prevenção
A transição para um modelo com menos incidentes depende mais da escolha da plataforma e das funcionalidades do que de mudanças na forma de trabalhar.
Por exemplo, sempre que ocorrer um incidente, comece a registrar os fatores específicos de cada site que contribuíram para ele, além das etapas adotadas para resolvê-lo. O objetivo não é documentar por documentar, mas identificar se os incidentes continuam ocorrendo pelos mesmos motivos. Os registros do MyKinsta podem ajudar nesse processo.
Um log que mostra três incidentes no mesmo site causados por conflitos de atualização de plugins aponta para uma falha no fluxo de trabalho de teste. Sem esse registro, o padrão fica invisível e os incidentes continuam.
Uma checklist pré-implantação é uma forma eficiente de transformar as decisões que você já tomou em um processo repetível. Os itens abaixo ajudam a evitar os tipos mais comuns de incidentes evitáveis:
- Teste todas as alterações em um ambiente de teste da Kinsta que represente o ambiente ativo antes de mover as alterações.
- Use a opção de Mover seletivamente para adequar o escopo da implantação ao tipo de alteração.
- Revise as configurações da Proteção contra bots após qualquer implantação que adicione funcionalidades dinâmicas acessíveis ao público, principalmente formulários, fluxos de checkout ou endpoints de login.
- Verifique o gráfico Desempenho em Análises após a implantação para confirmar que os tempos de resposta permanecem dentro do esperado.
Depois que você passar a acompanhar regularmente os incidentes de cada site, poderá apresentar tendências de confiabilidade de forma proativa, em vez de apenas explicar problemas depois que eles acontecem. Um cliente que recebe um relatório trimestral mostrando a redução da frequência de incidentes e um tempo de atividade consistente percebe o serviço de maneira muito diferente de outro que só recebe uma ligação quando ocorre um problema.
Uma infraestrutura orientada à prevenção é o que torna o crescimento de uma agência sustentável
Responder rapidamente a incidentes é uma capacidade essencial para qualquer agência. No entanto, é a infraestrutura que torna os incidentes pouco frequentes que determina se essa capacidade será utilizada constantemente ou apenas ocasionalmente. Em uma agência em crescimento, é essa diferença que define a rentabilidade e a estabilidade da equipe.
O conjunto de ferramentas e a infraestrutura da Kinsta (como o isolamento por contêineres, o sistema de backup automático e a proteção contra bots) lidam com as categorias de incidentes nas quais você gasta mais tempo respondendo. A partir daí, o processo que você implementa, como um registro de incidentes ou uma lista de verificação pré-implantação, torna a redução consistente em todos os sites que você gerencia.
Para agências que gerenciam sites de clientes na Kinsta, o Programa de Agência Parceira da Kinsta oferece suporte dedicado, recursos para co-venda e ferramentas desenvolvidas para facilitar o gerenciamento de WordPress em larga escala.
