4 ms·

> I'm not saying it's a great idea to, y'know, restart a production service based on a card telling you. But on the other hand, have you tried restarting it to

> I'm not saying it's a great idea to, y'know, restart a production service based on a card telling you. But on the other hand, have you tried restarting it to see if that helps? Who among us hasn't tried that, honestly? And being told to do it just to see what happens seems like it has a decent chance of being effective. Yeah, restart the malfunctioning thing and throw away what precious state you had for meaningful debugging of a potentially hard to reproduce problem. If I ever encounter someone guiding their engineering or administration tasks with tarot cards somewhere I have the authority to, they'll be promptly dismissed.

sillysaurusx 7y ago
You can say that about any aspect of debugging: "Yeah, avoid restarting the server and limp along at 10% performance in hopes of debugging the spaghetti code that some intern wrote over the weekend." No one was recommending throwing away state that might help you debug a problem. But I think that there are people who will dislike the idea of controlled randomness regardless of any merits, counterexamples, or evidence in support of its effectiveness. Doctors hated the idea that washing their hands would save lives, because it implied they had been doing their jobs wrong their entire lives.
geofft 7y ago
Restarting the server because the tarot deck said to is certainly a way better reason than the ones I occasionally see in practice - e.g., "because the uptime was unusually high and that seemed suspicious," well did you suspect that it was manually configured and nobody was rebooting it for a reason? That one is an actively bad reason to reboot a server during an outage, at least the tarot deck isn't making decisions contrary to evidence. Also, if you read the article closely, it's not advising you to trust the deck blindly, it's advising you to use it as a way to think about the problem from a new angle. If you're restarting it blindly based on a tarot deck, you're the sort of sysadmin who's ready to restart it blindly based on finding a five-year-old wiki page with a vaguely similar error message on a totally different platform. Should that be a fireable offense? (Maybe! Or at least maybe the company should find you a different role that recognizes that making decisions about production servers is not actually one of your skills.)

sillysaurusx 7y ago

You can say that about any aspect of debugging: "Yeah, avoid restarting the server and limp along at 10% performance in hopes of debugging the spaghetti code that some intern wrote over the weekend." No one was recommending throwing away state that might help you debug a problem. But I think that there are people who will dislike the idea of controlled randomness regardless of any merits, counterexamples, or evidence in support of its effectiveness. Doctors hated the idea that washing their hands would save lives, because it implied they had been doing their jobs wrong their entire lives.

geofft 7y ago

Restarting the server because the tarot deck said to is certainly a way better reason than the ones I occasionally see in practice - e.g., "because the uptime was unusually high and that seemed suspicious," well did you suspect that it was manually configured and nobody was rebooting it for a reason? That one is an actively bad reason to reboot a server during an outage, at least the tarot deck isn't making decisions contrary to evidence. Also, if you read the article closely, it's not advising you to trust the deck blindly, it's advising you to use it as a way to think about the problem from a new angle. If you're restarting it blindly based on a tarot deck, you're the sort of sysadmin who's ready to restart it blindly based on finding a five-year-old wiki page with a vaguely similar error message on a totally different platform. Should that be a fireable offense? (Maybe! Or at least maybe the company should find you a different role that recognizes that making decisions about production servers is not actually one of your skills.)