Uma mudança do seu time derruba a produção. Me conte o que acontece em seguida.

Restaure o serviço primeiro, investigue depois. Coloque em prática a mitigação segura mais rápida, normalmente um rollback a menos que voltar atrás seja mais arriscado, mantenha um comandante de incidente claro e um responsável separado pela comunicação, e proteja o engenheiro envolvido de ter que consertar e explicar ao mesmo tempo. Depois, conduza uma revisão sem culpados que encontre as fragilidades do sistema (falta de guardrails, caminho de deploy inseguro, testes fracos) em vez da pessoa.

Mitigação primeiro. A única pergunta nos primeiros cinco minutos é qual é o caminho seguro mais rápido de volta a um estado funcional, e normalmente isso é um rollback, e não uma correção inspirada feita sob pressão. Garanto que alguém seja comandante do incidente e outra pessoa cuide da comunicação, porque os piores incidentes que já vi foram aqueles em que quem digitava também respondia ao executivo que ficava entrando na call. Se o engenheiro que entregou a mudança é a melhor pessoa para consertar, ele conserta, e eu tiro todas as outras conversas do colo dele. Uma vez estável, a revisão é sobre o sistema. Quando isso aconteceu no meu time, uma mudança de configuração pulou o staging porque o caminho de deploy permitia. O engenheiro foi o último dominó, não a causa. As ações foram um guardrail naquele caminho, um teste para aquela falha específica e alertas melhores, cada uma com nome e data. E eu digo em voz alta na revisão que a mudança era razoável dada a informação que ele tinha, porque o time inteiro está olhando como aquela pessoa é tratada.