Live data from Hacker News

Devops Horror Stories

statuspage.io

11–20 of 102 posts

Re: Devops Horror Stories

#12
post #3

The customer.io story seems like a great example of why NOT to use budget providers like OVH and Hetzner for mission-critical applications. You get what you pay for.

I've spent nearly 2 hours with sites down at Rackspace, which is certainly not a budget provider, because our hardware firewall crapped out and they "couldn't find" our hardware in the datacenter.

Entirely different problem from a provider that loses one internet connection and their other links can't keep up with traffic, but you can still have major problems even if you're spending thousands of dollars a month compared to hundreds.

Re: Devops Horror Stories

#13

My Devops horror stories, one sentence each: - Somebody deployed new features on a Friday at 5pm. - Fifteen hundred machines running mod_perl. - Supporting Oracle - TWICE. - It turns out your entire infrastructure is dependent on a single 8U Sun Solaris machine from 15 years ago, and nobody knows where it is. - Troubleshooting a bug in a site, view source.... and see SQL in the JS.

Automated tests trigger automated security, all admins are banned, user groups are automatically notified that certain admins are no longer admins.

Re: Devops Horror Stories

#14
Are there any open source load balancing solutions like what Amazon ELB does? Say, install the load balancer on to one or two Amazon VPS, proxy traffic to third party VPS/dedicated servers, Linode, OVH, etc. Wonder how feasible this approach is?

Re: Devops Horror Stories

#15

My Devops horror stories, one sentence each: - Somebody deployed new features on a Friday at 5pm. - Fifteen hundred machines running mod_perl. - Supporting Oracle - TWICE. - It turns out your entire infrastructure is dependent on a single 8U Sun Solaris machine from 15 years ago, and nobody knows where it is. - Troubleshooting a bug in a site, view source.... and see SQL in the JS.

I read the last two lines, threw up under my desk and blacked out.

Re: Devops Horror Stories

#16
post #3

The customer.io story seems like a great example of why NOT to use budget providers like OVH and Hetzner for mission-critical applications. You get what you pay for.

Echoing some of the other comments... the place i worked at was one of the 5 biggest Rackspace customer, and that didn't stop them from regularly cutting traffic or bringing down servers for hours in some case. You might get better uptime overall from reputable providers, but ultimately it's all about distributed application/service architecture.

Re: Devops Horror Stories

#17
"you can't have more than 64,000 objects in a folder in S3 - even though S3 doesn't have folders." Is this for real, or are these stories made up? All documentation I've read about S3 suggests that it does not have any file count limitations. The timeline of Togetherville suggests that this story took place between 2008 and 2010. Did S3 have a limit back then that they lifted?

Re: Devops Horror Stories

#18
post #3

The customer.io story seems like a great example of why NOT to use budget providers like OVH and Hetzner for mission-critical applications. You get what you pay for.

The high-dollar ones aren't necessarily better.

At a previous job we hosted with {HAL} out of Atlanta. A NOC operator there saw/heard/smelled something that indicated to him that he should hit the Big Red Switch. So he did. This removed power to every machine in that part of the DC.

After management confirmed that there was no life-threatening emergency, they started bringing everything back up. Only to have machines start going down again 20 minutes later, as their local UPSes ran out of juice. Someone had to walk around to every cage and recycle them all manually.

Re: Devops Horror Stories

#19
post #16
post #3

The customer.io story seems like a great example of why NOT to use budget providers like OVH and Hetzner for mission-critical applications. You get what you pay for.

Echoing some of the other comments... the place i worked at was one of the 5 biggest Rackspace customer, and that didn't stop them from regularly cutting traffic or bringing down servers for hours in some case. You might get better uptime overall from reputable providers, but ultimately it's all about distributed application/service architecture.

Absolutely. Removing SPOFs and moving to a service oriented architecture has been a major focus for us over the last few months.

Re: Devops Horror Stories

#20
Temporarily mounted an NFS volume to a folder under /tmp.

Forgot about tmpwatch, a default entry in the RHEL cron table to clear out old temp files.

4AM the next morning, recursive deletion on anything wiuth a change time older than n days.

Post reply on HN