Language Selection

English French German Italian Portuguese Spanish

Five common mistakes that Linux IT managers make

Filed under
OSS

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

Full Article.

More in Tux Machines

Tanglu 3.0 Alpha Out Now Based on Debian 8 Jessie, Offers GNOME 3.16 and KDE Plasma 5

Matthias Klumpp announced today, April 18, the immediate availability for download and testing of the first Alpha version of the upcoming Tanglu 3 Linux operating system. Read more

EXT4 In Linux 4.1 Adds File-System Level Encryption

The EXT4 file-system updates for the Linux 4.1 kernel have been sent in and it features the file-system-level encryption support. Earlier this month we wrote about the newly-published patches for EXT4 encryption support coming out of Google and intended to land in the next major release of Android. Those patches for file-system-level encryption will now be landing upstream with the Linux 4.1 kernel update. Besides this native encryption support for EXT4, the rest of the updates for this merge window pull request equate to mainly fixes. More details via the pull request itself. Read more

Manjaro Linux 0.8.13 Pre1 Released for Testing with KDE Plasma 5.2.2 and Xfce 4.12

The Manjaro development team announced that the first Preview release of the upcoming Manjaro Linux 0.8.13 operating system is now available for download in Xfce and KDE Live CD flavors. Read more