The IT Skeptic - Comments for "SLAs: measuring an ITSM service as a black box is essential"

You comment on the challenge is too true

vaioboyaus — Sun, 01 Apr 2007 05:58:53 +0000

It can alert on all of your scenarios, so long as the network address of these services is known (presuming you are in an IP network of course). When we were trialing it, it became quite obvious that the clients network services provider was not doing 100% of the job they were being paid for. Suddenly the shutters came down on the SPAN port and the tool was left high and dry, despite numerous protestation from us (we were charged with managing the services provider) and the shared customer.

I do agree with you though Skeptic everyone has to enter the scene with the desire to improve the client's and their end-user's experience - not just meet SLA's.

Looking in her eyes I felt as near to Icarus as to the city before me as to the death of the sun. (The Long Road of the Junkmailer, Patrick Holland, 2006)

The challenge that tools like NetQoS have

skeptic — Sun, 01 Apr 2007 01:45:58 +0000

The challenge that tools like NetQoS have is to be service-aware. That is, they see packets, so they can tell what the user experience is overall, but can they differentiate between packets for the Payroll application and packets for eMail and apckets for the core business transactional system? One user might use all three services but have quite different SLAs for each. I don't know if NetQoS can or can't do this, but I know it is tricky if the tool is not actually out at the desktop tracking what applications and screens are executing.

I agree, there are some useful technologies out there

vaioboyaus — Sat, 31 Mar 2007 23:49:49 +0000

When I was working on an Internet Banking application, we looked at a product called NetQoS it was a client side monitor but you did not have to deploy a client side agent everywhere. We implemented it off a SPAN port in the central network core where it looked at the packets and their send/receive tags. That is for those of us (like me) that don't speak networkese the time the packet originated from the source and was acknowledged (responded to) by the dest.

The product kept stats for 13 months so you could see yesterday, last week, last month, last year to determine if the client experience was degraded - you could then target the deployment of client side agents as necessary (and quite quickly) to repsond to these flags. In fact with the appropriate thresholds you would be alerted to client experience problems quite possibly before the client even noticed.

(I do know that the product was implemented with some success in a major vehicle manufacturer)

The very nature of an IP network means that you cannot guarantee the paths that packets will take from a source to a dest and back, so no amount drawings is going to help that one.

As to the drawings, I haven't seen any yet that indicate the routing rules or traffic or its importance to the business (that is the importance of particular sources and dests of packets)

But then network types have always been a little odd to those of not from their world.

Have a happy easter everyone if I do not post before then.

VaioBoyaus

Looking in her eyes I felt as near to Icarus as to the city before me as to the death of the sun. (The Long Road of the Junkmailer, Patrick Holland, 2006)

The danger of being precisely wrong

Richard of Londres — Sat, 31 Mar 2007 10:00:58 +0000

I am 100% aggreement that top down is the way as it factors in the user/business.

I would add that the great danger of going bottom up is losing context and falling into the trap of being precisely wrong. Someone (within another silo) then see's how much time and effort you have put in to produce the "details" actually assumes that the outputs have integrity.

RedMule

RedMule Blog