Dat zou inderdaad een interessante zijn, maar je moet natuurlijk wel heel erg oppassen met vergelijkingen maken. Als de onderliggende infrastructuur en het applicatielandschap volledig afwijken van elkaar kan je uiteraard nog altijd het aantal functionele verstoringen bekijken. Als in 'hij doet het niet'. Maar achter één 'hij doet het niet' kunnen natuurlijk meerdere verstoringen zitten, die al dan niet meer dan één oorzaak hebben.
Als we alleen een lijstje kunnen krijgen "ING zoveel dit jaar bij de internet bankieren en zoveel bij de betaalpassen" en zoveel voor de ABN-AMRO, enz. enz. enz. Dan is dat niet zo interessant natuurlijk. Als ze vervolgens ook nog rapporteren, met hoe lang de storingen duren (gemiddeld, maximaal, minimaal, enz.) dan wordt het misschien al wat interessanter. En als er ook nog bij komt hoe snel en volledig ze communiceren, wordt het misschien wel aardig. (hoe open en transparant ze zijn. Dus of ze roepen 'Al onze klanten gebruiken de betaalpassen verkeerd!!' of 'Het ligt aan iedereen z'n telefoon/internetverbinding'

)
Je ziet bij iedere verstoring van een groot bedrijf hier wel iemand roepen 'Ze moeten het ook redundant uitvoeren', 'ze moeten beter testen', 'bij ons gebeurd dit nooit', OTAP-straat links en recht, blablabla. In de praktijk zijn er maar weinig bedrijven die de onderliggende oorzaak van een verstoring publiceren om verschillende redenen.
Onder aan de streep hebben we daar als klant natuurlijk ook geen boodschap aan. Het is een dienst die het moet doen, en als het eventjes kan, altijd. Als hij het niet doet vanwege een menselijke fout, een ontplofte switch, aardstralen of een maanstand hebben we natuurlijk niets mee van doen. Het moet het gewoon doen.
In mijn professionele ervaring zijn er tegenwoordig maar weinig verstoringen die komen door falende hardware. De 'dubbel uitvoeren' gaat bij banken sowieso niet op. Geloof maar dat alle financiële instellingen alle betalingssystemen minimaal 'dubbel hebben uitgevoerd'. Al is het maar om aan de regels van de DNB en de ECB te voldoen en hardware in de praktijk niet de duurste componenten zijn van het geheel.
Veel verstoringen die ik voorbij zie komen vloeien voort uit menselijke fouten (iets naar een verkeerd systeem hebben geïnstalleerd, de netwerkgegevens van het testnetwerk in de release hebben laten staan, ik noem maar een paar lullige zijstraten) of een gemiste test. Het is zeer complex om alles 100% zowel functioneel als technisch te testen. Uiteraard niet onmogelijk, maar wel HEEL complex.
Er zijn van die situaties van "Normaal verwerkt de applicatie 100.000 transacties per minuut. Het werkte bij de oplevering van de applicatie prima met een stresstest van 1,5 miljoen transacties per minuut (factor 15 meer dan nodig was bij oplevering). Die applicatie draait al meer dan drie jaar probleemloos, gewoon normale onderhoudspatchen en kleine functionele aanpassingen. Allemaal geen probeem. Het systeem groeit langzaam in gebruik, maar zorgt nooit voor performanceproblemen. Niemand denkt er aan om voorbij die 1,5 miljoen te testen. De volumes hebben nog nooit voor problemen gezorgd. De systeembelasting (CPU/IO/geheugen/enz/enz/enz groeien wel een beetje, maar allemaal prima binnen de marges) De groei bereikt een kritische punt en boem. De applicatie stort
functioneel in. Wat bleek. Bij 1,51 miljoen breekt de applicatie vanwege een bepaalde ontwerpkeuze xyz.
Uiteraard kunnen we zeggen. Bovenstaande had getest moeten worden, naar mate de applicatie groeit, enz. enz. enz. Maar je moet er wel maar net aan denken dat een applicatie die groeit, nooit voor problemen zorgt, nooit performanceproblemen geeft, in eens
functioneel kan instorten door groei boven een specifiek kritisch punt.
Houd ook rekening met externe toeleveranciers van data. Hier heb je in de praktijk weinig invloed op. Uiteraard kan je allemaal zware SLAs e.d. hebben, maar als het stuk is door die derde partij, dan is het stuk. SLA of niet.
Al met al, is het heel moeilijk om een eerlijke vergelijking te maken die ook waardig is voor op een tech-site. Als je niet oppast wordt het al snel een 'bash-artikel'