Depois do lançamento, alguém precisa cuidar da aplicação, dos dados e dos serviços que ela usa. O trabalho depende do que as pessoas precisam: um site de conteúdo e uma aplicação que recebe pedidos de clientes pedem verificações e planos de recuperação diferentes.
Antes de fechar uma manutenção, defina o que precisa de atenção, quem é responsável por cada coisa e que comprovação você vai receber. Estas são as perguntas que eu passaria com você.
Separe hospedagem, manutenção e desenvolvimento novo
A hospedagem oferece a infraestrutura que roda o seu software. Dependendo do serviço, ela também pode cuidar de parte da segurança, dos certificados ou dos backups. Isso não quer dizer que alguém esteja verificando se o pagamento, o login ou as notificações continuam funcionando.
A manutenção cobre o trabalho combinado para manter o produto atual funcionando. O desenvolvimento novo muda o que ele faz. Um plano de suporte pode incluir tempo para os dois, mas um redesign, um novo fluxo de pagamento ou uma integração grande precisa de escopo próprio. Deixe esse limite por escrito antes de o trabalho começar.
Pergunte também qual suporte está incluído depois da entrega inicial, por quanto tempo e o que ele cobre. Saber onde esse suporte termina facilita planejar o trabalho contínuo.
Mantenha as dependências em dia e verifique as atualizações
Aplicações dependem de bibliotecas, frameworks e serviços externos que mudam com o tempo. Correções de segurança e fins de suporte exigem atenção. As atualizações devem ser avaliadas para a sua aplicação e testadas nos fluxos importantes antes de chegar à produção.
O ritmo depende do risco e do produto. Uma falha de segurança urgente que afete você não deveria esperar a janela mensal de atualizações. Combine como esses casos são comunicados e tratados, inclusive o trabalho que ficar fora do plano.
Saiba o que tem backup e como restaurar
O código no repositório é só uma parte da recuperação. Seu produto também pode depender de dados de clientes, arquivos enviados e configurações de serviços. Pergunte o que tem backup, com que frequência, por quanto tempo as cópias são guardadas e quem consegue restaurá-las.
Escolha a frequência dos backups de acordo com quantos dados você poderia se dar ao luxo de perder. Por exemplo, se o último backup bem-sucedido foi à meia-noite e o banco de dados falhar às 17h, restaurar só essa cópia deixaria de fora as mudanças do dia. Um produto que recebe pedidos pode precisar de uma abordagem diferente de um site cujo conteúdo muda toda semana.
Separadamente, combine quanto tempo o produto pode ficar fora do ar durante a restauração. Quantos dados você consegue recuperar e quanto tempo leva para recuperá-los são perguntas diferentes.
Um aviso de backup concluído não prova que a aplicação pode ser restaurada. Teste a recuperação em um ambiente separado adequado e registre os passos. Asorientações do NCSC sobre backup também recomendam verificar se os backups contêm os dados importantes e se você sabe como restaurá-los.
Monitore o que os clientes precisam
Uma verificação de disponibilidade diz que uma página responde. Ela pode não mostrar que os e-mails estão falhando, que uma tarefa em segundo plano parou ou que um cliente não consegue concluir uma compra. Decida quais verificações importam para o produto e para onde as falhas devem ser enviadas.
Disponibilidade da aplicação e dos serviços importantes.
Erros em fluxos críticos, como login, pagamento ou agendamento.
Falhas em tarefas em segundo plano, notificações e integrações de terceiros.
Renovação do domínio, situação do certificado, limites de armazenamento e uso dos serviços.
Todo alerta precisa de um destinatário e de uma resposta combinada. Defina em que horários alguém responde, como um problema urgente é comunicado e quem é acionado se essa pessoa não estiver disponível. Um plano mensal não inclui plantão 24 horas; isso precisa ser combinado explicitamente.
Pergunte o que significa um compromisso de resposta. Reconhecer um problema, começar a investigar e restabelecer o serviço são etapas diferentes. O texto deve deixar claro qual etapa está coberta e o que acontece depois.
Revise desempenho e acessos conforme o produto muda
Os dados crescem, novas funcionalidades chegam e os usuários reais se comportam de forma diferente das contas de teste. Revise páginas lentas e operações caras quando houver sinais de problema. Comece pelo impacto no usuário e depois investigue a causa, em vez de aumentar a infraestrutura por hábito.
Revise os acessos às contas quando pessoas entram ou saem. Mantenha em dia a titularidade e os dados de renovação, e documente onde ficam os serviços importantes. Um produto não deveria depender de uma conta esquecida que ninguém da equipe consegue recuperar.
Peça um plano de manutenção que você entenda
Antes de fechar um trabalho contínuo, faça estas perguntas:
Quais aplicações, serviços e ambientes estão cobertos?
Que verificações e tarefas de rotina vão acontecer de fato?
Quem cuida dos backups, dos testes de restauração, das renovações e das faturas dos serviços?
Qual é o horário de resposta e como eu comunico um problema urgente?
Como é usado o tempo para correções ou melhorias, e o que exige um orçamento à parte?
Que registro do trabalho feito e dos riscos restantes vou receber?
O que acontece com os acessos e a documentação se pararmos de trabalhar juntos?
Peça um registro por escrito do trabalho concluído e dos pontos em aberto. Uma atualização de manutenção poderia dizer, por exemplo:
Concluído: atualizei as dependências da aplicação e verifiquei login, redefinição de senha e o fluxo principal de agendamento em homologação antes da publicação.
Teste de recuperação: restaurei o backup mais recente do banco de dados em um ambiente separado e conferi uma amostra dos registros. Os arquivos enviados ainda não foram incluídos neste teste.
Precisa de decisão: o uso de armazenamento está aumentando. As opções e o impacto esperado estão listados para análise antes de qualquer mudança.
É um exemplo do nível de detalhe a pedir, não a promessa de um cronograma mensal específico. Seu plano deve dizer quais verificações se aplicam ao seu produto e com que frequência acontecem.
Comece pelo produto que você tem
Para uma primeira olhada em um site público, você pode usar meucheck-up do site ou aauditoria do site. Eles podem apontar problemas que valem uma investigação. Não conseguem examinar o código privado da aplicação nem provar que seus backups e os fluxos dos seus clientes funcionam.
Se quiser ajuda contínua,me conte sobre seu produto, os serviços que ele usa e o que você precisa cobrir. Podemos montar um plano de suporte a partir dessas necessidades ou definir primeiro um conjunto específico de melhorias.