Assuma a responsabilidade pelo serviço após o deployment

Defina o serviço de que os usuários dependem

O deployment disponibiliza o software. A operação o mantém útil conforme usuários, dependências, tráfego e requisitos mudam. Um gerador de código não elimina esse trabalho contínuo.

Para uma exportação fictícia de clientes, os usuários precisam de mais que uma página acessível. Precisam dos registros permitidos no formato exigido e em tempo aceitável. Também precisam que o serviço impeça o acesso a dados de outra organização.

Defina o responsável antes do release. Registre quem responde fora do horário normal se isso fizer parte do compromisso do serviço. Um fornecedor pode realizar parte do trabalho, mas a organização ainda precisa de um caminho claro para decisões e comunicação.

Escolha sinais que apoiem a ação

Um indicador de nível de serviço, ou SLI, mede uma propriedade definida do comportamento do serviço. Um objetivo de nível de serviço, ou SLO, estabelece uma meta para esse indicador em um período declarado. Escolha a meta com base nas necessidades dos usuários e na capacidade operacional.

As orientações de SRE do Google explicam essa abordagem e o uso de um orçamento de erro nas decisões de confiabilidade. Não copie a meta de outro serviço sem verificar seu significado. Orientações sobre SLOs, exemplo de política de orçamento de erro.

Para a exportação, defina o que conta como uma requisição elegível bem-sucedida. Separe recusas esperadas de falhas do sistema. Documente exclusões para que uma métrica não melhore apenas por esconder requisições difíceis.

Evite registrar exportações completas em logs para melhorar a visibilidade. Colete o mínimo de informações necessário para diagnosticar o problema e proteja o acesso a elas.

Prepare a resposta a incidentes

Decida quem coordena, quem investiga e quem comunica. Esses papéis podem ser combinados em uma equipe pequena, mas as responsabilidades precisam continuar claras. Mantenha um registro das observações e ações.

As orientações do Google sobre resposta a incidentes enfatizam coordenação e comunicação junto com a mitigação técnica. Uma correção tecnicamente correta ainda pode deixar usuários sem informação ou várias pessoas executando alterações conflitantes. Resposta a incidentes.

Um agente pode resumir logs ou comparar hipóteses dentro dos limites aprovados de dados. Não deve ganhar autoridade irrestrita de produção porque o incidente é urgente. Use um caminho definido de escalonamento para acesso excepcional.

Exercite a recuperação e financie a manutenção

Teste o procedimento de recuperação com dados fictícios representativos. Identifique o que um rollback de código não consegue desfazer, incluindo registros excluídos ou mensagens já enviadas. Registre o tempo e as informações necessários para restaurar o serviço.

Atribua o trabalho contínuo: atualizações de dependências, revisões de acesso, renovação de certificados quando aplicável, alterações de capacidade e correções de documentação. Um serviço sem capacidade de manutenção acumula obrigações depois que o orçamento de lançamento termina.

Após um incidente, escolha melhorias que tratem as causas observadas. Relacione-as à implementação e à verificação. Isso fecha o ciclo de vida: as evidências operacionais mudam o que a equipe especifica e constrói a seguir.