Archive for the ‘Best practices’ Category

Scripting (part 3) – which language?

Sunday, March 15th, 2009

In an ideal world, your whole IT department will make a policy decision to pick one scripting language and stick to it. Sadly this does mean that the advocates of other languages will “lose” the argument and be prevented from using their most comfortable language.

However, the benefits of a consistent policy should be obvious – people can switch between teams without a huge learning curve; there is more incentive to invest time in learning the language properly; no one creates a legacy of code only they can support; and it’s less likely that someone ends up maintaining code in a language they hardly understand. It also means you can concentrate the support effort: creating templates, building shared modules, etc.

Scripting (part 1) – it’s important

Saturday, March 14th, 2009

This is not a particular practice, more a whole approach.
Adopt, learn and use a scripting language. JFDI.

1) Decide on a scripting language for your IT dept
2) Learn it
3) Use it

Reuse of monitoring data

Friday, March 13th, 2009

As hinted at in various other articles, there is a huge overlap between the data needed for monitoring, usage tracking & capacity planning, and (cost) charging.  Assuming you set up the comprehensive set of probes required for Total Monitoring, you will be getting a heavy stream of information about response times to test requests, and also a set of platform data – CPU percentage busy, how much disk space is used, etc.

Although it is probably not required (or practical) to save every measurement in that stream, a summarised set of data (averaged or summed over longer periods) is exactly what is needed for tracking and forecasting usage trends, and for calculating a usage-based bill to send to your customers.


Usage tracking

Monday, March 9th, 2009

This is about tracking the usage of individual resources in your environment – whether a CPU is busy, the space used on a disk or RAM, and so on.

Tracking the usage of a particular resource is useful in several respects; it allows you to:

  • predict a point at which the resource will be exhausted, e.g. no more free licenses
  • allocate proportional costs to each business department
  • check expectations against reality – it may be a warning sign if you see heavy usage of a resource that should be lightly used, or is not marked as critical
  • consolidate, where you see underutilised resources.

My belief is that we tend not to track these things closely enough, but that improving should be easy.


Configuration Management – Part 1

Friday, March 6th, 2009

Here’s where it all starts… I believe configuration management to be the most important and crucial practice for running an efficient and safe IT infrastructure. Sadly, one that is very rarely done properly, if at all.

In development, a comprehensive test suite is claimed to be the basis for all the other Agile practices – only if every aspect of the code is tested can you be confident to go in and make changes. Similarly, a comprehensive CMDB is the beginning of Agile SysAdmin. It:

  • allows you to see the pattern of dependencies in your environment
  • gives an instant guide to the cascading impact of an outage
  • prevents outages caused by conflicting services and other mistakes
  • enables “change with confidence”
  • enables systematic coverage (e.g. backups and monitoring should do enough, but not too much)
  • allows easy queries for “what’s out there?” (what is non-standard, what is at an old level, etc)