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

Defina o serviço de que os utilizadores dependem

O deployment disponibiliza o software. A operação mantém-no útil à medida que os utilizadores, as dependências, o tráfego e os requisitos mudam. Um gerador de código não elimina este trabalho contínuo.

Num export de clientes fictício, os utilizadores precisam de mais do que uma página acessível. Precisam dos registos permitidos, no formato necessário e dentro de um tempo aceitável. Precisam também de que o serviço impeça o acesso aos dados de outra organização.

Identifique o responsável antes do lançamento. Registe quem responde fora do horário normal de trabalho, se isso fizer parte do compromisso do serviço. Um fornecedor pode executar parte do trabalho, mas a organização continua a precisar de uma via clara para as decisões e a 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 durante um período indicado. Escolha a meta com base nas necessidades dos utilizadores e na capacidade operacional.

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

Para o export, defina o que conta como um pedido elegível bem-sucedido. Separe as recusas esperadas das falhas do sistema. Documente as exclusões para que uma métrica não possa melhorar apenas por ocultar pedidos difíceis.

Evite registar exports completos nos logs para melhorar a visibilidade. Recolha apenas a informação necessária para diagnosticar o problema e proteja o acesso a essa informação.

Prepare a resposta a incidentes

Decida quem coordena, quem investiga e quem comunica. Numa equipa pequena, estas funções podem ser combinadas, mas as responsabilidades têm de continuar claras. Mantenha um registo de observações e ações.

As orientações da Google sobre resposta a incidentes destacam a coordenação e a comunicação, além da mitigação técnica. Uma correção tecnicamente adequada pode ainda deixar os utilizadores sem informação ou levar vários intervenientes a fazer alterações incompatíveis. Resposta a incidentes.

Um agente pode resumir logs ou comparar hipóteses dentro dos limites de dados aprovados. Não deve receber autoridade irrestrita em produção só porque o incidente é urgente. Use uma via de escalamento definida para acessos excecionais.

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 registos apagados ou mensagens já enviadas. Registe o tempo e a informação necessários para repor 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 de terminar o orçamento de lançamento.

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