4 ms·

If you want to find the developer who will drop your table by accident, ask your devs to raise their hands if they ever dropped a table by accident. Those that

• tetha 3y ago
  Aye. A similar rite of passage: Any admin who hasn't nuked a server yet isn't working for long yet, or at their effective limit and is too careful. 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".
• tracker1 3y ago
  Nope... but did check in the prod settings for the "local" config while working on a production bug close to the end of my contract. A couple weeks later another dev had dropped a production table as he'd used the local/dev connection string. Fortunately, every service request was logged and re-playable... so the DB was restored from backup, and every service request re-ran in order. Lost about a day of productivity for everyone using the app/service. 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.