I’ll admit, I hesitated a bit before writing this post. The whole point of this linuxblog.io and linuxcommunity.io forum is to bring together like-minded Linux users and professionals so we can troubleshoot, share ideas, and learn from one another. For a moment I thought, is it really productive for me to publish something that shows… continue reading.
So I was thinking there’s an easy way to remember this. I know it’s corny, lol, but:
GLAD - Gather, Look, Analyze, Document
G – Gather clues and define the problem L – Look at system status and logs A – Analyze findings, form a hypothesis D – Document the fix after verifying
That’s easy to remember and has a positive connotation. Will edit the article and add to the end.
I like the mnemonic GLAD you should patent it. Before it ends up on someone else’s training video on UDEMY. And it’s not as corny as some of the other ones I’ve seen/ heard for the last 17 years of Technical Support… none of which I remember from those trainings.
Thanks! I’ll take that as a compliment. No trademark though. Let’s consider it fully open-source. I’d honestly be flattered if it ever made it that far!
Funny story, many years ago, I told Cloudflare about an image optimization process for their image-serving and how they could implement it, which they then launched a few months later. As a thanks, they sent me a t-shirt and a signed card that read:
“Hayden, thank you for your image optimization suggestion. Millions of web surfers now get a faster web experience because of it!”
My only wish was they offered that Polish service free, because it really helps make the internet lighter and faster. And I guess keeping my original suggestion online for reminiscing’s sake.
Nice article however, not trying to be funny or anything, isn’t that pretty standard IT support practice?
I’m retired but ex-IT and I recall we did stuff pretty much like that for the systems (mainly Windows but some Linux too) we looked after and when I do stuff now, I follow something similar (perhaps not quite as rigorously) and try hard to document any solutions I come up with.
Yeah, that’s fair. It’s pretty much standard IT practice. The article just breaks it down in a simpler way for “new Linux users,” as it states. Many who are just starting out don’t yet have a structured troubleshooting process or know where to look at each stage.
Most experienced folks already follow something similar out of habit.
