For an obvious typo in a prod config (something like wrong addr:port), sure. But if I think I have an 90% chance of fixing a failure I just introduced (in code

For an obvious typo in a prod config (something like wrong addr:port), sure. But if I think I have an 90% chance of fixing a failure I just introduced (in code I just demonstrated not fully understanding), that's a 10% risk of prolonging a production outage for nothing more than style points. Roll the damn thing back and then fix it with a clear head. That should be a well-practiced reflex. If it ends up being one bad deploy, one rollback, and one healthy deploy all back-to-back, that's totally fine. In a blue/green world, failing back prod to the cluster with the known-good code should be reflexive. After that maybe you can be lax about whether to roll back or fix forward on the unhealthy cluster (or maybe not, if you only have n=2 clusters).