IT metrics fallacies

Friday 16 December 2011, 08:27:00 | software dev

Interessante post van iemand op slashdot:

The major fallacy many big companies fall into is that some of these systems have been running flawlessly for years, because they hired a competent IT staff. They look at the price of those paychecks and shiver. Why are we paying so many high priced engineers when we've never had a problem, they think.

So they reduce staff and start to rely on support contracts instead of on-site gurus. The gurus are still there to solve any oh-shit moments. But that back investment in good engineers has produced a stable infrastructure that runs with few problems for years. So they reduce staff more, pay for more support contracts, and eventually the system critical mass is greater than the engineers who can support it. It's no problem until it's a problem.

Eventually something minor goes wrong, but nobody notices or if they do it's not really their field of expertise so they don't understand it's minor now but could escalate. When it does, something else goes wrong, and a cascade effect takes out more and more systems. With a full staff, you have enough guys that when the critical mass is reached, they can start defensive measures and get things back in working order in no time. With support staff only, things are going wrong faster than they can deal with it.

"Call on our support contracts," shout the bosses! So now your on-site staff are all on hold instead of troubleshooting. When they get through to someone, they have to spend the first hour or two describing their infrastructure to the technician on the other end, who starts making random suggestions that maybe help, but probably don't.

Het praktijkvoorbeeld dat hij vervolgens noemt is best wel erg te noemen... :-|

People have replied:

Rik vd Ende

2011-12-17 08:57:00

Ik had ook een keer zoiets, gelukkig in de QA database, niet in PROD. Er liep een simpel proces om een batch mailingen in PDF formaat in de database op te slaan. Vanwege een fusie waar alle klanten van op de hoogte moesten worden gebracht waren er op een dag niet het gewone aantal pdf's, maar 3 stuks voor elke klant! Met het inserten van zoveel blobs loopt de replay log dus vol, en krijg je overal mysterieuze time outs.

Het probleem was dat de IT kant recent was geoutsourced naar IBM. Aan de software kant was dus geen Oracle DBA die dit soort dingen had kunnen weten, en met IBM was geen contract om een probleem uit te zoeken, dus het enige wat die wilden doen was een log sturen: 'java.sql.SQLException: Socket read timed out' met de opmerking dat het probleem in onze applicatie zat. Je bent dan genoodzaakt in het blinde weg mogelijke workarounds in te bouwen en te laten deployen door IBM (iedere deployment kost geld), die geen van allen het gewenste effect hadden. Gewoon een half uur pauzeren en nog een keer proberen bij een time out had wel het gewenste effect, maar op die manier zou de verwerking van de batch vele dagen duren, en al die tijd bij alle applicaties op die database time outs veroorzaken. Dat kon dus nooit naar productie.

Uiteindelijk heeft iemand een oud collega die nu zzp-er in IBM dienst was bij de database afdeling tegen de contracten in prive opgebeld. Die heeft er stiekum even naar gekeken en had binnen 5 minuten de oorzaak gevonden en opgelost: replay log liep vol, ik heb hem even vergroot, probeer het nog eens. Probleem opgelost. Als IT en software niet over twee verschillende bedrijven was verdeeld, was dit probleem dus in 5 minuten opgelost geweest.

Irmen de Jong

2011-12-17 14:47:00

Ouch. Maar komt me redelijk bekend voor helaas. Wij kampten ook met een performance storing / locking probleem wat nog altijd niet helemaal achterhaald is, maar wat -net als jij aangeeft- "opgelost" is door maar een handvol aanpassingen min of meer lukraak in te bouwen en te kijken of het daarmee op productie weg ging.

Ken je het boek Release it! ? Daar staat ook een zeer interessant verhaal in over een meltdown in een air traffic reservations systeem en hoe ze daar mee omgingen. Hoofdstuk heet "the exception that grounded an airline"....