Earlier quoted context omitted.
And yet, the net result is the same; right-click, clear table, or ./clearTable.sh. Both are human actions, and both are fallible. What if some prankster edited clearTable.sh to do the users table instead of the raids table? What if he did it himself to test something?
Forget a prankster! What happens if the full RAID array fails that holds the database? No backups: dead company.
How I Fired Myself
281–290 of 424 posts
Re: How I Fired Myself
#282Re: How I Fired Myself
#283Re: How I Fired Myself
#284Re: How I Fired Myself
#285Earlier quoted context omitted.
The problem isn't who has the keys , it's how they're used . I don't care as much if a junior developer has the prod password; I care more about building an engineering and ops team that understands that dicking around with the prod database isn't okay . Sysops and DBAs are fallible too--I've seen a lot of old school shops that relied heavily on manual migration and configuration. Automate, test, isolate and expect f…
That's why you don't give out the keys to people that know how to act responsible.
Giving keys to irresponsible people seems irresponsible ;)
Re: How I Fired Myself
#286Earlier quoted context omitted.
Bingo. As I like to emphasize, people don't care about backups---this company certainly didn't---they care about restores . And almost no one is willing to put up the money to do compete testing of restore paths, let along statistically making sure they continue to work.
My favourite way to test restores is to do them frequently to the dev server from the production backups - this keeps the dev data set up to date, and works as a handy test of the restore mechanism. Of course if you have huge amounts of data or files on production this becomes more difficult, but not impossible, to manage.
Re: How I Fired Myself
#287Earlier quoted context omitted.
This sounds so unreal that I am having doubts about the veracity of the story and would defer any judgement before hearing from the "other side".
Having just helped a friend who was miffed at the idea of spending money on a new UPS for >$5k worth of networking equipment: do not be surprised. Penny-wise pound-foolish.
Re: How I Fired Myself
#288More than anything else, this describes an appalling failure at every level of the company's technical infrastructure to ensure even a basic degree of engineering rigor and fault tolerance. It's noble of the author to quit, but it's not his fault. I cannot believe they would have the gall to point the blame at a junior developer. You should expect humans to fail: humans are fallible. That's why you automate.
When the people screw up, there's no processes to hold them back, they can really, really screw it up.
Once you hit millions in revenue it's probably wise to put a couple of fall back processes in place, reliability becomes as important as agility.
Re: How I Fired Myself
#289Earlier quoted context omitted.
More than that, it's telling that the company threw him under the bus when it happened. I've been through major fuckups before, and in all cases the team presents a united front - the company fucked up, not an individual. Which is, if you think about it, true, given that the series of events leading up to the disaster (the lack of a testing environment, working with prod databases, lack of safeties in the tools used…
I've been through major fuckups before, and in all cases the team presents a united front - the company fucked up, not an individual You should consider yourself very lucky. Or very savvy at knowing which companies to avoid.
Re: How I Fired Myself
#290When I was 18 I took out half my towns power for 30 minutes with a bad scada command. It was my summer job before college and I went from cleaning the warehouse to programming the main SCADA control system in a couple weeks. Alarms went off, people came running in freaking out, trucks started rolling out to survey the damage, hospitals started calling about people on life support and how the backup generators were no…