Um deploy saiu há uma hora e as taxas de erro vêm subindo desde então. O que você faz?

Faça rollback primeiro e investigue depois, a menos que o deploy tenha incluído uma migração de banco que torne o rollback inseguro. Confirme que a linha do tempo bate com o deploy, veja se os erros estão concentrados nas instâncias da versão nova, e então volte para o artefato anterior ou desvie o tráfego de volta. Assim que a taxa de erro se recuperar, mantenha o build com defeito disponível em um ambiente de staging para conseguir diagnosticar sem os usuários pagando por isso.

O padrão é fazer rollback. Uma hora de erros subindo não é um mistério para resolver ao vivo, é um sangramento para estancar, e o artefato anterior é sabidamente bom. Antes de puxar o gatilho eu faço duas checagens rápidas. Uma, a curva de erro começa mesmo na hora do deploy, ou já vinha subindo antes, porque se começou antes o deploy é coincidência e o rollback desperdiça dez minutos. Duas, este release incluiu migração de schema, porque se incluiu eu preciso saber se o código antigo ainda funciona contra o schema novo. Se a gente fez expandir e contrair direito, funciona, e o rollback é seguro. Se alguém removeu uma coluna, o rollback agora é a opção perigosa e eu parto para uma correção para frente ou uma feature flag. Assim que os erros se recuperam eu mantenho o build ruim implantado em staging para a gente reproduzir sem envolver clientes. Depois a pergunta que eu levantaria é por que um canário não pegou isso, porque uma hora de impacto significa que o rollout não estava observando a taxa de erro contra uma linha de base.