Opinion- should we give Availability back to the Engineers, as suggested by S.A. Hodson?

greenspun.com : LUSENET : Service Level Management : One Thread

Do you agree w/ S.A. Hodson? Yes, no, maybe!? See his article , and give us your thoughts!

-- Christian Sarkar (christian_sarkar@bmc.com), December 03, 2001

Answers

I do not really agree with the suggestion in the article.

The issue for me has to do with "system". While my "database system" on the server may be available, the "data entry system" for the end- user may not be available due to overload or errors caused by system complexity (or whatever, the end-user couldn't care less). So availability is related to the the user of the system. As a service provider, my "data entry system" may be unavailable although the owner of the database system, the owner of the operating system, the owner of the network system all confirm that their systems are "available".

Systems must be designed to avoid the facts like collective users that cause overload error conditions, e.g. networks can have packet shapers to limit mail and file-download traffic. Availability measurement is crucial to alert when these error conditions occur, after which problem analysis and corrective actions should occur.

I agree that it is difficult to assign numbers to "Availability", We may need a more elaborated definition for it (like: "response time below 10 sec in 95 % of the cases measured with a well-defined script at 5 minutes interval"). But once the definition is in place and agreed upon, we can start using mathematical modelling again.

I also have a problem with the suggested alternative term "Usable". Too many systems behave exactly as the designer intents, but they may be a bit 'clumsy' in the user-interface, making them not usable at all although they are fully available...

-- Dirk Vermeylen (dirk.vermeylen@eds.com), January 16, 2002.


The author’s point is well made i.e. do not confuse the specification of system availability (in engineer’s terms) with the system availability specification for use as a service level metric. To introduce a new term Usability would go some way to making the distinction.

The most important criterion for establishing a good metric for SLA’s is how well it reflects the user’s experience or the actual service performance delivered. Classic availability does not propose to do that. In my experience, while availability is the most common metric and easiest to understand, the definition employed is somewhat closer to the Usability definition i.e. the system is unavailable when it cannot be used as the user has specified. No limitation is placed on the reasons for the unavailability (operator error, poor response, 3rd party failure etc), what matters is that the service is not delivered.

I agree that that a new term Usability is worthy of being introduced, but I would contest that the ‘availability’ metrics used by Service Level Practitioners today are probably closer to Usability than the BSI defined Availability.

-- Dave Wickens (dave.wickens@governus.co.za), August 12, 2002.


Availability is the term adopted by the IT Infrastructure Library -- the industry defacto best practice in use since the late 1980s and now in use the world over. Thus, the word Availability is established.

-- Hank Marquis (hank.marquis@opticominc.com), October 24, 2003.

Moderation questions? read the FAQ