> In the future we can connect these logs to slack so you can get slack alerts when a developer accidentally DROPs a table.
What can you do about getting me a slack notice BEFORE a developer accidentally drops a table? ;)
What can you do about getting me a slack notice BEFORE a developer accidentally drops a table? ;)
The Monarch: "Don't worry! If he hangs you I'll have him beheaded fifteen minutes later."
Triboulet: "Well, would it be possible to behead him 15 minutes before?
All our db operations like this go through our regular code review process for the db maintainers team, and instead of dropping tables, we just rename them with a prefix "to_be_dropped" as a scream test, then actually drop them a month later or so.
Recovery is much simpler for renaming than dropping.
We all have a few of these. My first one was a jenkins node with a "mv $WORKSPACE/ $WORKSPACE/bin" and no "set -u" :) Or accidentially wiping all SSH keys from a server due to a typo in the config management. That was fun.
But it's a good test for the mistake culture of the team and the resilience of their infrastructure. We had juniors nuke systems and no one but us and the monitoring noticed besides maybe a short hickup during a leader failover. That's pretty cool - and also a good horror story in a few words: "When you start ansible, and 3 minutes later on-call says 'Hi.' on slack".
As to the config, this at least was pretty common for Web.*.config files in the .Net space in the mid 00s. I was never a fan of it, and even with the newer options in the space, prefer simpler environment variables these days.
Ideally, you don't want developer(s) to have access to destruct data especially things like DROP. Now, a lot of small businesses may not have the resource to have separate DBAs etc but the rule still applies.
This is more a control problem than a code problem. Having said that, you could write triggers to stop DELETE or DROPs from happening if you cannot control the access.
All the same, I don't touch prod servers, and especially don't touch client prod servers.
I was studying SQL Server at the time, so Kendra Little, Brent Ozar, that whole crew were a good starting point.
Once you learn the basics of the DCL for your database, a lot of the stuff just becomes a natural extension, and almost always you're just talking about the official documentation.
Usually you have a server and a database level identity, and manipulating those usually break out the connection vs object level permissions.
Once you understand the maps of those and grouping users, you can do stuff like detect a user did a bad thing and add them to a group of users who are default denied from the database, insert a row in a table, and roll back their changes. A logon trigger that does rude things to people's sessions, or certainty that your developers can view some parts of some data without exposing your secrets.
Maybe it could send a Slack message which you (some someone else) would need to react with (I think this site malforms that white checkmark unicode character though..) before it continues, or times out after a while with an error!