Usually when I need to do a DB thing that is too risky to perform as a migration (need to time it for non peak, do some batching, e.g.) we'd make it a script that you can run as a CLI tool, and then run through a deployment tool like Rundeck.
Then, the infra team can look at it like any other code review, and you don't need to set up any special permissions to run it (the deployment tool already has them). Also, the developers who wrote the DB script are the ones who are fully responsible for running it and don't need any other ops involvement. Also, nobody is running bare SQL queries against your production database with the potential for copy/paste errors.
On the pro side of this incident it sounds like there has been time to reflect on why things went wrong and how to address it! I hope you get the time to do so 👍 following up on incidents is almost as important as being able to recover from them.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Usually when I need to do a DB thing that is too risky to perform as a migration (need to time it for non peak, do some batching, e.g.) we'd make it a script that you can run as a CLI tool, and then run through a deployment tool like Rundeck.
Then, the infra team can look at it like any other code review, and you don't need to set up any special permissions to run it (the deployment tool already has them). Also, the developers who wrote the DB script are the ones who are fully responsible for running it and don't need any other ops involvement. Also, nobody is running bare SQL queries against your production database with the potential for copy/paste errors.
On the pro side of this incident it sounds like there has been time to reflect on why things went wrong and how to address it! I hope you get the time to do so 👍 following up on incidents is almost as important as being able to recover from them.