Things have evolved a little bit—most of us are using text messages instead of pagers—but the problem still remains.  Most monitoring applications come with the ability to perform amazing numbers of checks against a system.  Most are also set to alert on any warning or error detected.  This is what generates the volume of messages that  flood inboxes.  Hiding in the batch of unread messages are probably five or six really important pieces of information.

When setting up a monitoring solution, I prefer to go with the minimalist approach.  It’s fine for the monitoring application to log and keep records pertaining to the hundreds of items it checks. But when it comes to sending alerts, I only want the critical things I’ve listed.  Start small with things like disk-space checks and key-service checks.  Failures on those checks are the things I, as an administrator, want to be notified about.  Then when some other significant error pops up, stop and look to see if a special check could be done, and then create an alert for it.  Eventually you will have your monitoring application tuned to your liking.  One last step: back up all those customizations you have made.  It takes time customizing a monitoring solution; it would be a shame to start over.

I recommend developing a list of critical requirement that will need your attention.  Interview stakeholders to find out their requirements.  Ask yourself, “What decision will I make or what action will I take with this piece of information?”

Or you could try to monitor everything. Just make sure those alerts are not waking you up to tell you “a service was busy and will try again in a few minutes.”

Every day, users log in and check their email, surf the Internet, print documents, call the help desk, and collaborate on files. All of these activities consume IT resources that have an annual running cost. Very few companies have a good grasp on what their true running costs are. Between employee salaries, amortized assets, and circuit costs, an IT organization can run up a pretty hefty bill just keeping the lights on. A few simple exercises can help an IT organization understand costs and show others where and how the IT budget is being spent.

1. Start with a good user list, by department
2. Begin pulling in information from various sources and tie it back to the user list:
   • Storage usage for email and files
   • Internet usage
   • Support calls to the help desk
   • VPN logs
   • Assets assigned to the user (laptop, desktop, company cell phone, etc.)
3. Derive a reasonable per-unit cost for each of these items
4. Assemble this information into a report

I’ve helped companies through this exercise in the past. While this is not a complete look at operational costs, it does put actual numbers and metrics in place for review. The goal was never to actually do a charge-back to other departments, but to help management visualize two things:

• Quantifiable operational costs
• Which users/departments in the organization were consuming significant amounts of IT resources

So go through this exercise on your own before your next budget planning session. It will go a long way towards helping to justify the planned IT spend.

If you happen to have technology solutions from vendors such as Microsoft, Oracle, and IBM, then you are no doubt struggling with all the new versions pouring out into the market.  Each one touts more features, better manageability, increased productivity, etc.  You find yourself asking, “Do I really need to upgrade?”

The short answer is “yes.”  The long answer is “eventually.”  Don’t get me wrong. Some of the new technology solutions being released have features that an enterprise can take advantage of to reduce costs or to provide a more agile technology-solutions environment to the business.  If an IT organization is in tune with the business and its needs, it may have a reason to adopt the latest, greatest technologies.

However, there are business stakeholders out there who think their current software already does everything needed.  To introduce a new version would require a significant investment in testing or even validation compliance.  So why upgrade?

The answer lies in understanding a vendor’s software life cycle.  Vendors publish a support schedule for each application they provide.  They determine this during the application software’s development.  This support schedule will include the release date, patches, service packs, feature releases, etc.  It will also publish a date when support for that given item will end.  Here is a link to Microsoft’s product index with direct links to support timelines.

It is important to understand the versions of applications you use and the scheduled end date for support.  This information will help you decide if you can accept the risk of running unsupported software or whether it’s time to upgrade, like the Joneses did.

Over the years, many organizations tend to have staff turnover.  There is a very good chance that those names associated with your domain name no longer work for your company.  It’s easy to assume that everything is working correctly and that the company name is protected.  The real danger is the potential risk a competitor or disgruntled employee poses to your organization.

So you see how bad it can get. How do we fix it?  First head over to your favorite WhoIS website (I use domaintools.com).  Type in your company’s domain name and look through the results for the technical, billing, and administrative contacts.  Make sure the information is accurate.  If any of these contacts are still with the organization, they can make all the appropriate updates and eliminate the risk right away (assuming they know their login to the registrar).  If all of the contacts have since moved on, you will need to contact the registrar listed and go through its procedure to reset the names.

While you’re looking at your domain, try searching for .net, .org, and various misspellings of your domain name.  You might be surprised what else is registered.

It sounds silly. The assumption is that if it was backed up, it can be restored. Admins are routinely reviewing backup jobs and looking for errors. That’s a great approach, but it is missing two key ingredients: backing up the right stuff and knowing that it can be restored.

Servers, and the data on them, evolve over time. That means somebody who understands the servers and the data should occasionally review the backup job definitions to ensure that the correct data is being backed up.

The second challenge is being able to restore data from a backup. There are an unbelievable number of challenges here. They could come from the hardware, software, configuration, and even the tapes themselves. Within the last 10 years, we’ve seen gigantic leaps in tape technology. That means that even though you’ve kept old tapes, you may have forgotten to keep an old drive or two handy to use for an actual restore. Software suffers the same problem. That backup from three years ago used a particular version of software that you may no longer have media or keys for.

The last, most critical part is the tapes themselves. Tapes are only rated for a certain number of reads/writes. Tapes are also picky about their environment and can’t withstand extreme temperatures. So while you may feel safe knowing that your tapes are in a fireproof lock box, understand that they will surely melt from the heat of a fire in that room.

You still won’t get a good night’s sleep until you put all of these things to the test and do an actual restore. Try restoring part or all of a server to an alternate location. Bringing back a spreadsheet is progress. Actually proving that you can recover an entire database or an email server is real peace of mind.