Revisado · Recursos do Hosmio
Antes de começar
Reúna o inventário de aplicações, o contato do cliente, o operador atual e um possível substituto. Tenha um local para armazenar o briefing que permaneça acessível se o VPS estiver indisponível. Referencie o armazenamento protegido de segredos; não cole credenciais no documento.
01
Defina primeiro o limite do serviço.
Liste o trabalho necessário para manter a aplicação útil: revisões de acesso, atualizações do sistema operacional, mudanças de runtime, manutenção de banco de dados, backups, monitoramento e renovação de domínio. Separe isso do trabalho que o fornecedor de infraestrutura realmente concordou em executar. Um botão de reset, uma seleção opcional de backup ou um contato de suporte não estabelece por si só um contrato de serviço gerenciado.
Anote tudo cujo responsável ainda é desconhecido. Para Hosmio, intervenções finais do fornecedor e escopo de suporte exigem confirmação. Planejar suas próprias responsabilidades agora evita presumir que um incidente de aplicação será diagnosticado automaticamente pelo host.
02
Atribua ações e autoridade de decisão.
| Atividade | Função responsável | Gatilho e verificação |
|---|---|---|
| Lançamento do aplicativo | Operador do aplicativo; backup nomeado | Mudança aprovada; testar login e uma tarefa representativa |
| Manutenção disruptiva | Aprovador de mudanças do cliente | Janela de impacto conhecida; go/no-go explícito |
| Exercício de recuperação | Operador de recuperação | Ensaio agendado; registros e anexos restaurados verificados |
| Comunicação de incidentes | Proprietário atual do incidente | Mudança com impacto material; transferência com carimbo de data/hora |
| Exceção de pagamento | Contato de compras | Divergência ou resultado incerto; retenha detalhes factuais do pagamento |
Uma função só é útil quando a equipe atribuiu a ela uma pessoa acessível. Registre a atribuição atual em suas notas operacionais privadas. Uma pessoa pode acumular várias funções, mas a distinção evita que um técnico aprove acidentalmente um risco de negócio em nome do cliente.
03
Combine a mudança e seu ponto de parada.
Para uma atualização planejada, registre por que ela é necessária, o que muda, os serviços afetados e como retornar a um estado conhecido. Especifique quem pode aprovar a interrupção e quem pode interromper o trabalho se as verificações falharem. Use uma janela acordada com fuso horário explícito; “fora do horário” é ambíguo para uma equipe internacional.
Antes de iniciar o trabalho, verifique o acesso, a cópia de recuperação e a versão ou configuração exata que está sendo alterada. Defina um horário até o qual a equipe deve passar nas verificações de aceitação ou acionar seu plano de recuperação. Não descreva a reversão como instantânea, a menos que um ensaio real sustente essa expectativa.
04
Escolha sinais que levem a uma ação.
Comece pela tarefa do usuário: uma conta representativa consegue fazer login, ler o registro esperado e concluir uma operação segura? Adicione verificações de recursos e dependências que ajudem a explicar falhas. Um aplicativo pode responder a uma solicitação básica de saúde enquanto uma fila em segundo plano não faz mais progresso.
Escolha os limites de escalonamento com base nas necessidades e observações do projeto. Um portal ilustrativo pode tratar duas verificações falhas de tarefas agendadas como um sinal para investigação, em vez de uma definição universal de indisponibilidade. Registre como a verificação é executada e o que o operador deve inspecionar em seguida. Alertar sem um destinatário responsável não cria cobertura.
05
Prepare a substituição antes de um incidente.
Faça com que o operador substituto encontre o inventário, o procedimento de acesso protegido, o registro de mudança mais recente e as notas de recuperação sem orientação. Eles devem ser capazes de distinguir um fato conhecido de uma hipótese não testada. Dê a eles autoridade apropriada à função, em vez de compartilhar uma conta pessoal apenas para facilitar o acesso.
Mantenha os carimbos de data/hora de incidentes inequívocos. A RFC 3339 define representações de carimbo de data/hora com UTC ou um deslocamento explícito; um registro como 2026-09-12T14:00:00Z evita um valor de relógio local inexplicado. RFC 3339: carimbos de data/hora da Internet ↗ Siga o guia de transferência de fuso horário para uma transferência mais completa da propriedade atual.
06
Ensaiar o briefing e registrar lacunas.
Use um exercício de mesa antes de confiar no documento. Apresente um trabalho em segundo plano com falha hipotética enquanto o operador principal está indisponível. Peça ao substituto para identificar o impacto, as ações permitidas, a rota de aprovação e a próxima atualização. Não faça alterações reais no serviço apenas para demonstrar que o resumo existe.
Registre permissões ausentes, propriedade pouco clara e documentos inacessíveis como ações com responsáveis. Revise o resumo quando a equipe, as integrações, as metas de recuperação ou os fornecedores mudarem. A conclusão significa que outra pessoa autorizada pode seguir o processo e explicar seus limites; não significa que uma equipe de suporte contínuo tenha sido estabelecida.
Continue com um ensaio de saída do provedor e os modelo de resumo de incidentes. Mantenha o resumo operacional conciso o suficiente para usar durante um problema e vincule a procedimentos mais detalhados quando necessário.