Agile SysAdmin

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.
(more…)

In other articles, I discuss why scripting is important, and which languages to use. This one is largely an exhortation to learn it properly – just as you are wasting your time doing things manually that could be scripted, you are wasting your time if you do not make the most of this vital tool.
(more…)

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
(more…)

In a conversation with a couple of former colleagues the other day, the topic of certification came up.  We had a range of views – from “is there really any point?” to “they open up opportunities you’d never hear about otherwise”.

Over the years I’ve moved from a slightly snobbish “certifications are nice enough, but don’t mean much” to thinking they can be a useful aid to learning and recruitment – though I still treat their presence on a CV with a large pinch of salt.
(more…)

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.

(more…)

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.

(more…)

Most of the challenges and issues that a system administrator faces today are not really new, but an extension of past trends. In a competitive marketplace, the demands to “do more with less” will never abate. While new technologies can help in some ways, they often bring their own new variations on old problems.

Some clear themes are:

• Ever more moving parts – the number of components in the environment
• Changing legal and regulatory requirements
• Security threats
• Managing product lifecycles & the pace of change
• Keeping the environment flexible
• Stability and resilience
• Personal learning
• Cost control

(more…)

The “Agility” concept has been a buzzword in business management science (what you might call the MBA crowd) long before it reached IT and software development. It was based on the ideas of lean manufacturing, such as just-in-time, continuous improvement, quality circles, and so on.

In order to meet the challenges of the marketplace, companies need to change frequently to introduce new ways of working, new functions, and connect to new customers, partners and suppliers. Even a non-commercial organisation has to adapt to changing legal, political and social pressures, and try to improve cost-efficiency. Any organisation that has moved beyond paper-and-pencil will need its IT to adapt accordingly.

(more…)

This blog contends that SysAdmin does not receive the attention that software development does; in research, debate and publication. But let’s first define our scope - what is SysAdmin? (Also, what is software development, and come to that, are there any other fields we’re excluding/including?)

Intuitively, software development is easy to describe - the process by which new software is created. In today’s integrated views of this process, development should not be separated from specification, design, testing or delivery, and it also includes the planning process for all these.

System administration is just about everything else. Simple! Well…
(more…)

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)

(more…)