I'm tempted to ask how the production data differed from the data in the test environment on which they ran these potentially destructive tools first, but I'm a

I'm tempted to ask how the production data differed from the data in the test environment on which they ran these potentially destructive tools first, but I'm afraid that would be interpreted as rhetorical sarcasm. Seriously though, how on earth do you even get the idea to initiate such an operation without a) testing it against realistic data, and b) doing a dry run against the live data first before you decide to pull the trigger and start terminating applications? And to top it all off, there was no roll back scenario and the restore process was buggy, which means it wasn't tested properly either. I'm all for "move fast and break things", but this is a complete joke. The organizational chaos that leads talented engineers to operate this way must be a nightmare.