Definitely, balance is key. My experience is that the more time you are able to spend educating people while things are working, the more latitude you have to troubleshoot while things are down.
I'm pretty sure we've all had to do a quick-n-dirty fix. The problem comes when you have so many of those in place, that are not getting revisited for a more permanent solution, that you end up with a perfect storm scenario. Everyone loses there. *ASB *(My XeeSM Profile) <http://XeeSM.com/AndrewBaker> *Exploiting Technology for Business Advantage...* * * On Thu, Sep 23, 2010 at 7:48 AM, James Rankin <[email protected]> wrote: > I agree, but sometimes you only have time to gather the facts after you've > implemented a fix for the users screaming at you. I personally try to avoid > server reboots to fix, that comes from being judged on server uptime. I'm > not saying "don't gather facts", I'm saying that sometimes, in the support > arena - and especially for small companies and/or teams - implementing or > finding a fix ends up being more urgent than gathering facts, and sometimes > you have to different try things to narrow the issue down (not "at random" > though). But I always believe in understanding why something happened. > Sometimes I will spend inordinate amounts of time trying to understand a > root cause, a lot more than I ever get given to implement a fix - but you > can afford to do that when everyone isn't screaming at you. > > I'm not saying that you shouldn't be systematic, just that sometimes you > have to act quickly and decisively - and occasionally almost instinctively - > using your previous experiences and knowledge as a guide. YMMV, etc. - I'm > not trying to start a flame war here. > > When dealing with users also, I agree, it always pays to check and > double-check what issue they are actually experiencing. A lot gets lost in > translation and through whichever logging system you use. > > > On 23 September 2010 12:15, Mike Hoffman <[email protected]> wrote: > >> The most important of these is gathering the facts. This is not what then >> end user issue seems to be, but what it actually it. Then you can decide to >> either fix, mitigate, or investigate further. >> >> >> >> I know of a number of IT companies where a server reboot is the fix to >> most issues, while I know that most issues are not affected by a reboot, it >> only delays identifying the cause. >> >> >> >> Mike >> >> >> >> *From:* James Rankin [mailto:[email protected]] >> *Sent:* 23 September 2010 11:37 >> >> *To:* NT System Admin Issues >> *Subject:* Re: Kick Ass Sysadmin (was RE: It appears that the Symantec >> Virus has affected PGP already) >> >> >> >> I wasn't saying "random" based on "gut feeling". It was more an inkling >> that something was amiss with that particular function due to experience. >> Maybe I should have been more clear about what I meant by "didn't like the >> look of it". When a system is down and you're the only one assigned to fix >> it, sometimes time is of the essence. In situations where you have time on >> your side, a more structured approach is ideal. Also, if you have an agreed >> SLA, you can be more considered in your approach. Unfortunately that isn't >> always present though. >> >> However I wasn't saying I would just stop services for the hell of it on a >> live system that users were still able to access. That would just be plain >> irresponsible. >> >> On 23 September 2010 11:29, Ken Schaefer <[email protected]> wrote: >> >> Agreed. Making random changes to servers based on “gut feelings” what are >> bad, isn’t my idea of a desirable troubleshooting strategy. >> >> >> >> Gather facts >> >> Isolate Issue >> >> Identify Root Cause >> >> Implement Fix >> >> >> >> Cheers >> >> Ken >> >> >> >> *From:* Andrew S. Baker [mailto:[email protected]] >> *Sent:* Thursday, 23 September 2010 6:13 PM >> >> >> *To:* NT System Admin Issues >> >> *Subject:* Re: Kick Ass Sysadmin (was RE: It appears that the Symantec >> Virus has affected PGP already) >> >> >> >> Another aspect of troubleshooting is the ability to keep track of what are >> actual facts, and what are as-yet-untested-assumptions. >> >> >> >> This includes knowing how to classify information that has been given you >> by the end user. >> >> >> *ASB *(My XeeSM Profile) <http://XeeSM.com/AndrewBaker> >> *Exploiting Technology for Business Advantage...* >> * * >> >> On Thu, Sep 23, 2010 at 2:42 AM, James Rankin <[email protected]> >> wrote: >> >> It's not what you Google, it's how you Google it. Even when interviewing >> now I tend to try and look for people who can work problems out rather than >> people who can simply rhyme off lists of stuff - and I'm always keen on >> people who check the obvious things first. (Think "how would you >> troubleshoot a GPO that's failing to apply" rather than "name the FSMO >> roles".) There's an art to troubleshooting technical issues that's sometimes >> hard to define. It's probably the old "clean minds and scruffy minds" thing. >> Scruffy minds move in unexpected directions and try things that wouldn't >> necessarily make sense. I can remember fixing some random server hang just >> by stopping a service I didn't like the look of. It's only afterwards that >> we realised that particular app was opening loads of ports and generally >> monopolising the system. I didn't really know what I was looking for, until >> I found it. >> >> On 23 September 2010 00:31, Jonathan Link <[email protected]> >> wrote: >> >> Sometimes I wonder if I'm just a good googler... Seems like 90% of my >> issues have been tackled (and documented!) by someone else. >> >> >> >> >> >> On Wed, Sep 22, 2010 at 7:17 PM, David Lum <[email protected]> wrote: >> >> The place with the ad you mean? I don't remember, but here's one in NY >> that is not completely different: >> >> http://www.linkedin.com/jobs?viewJob=&jobId=1007553 >> >> >> >> I do think I am generaly kick-ass, just don't call me an expert at >> anything. My specialty is the near-vertical leanning curve that is needed on >> an occcasional basis. I get stuff like this almost every month: >> >> Q. "Hey Dave, is this possible?" >> >> -or- >> >> "Hey this infrastructure piece is down and the guy who usually manages it >> is out and there's no documentation, can you make it work?" >> >> >> >> In both cases: >> >> A. "No clue..I mean in theory it is somehow possible" <run off> <back in >> 45 minutes> "yeah we can do it, here's a script/tool/some other clever >> capability". >> >> >> >> The answer of course sometimes comes from this list, or Exchange list, or >> Michael B. Smith. >> >> >> >> Ok I'm not kick ass at all, but I know how to contact a LOT of guys who >> are... >> >> >> >> Dave "my expertise is knowing experts and how to contact them" Lum >> ------------------------------ >> >> *From:* Steven M. Caesare [[email protected]] >> *Sent:* Wednesday, September 22, 2010 1:46 PM >> *To:* NT System Admin Issues >> *Subject:* RE: It appears that the Symantec Virus has affected PGP >> already >> >> Hehe.. type of org? >> >> >> >> -sc >> >> >> >> *From:* David Lum [mailto:[email protected]] >> *Sent:* Wednesday, September 22, 2010 2:26 PM >> *To:* NT System Admin Issues >> *Subject:* RE: It appears that the Symantec Virus has affected PGP >> already >> >> >> >> That reminds me, I was looking at job openings and once place had the job >> description on their website “looking for someone who is kick ass at finding >> technical solutions…”. Being an informalish kind of guy, I was tempted to >> apply just based on that kind of verbiage. >> >> >> >> Still like %dayjob% enough to not apply though… >> >> >> >> Dave >> >> >> >> *From:* Steven M. Caesare [mailto:[email protected]] >> *Sent:* Wednesday, September 22, 2010 10:16 AM >> *To:* NT System Admin Issues >> *Subject:* RE: It appears that the Symantec Virus has affected PGP >> already >> >> >> >> I’m using that on my next technical evaluation summary. >> >> >> >> -sc >> >> >> >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
