IT Manager's Journal
Tracking the Evolution of IT
http://www.itmanagersjournal.com/

Title    Five common mistakes that Linux IT managers make
Date    2005.09.23 8:01
By    Joe 'Zonker' Brockmeier
Topic    Systems Management
Story URL    http://www.itmanagersjournal.com/article.pl?sid=05/09/21/141224

After seeing the same mistakes repeated by different IT managers over the years, I've noticed a pattern of common errors. Here are the five common mistakes, along with tips for avoiding them.

Mistake #1: Reactive, not proactive

The number one mistake made by IT managers of all stripes is to carry out their duties by reacting to problems only as they come up, rather than looking ahead to potential problems and having a solution in place ahead of time. This trait isn't unique to IT managers, but it can be a fatal flaw when the head of an IT department fails to take a proactive approach.

For example, proactive IT managers make sure they have disaster plans in place rather than trying to implement a disaster plan on the fly. A good IT manager will have plans to deal with hardware failure, natural disaster, compromised systems, and any other problem that might crop up. If you spend most of your time putting out fires, you're probably not being proactive enough -- or you're still cleaning up the previous manager's messes.

A proactive manager plans for the future in terms of capacity planning, upgrades, and support. What happens when an application outgrows a single server, for example? How difficult will it be to deploy on multiple servers, and is this even possible? When deploying open source software, you'll want to assess the health of the community that supports it. If it's a project without a long history and an active developer community, it may not be the best choice. Projects like Samba and Apache are safe bets, while a project that made its SourceForge debut three weeks ago is risky business.

Many organizations experience costly growing pains because the IT infrastructure wasn't planned with an eye to the future. You may only need to support five or 50 users now, but what about three to five years down the road? If that seems like it's too far off to worry about, you've already failed.

When it comes to hardware, be picky and choose servers and equipment that will have a long life span and support. Be cautious about choosing non-standard hardware with binary-only kernel modules. The vendor may provide support and upgrades now, but what happens if it chooses to stop supporting a piece of hardware after a few years? That leaves you with the choice of ditching hardware or not being able to upgrade the kernel.

Mistake #2: Failing to emphasize documentation and training

Prior to the invention of writing, people had to rely on oral tradition to pass on knowledge from one person to another. Of course, this is an extremely fragile way to store information, which is why writing systems were invented. However, if anthropologists examined the average IT department from a distance, they'd be forced to conclude that the average IT staff still relies on oral tradition to pass on policies and important information.

In my experience, most IT departments have very poor practices for disseminating information between members of the IT department and the users who depend on them. Vital information, like passwords and setup information for home-grown applications, often lives with the systems administrators rather than being stored in a central and permanent location.

Other information may be passed via email or IM from admin to admin, but never quite makes it into a usable form of documentation that new hires can assimilate. Organization-specific information, such as passwords for servers and services, installation instructions and guidelines, firewall rules -- basically, anything that's not obvious, standard, or found in existing documentation -- should be documented in an easy-to-find location.

Instead, new IT staff usually go through a slow process of information-gathering to get up to speed in their new environment. This process is expensive, wasteful, and frustrating for the new staff and the experienced staff members who have to answer a steady stream of questions.

Even worse, vital information is lost altogether when experienced staff move on without writing down what they've done or passing it on to new staff members. Remaining staff members then have to burn valuable time re-learning what the exiting admin knew.

There will always be an adjustment period for new staff members, but it's possible to reduce the learning curve by providing appropriate training and documentation.

IT managers should set up a central repository for documentation and policies, and make documentation a job requirement for systems administrators and programmers.

Mistake #3: Failing to assess strengths and weaknesses

Many Linux IT managers make mistakes when deciding whether to keep a project in-house or farm the job out to a contractor or hosting service. This problem is especially challenging for open-source-oriented IT managers because they share a strong penchant for do-it-yourself projects. Open source is a great equalizer -- a hobbyist can make use of the same open source software that large corporations use to power their businesses. That doesn't mean that the hobbyist will be as adept at setting it up, though. To be effective, manager needs to know the strengths and weaknesses of their teams.

Many managers try to cut costs by keeping everything in-house, when a careful study might reveal it will take longer and cost more to do so. A manager, for instance, may decide it's time to replace Windows NT print and file services with Samba for a few hundred users. That's a great idea, but it might be a mistake to attempt this using in-house staff if no one has experience with Samba. Samba isn't that difficult to manage, and I'd trust a competent admin to set up and maintain Samba for a small organization with no experience with it, but a larger and more complex deployment might call for a contractor who has a great deal of experience with Samba.

Hosting a Web site using Apache, PHP, and an open source content management system isn't terribly difficult, but it may be a waste of time and money to do it yourself if your organization's Web site isn't part of your core business. It may be cheaper and easier to host the site with a professional hosting company rather than trying to maintain a Web server on your own.

It's doubly important to get an experienced person on the job if the project involves replacing an existing system with a new system. If a new service is delayed by a week or more, it's usually not the end of the world, or the IT manager's job. On the other hand, if an existing service is swapped out with a new system, it needs to work flawlessly right out of the gate.

On the other hand, it's silly to use contractors for long-term services, or in place of full-time staff. If you have the expertise and manpower to do it in-house, by all means cut the contractor off. Over the long haul it may be cheaper to hire someone full-time than to keep paying the going rate for contractors.

Mistake #4: Too much, too quickly

While I applaud IT managers who decide to deploy Linux and open source applications in their organizations, I encourage them to move cautiously when replacing existing systems. Moving too much, or doing it too quickly, can cause a lot of problems and sour the organization's management on future open source projects.

Change in IT is almost always going to be disruptive. Upgrades, new software, or anything that operates differently from the current environment users are familiar with is likely to cause productivity to take a hit -- even if it's better than what came before. If the new systems have less functionality, or they're harder to use, there's no point in rolling them out, though I've seen companies do it on several occasions.

Don't replace working systems with new systems that have reduced functionality just to replace proprietary software with open source. For example, I think it's a smart move for businesses to roll out Firefox to replace Internet Explorer as the company standard browser, but not if it breaks compatibility with sites users need to do their jobs.

OpenOffice.org is a suitable office suite for most users, but I wouldn't force it on users who use complex spreadsheets with functions that work only in Microsoft Excel. You want to ditch the company's intranet portal that uses Microsoft SharePoint for a Linux box running Mambo? Make sure that users have all the features in Mambo that they were using before in SharePoint.

Note that a new piece of software may not need the exact feature set as what came before -- your users might not have used all the features in the old application. If possible, do test deployments and have extensive discussions with users about what they need before rolling out any replacements. There's no way to make every user happy, so don't try. What is possible, however, is to keep most users happy (or at least at their current level of unhappiness) while rolling out new systems.

Mistake #5: Security as a secondary priority

A common fallacy is that Linux and open source are secure by default. While Linux and open source are a solid foundation for a secure environment, if your servers and applications aren't properly hardened, you might as well plan on being rooted.

Too many IT managers fail to give security the attention it deserves. They may place emphasis on installing security patches and having strict firewall rules, but fail to provide a comprehensive security policy for their organization.

From the front door to the firewall, security must be a pervasive element in an organization's IT architecture. It does little good to implement a strong firewall when untrusted users are granted access to servers behind that firewall through a company VPN. It does little good to install patches for every package on a server when the homegrown code that drives the organization's Web site is insecure. Requiring 10-character secure passwords that change every eight weeks for user accounts is a waste of effort if anyone can saunter into the server room and sit down at a machine where the root user still has an active session.

It's wise to call in reinforcements when necessary. If you and the rest of your IT staff lack solid security credentials, then don't be shy about calling in a consultant to provide assistance in securing your organization's IT infrastructure.

Have you noticed other common mistakes by Linux IT managers? Please tell us about them in a comment below.


© Copyright 2005 - IT Manager's Journal, All Rights Reserved

printed from IT Manager's Journal, Five common mistakes that Linux IT managers make on 2005-10-03 11:34:51

Hosted by www.Geocities.ws

1