Category: Discussion

Questions are so important when fault-finding; the more data you have, the more visibility you have of the situation.

What, Where, When

If you know what failed, where it failed, and/or when it failed then extraneous data can be discarded if it doesn’t match the answers to these questions.

Would you really want to discard data? Surely the more data you have the better? Well, yes, to a point. But the objective is to find the fault; anything else is noise and may distract from the objective.

Why

This is the answer you really want; you might know the what, the where, and the when, but until you can explain why you cannot fix the problem. Fault finding is about taking the what, where, and when, and coming up with the why.

How

How you fix the issue is up to you; if you know why a system doesn’t work then you have many options of how to deal with that problem. It might involve replacement, repair, or just plain ignoring the issue if it isn’t worth addressing.

Perhaps you are a CEO or CTO of an organisation that has contracted services out to one or more suppliers. And things are not going as smoothly as desired.

You may be looking for independent analysis.

Even if you already have a report on your desk from your vendor outlining potential issues – it might pay to have an independent viewpoint that you can take to your board as further evidence action is required.

IT Fault can evaluate your systems and provide you that independent technical report. Call today to arrange an evaluation of your systems.

There’s an old joke. It goes:

A specialist is somebody that knows more and more about less and less until they know everything about nothing.

A generalist is somebody that knows less and less about more and more until they know nothing about everything.

Like most good jokes there’s a grain of truth to it. But joking aside why is an “experienced generalist” somebody you want hunting down a fault for you?

In most organisations employees are tasked with a particular aspect of a complex system, for example:

• your developers are dealing with a set of APIs – in the Java world this might be Hibernate, Spring, or an Apache connection pooling library
• your system administrators are dealing with rolling out code – often to development environments first and then production environments
• your virtual machine team is dealing with creating and destroying virtual machines – as requested by the project and managing resource utilisation
• your devops team is dealing with another set of APIs – be they cloud related or managing the installation and upgrade of physical hardware your company owns

Each of these is often focused on their particular area of expertise and responsibility. And as much as one might try and refrain it is all to easy to blame another team when something goes wrong.

A generalist may not know the specific APIs your team is using. They may not know the specific limits of your hardware. But they’ve been around long enough to build up the skills to find out what needs focus.

That generalist will then pour through documentation and other material available to match recognised symptoms with potential problems – then hone in to eliminate potential areas of trouble.

The generalist will discount nothing! And they do not need to defend a specific aspect of a system. They are free to consider all the possibilities. And sometimes the results are quite surprising! But they are stories for a different day.