10 most foolish mistakes of IT pros

One of the most popular pastimes of IT professionals is complaining about the foolish things users do. We all get a laugh from articles like "10 classic clueless-user stories". But if we're honest, we have to admit that computer novices aren't the only ones who make mistakes. Most network administrators could (but probably won't) tell you about their "most embarrassing moment". That's the one where you discover you accidentally misconfigured the firewall to shut down the boss's Internet connection or that the backup you've been making every day has been copying the wrong files. Oops.

Let's take a look at some of the most common dumb things IT pros do that can mess up their networks — and how you can avoid making such mistakes yourself.

#1: Fail to have a comprehensive backup and disaster recovery plan
It's not that backing up is hard to do. The problem is that it sometimes gets lost in the shuffle, because most network administrators are overloaded already, and backups are something that seem like a waste of time and effort — until you need them.

Of course you back up your organisation's important data. I'm not suggesting that most admins don't have a backup strategy in place. But many of those backup strategies haven't changed in decades. You set up a tape backup to copy certain important files at specified intervals and then forget about it. You don't get around to assessing and updating that backup strategy — or even testing the tapes periodically to make sure your data really is getting backed up — until something forces you to do so (the tape system breaks or, worse, you have a catastrophic data loss that forces you to use those backups).

It's even worse when it comes to fully fledged disaster recovery plans. You may have a written business continuity plan languishing in a drawer somewhere, but is it really up to date? Does it take into account all your current equipment and personnel? Are all critical personnel aware of the plan? (For instance, new people may have been hired into key positions since the time the plan was formulated.) Does the plan cover all important elements, including how to detect the problem as quickly as possible, how to notify affected persons, how to isolate affected systems, and what actions to take to repair the damage and restore productivity?

#2: Ignore warning signs
That UPS has been showing signs of giving up the ghost for weeks. Or the mail server is suddenly having to be rebooted several times per day. Users are complaining that their Web connectivity mysteriously drops for a few minutes and then comes back. But things are still working, sort of, so you put off investigating the problem until the day you come into work and the network is down.

As with our physical health, it pays to heed early warning signs that something is wrong with the network and catch it before it becomes more serious.

#3: Never document changes
When you make changes to the server's configuration settings, it pays to take the time to document them. You'll be glad you did if a physical disaster destroys the machine or the operating system fails and you have to start over from scratch. Circumstances don't even have to be that drastic; what if you just make new changes that don't work the way you expected, and you don't quite remember the old settings?

Sure, it takes a little time, but like backing up, it's worth the effort.

#4: Don't log, so they can save space
One way to save hard disk space is to forego enabling logging or set your log files to overwrite at a small file-size threshold. The problem with this approach is that disk space is relatively cheap, but hours of pulling your hair out when you're trying to troubleshoot a problem without logs to help you discover what happened can be costly, in terms of money and frustration.

Some applications don't have their logs turned on automatically. But if you want to save yourself a lot of grief when something goes wrong, adopt the philosophy of "everything that can be logged should be logged".

#5: Take their time about installing critical updates
The "It'll never happen to me" syndrome has been the downfall of many networks. Yes, updates and patches sometimes break important applications, cause connectivity problems, or even crash the operating system. You should thoroughly test upgrades before you roll them out to prevent such occurrences. But you should do so as quickly as possible and get those updates installed once you've determined that they're safe.

Remember that Nimda and other major virus or worm infestations have done untold damage to systems, even though the patches for them had already been released.

#6: Save time and money by putting off upgrades
Upgrading your operating systems and mission-critical applications can be time consuming and expensive. But putting off upgrades…