I have viewed some profiles of SF users who have high reputations. One thing I have noticed that they have asked only a few questions. Some Profile links are given below:
Is it something like this that:
You missed me off the list! 2155 answers, 28 questions :)
Anyway the answer is that they, and I, are smart, experienced and resourceful.
We've done this a long time, building instincts that help with fault-finding and know where to go to get answers quickly.
We actually probably run into MORE problems than more junior guys, we're usually doing more so there's more to go wrong - but we can more quickly spot and solve problems than less experienced guys.
Basically there's no substitute for experience.
I do my own research - when confronted with an issue I break out scientific method, being structured really does help in problem solving. It hasn't always been possible/practical to go and ask the internet so I learned early on to read manuals and other sources.
It helps me that I am naturally inquisitive - I generally don't want to just fix something I want to know why it happened and how to prevent it from happening again.
I, the rest of the people on your list and others have years of experience. This really does help - we can use our experience to avoid the basic mistakes as well as to identify and correct more difficult problems early on.
On the occasions I have wanted to as a question on SF I have found it already answered - the 'Questions with a similar titles' that you get presented with really is a good resource - one that I wish more people would avail themselves of rather than posting duplicate questions.
Often the process of writing a question out forces you to think critically about your problem and break it down into its component pieces.
During this process, the problem and its solution reveal themselves using magic (often related to unicorns), making the question pointless to post.
There are in fact many problem solving techniques that use this tactic, and it's happened to me many times (although I think I have also asked almost 100 questions over the last 3 years)
My comment on Mark's answer shows my agreement with him. I've done exactly what he suggests many, many time.
Additionally, the problems I end up stumped on are rarely good SF questions. They tend to be full of nuance, and I've found that the act of explaining the nuance brings it smack into the domain of Too Localized. Or worse, need a fair amount of back-and-forth debate between experts to really come to a decision, and that's also a bad SF question.
In general, my search engine skills are hot enough that I can:
A large percentage of ServerFault questions can be answered by application of the above, and I have the rep I do because I applied the above skills to other people's problems. It's good practice for myself, allows me to learn new things along the way, and practice writing up solutions.
One final area that does impact what I'm able to share is who I'm working for. At my previous job, a publicly-funded University in the USA subject to Freedom of Information Act style disclosure rules, I felt zero qualms about posting details about what exactly I was facing and what I'd tried. We had no secret-sauce to protect, so may as well put it all out there anyway.
Now that I'm working for a private entity that actually does have secret-sauce to protect, I've found that I simply can't ask for help on some topics because they touch a bit too closely to the secret recipe. As a result I'm purposely posting more basic stuff that I could find for myself (specifically bullet points two and three up there) but want to get the SF opinion on instead.
What the others said, plus
I poke at the problem until it goes away, using my vast knowledge of Strange Shit I've seen in this business since I started.
If the problem doesn't go away, or I'm still in the dark at the end of my poking I ask a young person. Or Google.
The above steps have always solved the problem - If they don't I'll post a question here in the hopes that someone else has seen this new-to-me variety of Strange Shit before and has the answer written on the back of an old cocktail napkin somewhere in their bottom desk drawer.
While the above sounds humorous it's honestly the process I follow. My poking is more scientific than blindly running commands (usually), and always begins with what Rob Moir suggested: Define the problem fully.
Often this points you at the solution, but if not it at least gives you an idea of where you should look.
Armed with the definition of the problem I ask myself the Key Question of System Administration: What Changed?, and if I can identify an intentional change I put whatever changed back the way it was to see if the problem goes away.
After that it's down to the scientific method like Iain mentioned, methodically working through and investigating the issue, isolating probable causes, identifying possible solutions, and testing them.
Ideally you would do all your testing in a dev environment (and sometimes I've gotten lucky), but often what broke is production and the right answer is the "quick fix" -- Reboot the production box and make it work again. This is always followed up by making the problem happen in the development environment and learning Why it broke, and trying to make sure it won't happen again.
Asking a young person is surprisingly not on anyone else's list, nor is the more general "Bother your colleagues".
In my experience when all the senior admins are stumped sometimes explaining the problem to a junior admin (or someone outside the tech team) is helpful - It makes you think about the problem, and sometimes they have ideas that you haven't thought of.
Server Fault is also a great resource for learning. I've seen solutions here for problems I haven't yet had, but can anticipate happening soon. When I do have those problems I know the answer already, because I read it somewhere on the internet.
Have to agree with the answers here, as experienced IT people, we probably face more problems and we certainly face more complex problems than junior IT staff.
My own troubleshooting process goes like this:
Define the problem fully - I've solved numerous problems just by taking the time to properly describe them, which causes the troublesome area to become apparent - this corresponds to both Mark's point about writing a question out and Chopper's point about experience - helping me to spot the problem when I see it.
Fairly detailed knowledge (experience again) of how network or server components work, which allows you to quickly pinpoint the areas most likely to be problematic. or at least eliminate areas that are least likely to be involved. This greatly improves your chances of spotting and fixing an issue.
Fairly detailed knowledge of tools and techniques for isolating and diagnosing problems - not only does this make it easier to solve an issue yourself, it should improve the questions you need to ask (and make it obvious if you need to escalate an issue formally with a particular vendor instead of asking around places like this).
I ask a lot of questions compared to most high-rep users. They tend to be good questions, complex questions, or questions that will be helpful to other users (e.g. Google results). It's a balancing act. Many times, I know I can feel my way through an issue, and there's value in doing that. Other times, it makes sense to know when to get help (and where to get it). It's also realizing that I don't know everything. Working alone, it helps to have another set of eyes look at a problem... But more often than not, time is money. I have an incentive to move on to other assignments/projects.
They probably face more problems, but they also have more experience, so they can solve problems quicker.
Also a recent trend on serverfault is that lot's of people ask questions that can easily be solved by reading docs,manuals or just using google.
At least for me, the problems that I face have to do with very high end specialized equipment and the only person that can resolve the issue is the vendor - they are all "too localized". I have given some thought to posting some self-answerable questions about other more generic issues I've come across, and how to "resolve" them, but I just haven't gotten around to it yet.
OK, I don't have that much reputation compared to many users here, but I'm getting there!
I tend to reply the stuff I already know from my past experience. After spending way too many hours with servers over the 10+ years, I've learnt quite a lot.
My method for learning new stuff: read the docs, try it out, most importantly, try to break and then fix it. :-) Torturing software in weird ways is a great way to learn new things and occasionally spot genuine bugs. If everything else fails (or I'm in rush), I Google.
I see an SF question as a last resort of sorts. If an answer exists, then I'll likely find it through search. When I get resort to SF its because 1) search hasn't helped, or 2) the problem is significantly complex that it doesn't lend itself well to search.
As @sysadmin1138 mentioned, the act of trying to write a good question often leads one to additional ideas.
In my experience, not just with this site but with technical support in general (especially vendor tech support), the questions I typically have are exceptionally difficult, and few if any people have answers. That's because these problems have already been filtered through me. :)
As a result, SF has a strong tendency towards not being very helpful, unfortunately. Except when my question has already been asked and answered by someone else, of course.
