3 ms·

You should not have had that apache problem and not gotten help. Period. That's unacceptable, and I'm sorry. We're working on it

by jnoller 12y ago

snowwrestler 12y ago
Overall I've been a happy Rackspace customer for years, but we've had the same experience with Apache troubleshooting. The support ended at whether Apache was up and running. Beyond that we were told Rackspace considered it to be "application tuning"--which covers all the important settings that are used to manage loads and secure Apache. Luckily a development company we had on contract had a great Linux admin who could help us out. From this perspective Rackspace definitely has not performed a devops role for us. Network administrator? System administrator? Yes, absolutely, and great support for both. But devops is where the application meets the server, and IME Rackspace has stayed away from that. I do see the reason for it--what does Rackspace know about our application? It's not fair to hold them responsible for that. But it created a gap in our professional support. edit: words
- jnoller 12y ago
  I think support has to move up the stack to be remotely relevant to 2014 markets and beyond. This is my goal and why I'm running point on the dev to dev support. But to your point, on the 15th we precisely outlined what is covered on each support level: http://www.rackspace.com/managed-cloud/ http://www.rackspace.com/managed-cloud/ Fundamentally; support has to become systems level, and not single instance level, and that means gaining knowledge and expertise (which we have in house) about the nuances of a given application stack.
  - quicksilver03 12y ago
    I guess it depends on the use case and the sysadmin knowledge of the client. I find that the frontier of responsibility becomes too much blurred when the service provider takes care of anything above the hardware: I personally prefer when the service provider concentrates on power and network stability, and anything else is my responsibility.

You should not have had that apache problem and not gotten help. Period. That's unacceptable, and I'm sorry. We're working on it

by jnoller 12y ago

You should not have had that apache problem and not gotten help. Period. That's unacceptable, and I'm sorry. We're working on it

snowwrestler 12y ago

Overall I've been a happy Rackspace customer for years, but we've had the same experience with Apache troubleshooting. The support ended at whether Apache was up and running. Beyond that we were told Rackspace considered it to be "application tuning"--which covers all the important settings that are used to manage loads and secure Apache. Luckily a development company we had on contract had a great Linux admin who could help us out. From this perspective Rackspace definitely has not performed a devops role for us. Network administrator? System administrator? Yes, absolutely, and great support for both. But devops is where the application meets the server, and IME Rackspace has stayed away from that. I do see the reason for it--what does Rackspace know about our application? It's not fair to hold them responsible for that. But it created a gap in our professional support. edit: words

jnoller 12y ago
I think support has to move up the stack to be remotely relevant to 2014 markets and beyond. This is my goal and why I'm running point on the dev to dev support. But to your point, on the 15th we precisely outlined what is covered on each support level: http://www.rackspace.com/managed-cloud/ http://www.rackspace.com/managed-cloud/ Fundamentally; support has to become systems level, and not single instance level, and that means gaining knowledge and expertise (which we have in house) about the nuances of a given application stack.
- quicksilver03 12y ago
  I guess it depends on the use case and the sysadmin knowledge of the client. I find that the frontier of responsibility becomes too much blurred when the service provider takes care of anything above the hardware: I personally prefer when the service provider concentrates on power and network stability, and anything else is my responsibility.