Slashdot Mirror

However, it's pretty much always a support service. Therefore you should expect that you'll end up on call. Personally I don't like that part, but can't deny the extra pay is nice.

It's also a field where experience is what really really matters. Which means it can be tough to break into. Certifications and degrees are nice, but it's my '5 years in the industry' which opens doors, not the other bits of paper.

However as a starting point in 'building your career', I will suggest you look at:

• ITIL - IT infrastructure library. It's something that put me off initally, as it look a bit too much like icky-yuck processes and procedures. However, I've run into a _lot_ of companies that are starting to 'buy in' to the model. That wouldn't convince me, though. What did, is it's actually a fairly good way of 'doing IT'. Not the only way by any means, but one worth looking at, if only because then you have a basis for comparison.
• SAGE Systems Administrators guild, a subdivision of Usenix.
• BCS British Computer Society
• The Practice of System and Network Administration (Paperback) - A personal favourite, this is a brilliant book, because it covers the _theory_ of systems admin.

As far as I can tell, your bits of paper serve to help you secure an interview. But the field's .... well sufficiently complicated and convoluted that your ability to learn, research and innovate are far more important. As is your ability to show you can do this.

If you have an IT staff of 10, you can get away with this. If you have an organization that has over 400 IT employees; a non-IT it staff that is close to 50,000 people; are running nearly 900 applications on everything from Windows to Mainframe to AS/400 OS to seven different flavors of UNIX; and have are managing about 500TB of storage; then you can't get away with what you are describing for very long.

From your series of posts, it sounds like you are a smaller organization. If I am wrong, and you happend to have a couple of hundred IT employees, you need to look into ITIL. Otherwise, it is only a matter of time before you run into serious problems with your production environment.

The UK-based ITIL initiative describes in gory detail a collection of best practices that IT can follow to provide better service to their customers. They can do as much or as little of the whole program as they want, and it can even be driven from the outside by the user community if absolutely necessary. Obviously, if there's cooperation it works better, but if they roll their eyes at "another total quality management initiative" (which it's not) you can still use the terminology and methods and eventually drag them into it.

http://en.wikipedia.org/wiki/Information_Technolog y_Infrastructure_Library
http://www.itil.co.uk/

In fact this Sunday I'll be off to Melbourne for another course of a week, the second admin course for HPOV Performance Insight. Without the training I can't imaigine being able to deploy and support this quite complex (and not overly intuitive) product, it would in fact be negligent to have me do so.

I'd reccommend taking your need for education to your managemnt quite firmly, and if they won't budge look elsewhere - not just because of this particular issue, but because such behaviour is indicative of a lack of management vision IMO. If they can't outlay some cash now to train for the future it doesn't sound like they'll have much of a future to worry about - at least not a very interesting high growth one.

If you're creating an IS dept. It's time you start looking into ITIL See here for more info: http://www.itil.co.uk/ From what you describe of your situatiom, you're the only guy running the show. You need to start establishing a framework within your org to start managing IS/IT in an organized manner. ITIL provides a framework for which to do so. Trust me, you'll find this useful. Whether your company likes it or not, it has reached a critical point where it depends on it's IT infrastructure more than it thinks it does. You've gone beyond being the only admin running the show. The smart thing is to get their buy in on treating IS/IT like an asset and managing it correctly.

My 2c :)

One must also consider the possibility that the folks doing the coding and the quality assurance (SQA) may not be the original authors of the specific branch involved, and therefore did not have the proper experience level required to do the research and make the judgement calls. With the rumored turnover Microsoft has seen lately, I wonder if this is not a possibility?

More and more of the post-development activities (break/fix, SQA, implementation/packaging, etc.) for software are happening in little bubbles, somewhat removed from the core competency group that created the original code. We even see this touted as the right way to do things from sources that are considered to experts in the process + workflow arena (well, some folks consider them experts, anyway). When this becomes the standard operating procedure, any company runs the risk of bad patches to any kind of software: you can not limit the culpability to Microsoft.

ITIL stands for IT Infrastructure Library, and defines an IT Service Management structure that can be applied to IT Operations as an effective framework. There are two main areas within ITIL, Service Delivery and Service Support.

Service Delivery includes:

Service Level Management

Capacity Management

Availability Management

Financial Management

IT Service Continuity

Service Support includes:

Service Desk

Incident Management

Problem Management

Change Management

Release Management

Configuration Management (arguablely also part of Service Delivery)

If you apply an ITIL methodology throught IT Operations you will find that the IT operational projects are run more smoothly in a well controlled environment. You can google for a lot more information on ITIL, but I recommend certification, at least to Foundation level for anyone seriously interested in implementation. See also BS15000, the British Standard associated with ITIL which is expected to become an ISO (International Standard) in the future.

-- Pete.

Or ITIL (Information Technology Infrastructure Library) -- on which COBIT was partly based. It's a best practice framework for how to manage your IT shop.

Quoth the poster:

...a user base floating around 1M... over 20 duplicate bugs for a single incident... email to 5+ accounts, multiple forum posts, bugtracker, etc.

There are two aspects to user 'bug reports': improving product quality (fixing bugs) and user support (helping the user with a problem). Organizations doing much of the latter distinguish 'incidents' from defects (bugs). An incident is a user report of a problem; other users might have experienced the same problem, but no matter, the incident is recorded and a user-support person provides assistance. The user is not responsible for recording bugs at all; the user-support person (or someone else) does that. Thereby, all bug reports are produced by internal staff, rather than customers, so you can enforce good bug reporting. Also, the organization is set up so the user has only one point of contact, the user-support department, so duplicate incident reports are eliminated too.

If this is new to you, you might be interested in the ITIL Guidelines

• Change control?
• Incident management?
• Problem management?
• Change window?
• Service level negotiations?
• Capacity management?
• Security management?

As long as all the SysAdmins seem to be making it up as they go along, we will continue to be marginalized and geek-ified by management. Try on for size:

• ITIL (IT Infrastructure Library)
• More ITIL
• IT Service Management Forum (the U.K. headquarters)
• CMM (Capability Maturity Model) Technical Engineering Practices
• The Open Group's Technical Architecture Framework.

It's not that the SysAdmin necessarily has to manage these processes - though in a small shop no one else will - but he/she/it needs at least to be able to talk the language and understand the processes that the IT Manager has set up. And if you are managing the shop, then this is your job. You must know this stuff as a matter of professional responsibility and "keeping up" in your field.

A 20 min. presentation to the other managers on Best Practices and Processes in IT Management will gain you a lot of credibility and help lift you out of the geek gutter. There are decades worth of lessons that have been learned the hard way and documented into these processes. When you can demonstrate to management that you are drawing on a substantial body of knowledge that is geared towards improving service and reducing total cost of ownership, you will gain their respect (assuming that you care about their respect).

Beyond this, I want to emphasize an excellent point that Sanders makes in the article. The SysAdmin job is one that is invisible if you're doing it right. A good day at work is a boring day. Excitement is a sign that something has gone wrong. You should structure your environment to be as boring and reliable as possible.

Too many SysAdmins live off the adrenaline rush of fixing a broken server while everyone else in the organization sits on their thumbs waiting. That's costly for the organization, but ironically is the easy way out for the SysAdmin - you don't need to be disciplined or structure your time or do any planning or thinking, just jump from crisis to crisis. It's much more challenging to turn it into a boring desk job where most of your work is pushing paper and the machines pretty much take care of themselves. But guess which option is better for the organization's mission?

Once you do get to that Nirvana state of boring life, you can strategize how to produce some measurables so you can blow your department's horn at the monthly managers meeting. Because if you do your job well, with the result that your work is invisible, they'll cut your funding unless you keep in their face on a regular basis.

.nosig