Around 1999/2000 I worked at Universal Studios in Burbank. Shortly after I started working there in the networking group, a fellow employee asked me to reset a port on the core token ring switch. Being a helpful type, I clicked "disable" on the network management tool for the port and promptly everyone lost connectivity. To everything. A quick walk over to the NOC confirmed that yes, the entire campus was down, as we…
Ask HN: Best “I brought down production” story?
251–260 of 301 posts
Re: Ask HN: Best “I brought down production” story?
#252I was sitting in an escalation-call, called by one of our most important customer and India’s largest ISP. There were 13 of them, 3 of us, and only 1 technical (that’s me). Things were super intense, extremely heated debates were going on, I was fixing a few issues, while answering the questions coming my way, in parallel I was also chatting with my teammates, who were back in the office and were on support calls wit…
Re: Ask HN: Best “I brought down production” story?
#253I was testing backups for a CMS; to test, I had to destroy the test database. I destroyed the production database. While my manager was querying the CMS to do my annual review. Good news is I was already planning on restoring the test database from the production backup, so i had the database up in under 45 minutes (slower than it should have been because Oracle's docs were flat out wrong). A more senior engineer tol…
Re: Ask HN: Best “I brought down production” story?
#254Earlier quoted context omitted.
And why it’s often best to mark a record deleted and then have a reaper remove the records at a later point. But you must make sure all normal queries don’t see deleted items.
That's over engineering. At this point, just rely on PITR. FWIW, postgres does have a "reaper" via vacuum, but not for the purpose of safety. but rather to allow for mvcc.
Re: Ask HN: Best “I brought down production” story?
#255Re: Ask HN: Best “I brought down production” story?
#256From what I understand, it was a long weekend bringing that server up from tape backups.
The funniest thing to me wasn't that it happened. It was who it happened to. The CTO has created (and was granted patents for) multiple utilities still used very frequently in nix environments today.
Re: Ask HN: Best “I brought down production” story?
#257Most of these stories seem to be from 20+ years ago. Do newer sysadmins just not make mistakes anymore? Or is 20 years the timespan that is needed to get over the embarassment? :-)
New sysadmins make mistakes, sure. But they're typically not as critical because recovery processes and correct system architecture insulate the admin from making a mistake with such catastrophic results.
Re: Ask HN: Best “I brought down production” story?
#258Turned out that my coworker had set up the CI process to use a PHP-based zero downtime deployment scheme where each release was deployed into a folder with the commit hash as name and then a symlink was updated to point the web root to this new release folder.
But, critically, he also configured CI to delete old releases at the end of the deployment pipeline - by removing all release folders older than three days. And by re-deploying a commit older than three days, after uploading the code and updating the symlink, the release‘s folder was considered old and deleted at the end of the pipeline, leaving the webserver with an empty directory as web root.
Re: Ask HN: Best “I brought down production” story?
#259Earlier quoted context omitted.
I’m confused by the last part of your post. Sounds like you appreciated that your boss gave you space to learn, and understood that you made an honest mistake, but you’d fire someone who made this mistake if they were working for you? How do you square those two things internally?
It's not good to punish people for making mistakes in the course of their work (especially if that work is meant to be educational) It is good to punish people who give access to production databases to people who shouldn't have it. And the guy learning MySQL should not be given that access. Taking down prod is always a symptom of a systemic failure. The person responsible for the systemic failure should see the cons…
Re: Ask HN: Best “I brought down production” story?
#260Soon, he got a call asking what he did because all of our credit card processing went down.
Shortly after that we got a call from our credit card processor (one of the largest in the country) asking what we did because it was causing a cascading failure in their systems and had taken down a big chunk of online credit cards processing including Apple and Walmarts websites.
We tracked it down to the commit which had accidentally nulled the a username for authenticating with our credit card processor. They had a previously unknown bug that caused a memory fault when the username was null. The processing was queue based so when one machine failed, another would pick it up and try and process it and would fail. This happened until the entire data center fell over.
A few of the lessons learned: 1. Always check the length of user inputs. 2. Build in circuit breakers to prevent cascading failures. 3. Don’t push code without review to production, minutes before leaving.
Everyone involved kept their jobs and we learned a lot of programming lessons that day.