Bij het ontwerp van een technische architectuur voor een applicatie of platform zijn de non-functional oftewel quality of service requirements van groot belang. Zeker als het om een bedrijfskritische omgeving gaat. Te vaak zien we in de praktijk echter dat ondanks de juiste specificaties, procedures en afspraken er toch van alles misgaat in geval van een rampsituatie.
Waar zit hem dat nou in? Laten we eerst eens kijken naar belangrijke aspecten van beschikbaarheid en wat daar bij komt kijken. Beschikbaarheid wordt meestal uitgedrukt in zogenaamde uptime. De volgende regels geven voor de meest voorkomende uptime percentages aan wat de bijbehorende downtime per jaar is:
99 procent – 3,65 dagen
99,5 procent – 1,83 dagen
99,8 procent – 17,52 uur
99,9 procent – 8,76 uur
99,99 procent – 52,56 minuten
99,999 procent – 5,26 minuten
99,9999 procent – 31,5 seconden
99,99999 procent – 3,15 seconden
Duidelijk: vanaf four nines’ wordt het echt serieus! Naast uptime worden de termen rto (recovery time objective) en rpo (recovery point objective) gebruikt. De eerste geeft de maximale tijd aan, waarbinnen het systeem na een ramp weer beschikbaar moet zijn. De tweede geeft het maximale verlies aan data aan. Veelal uitgedrukt in minuten. Dus bijvoorbeeld bij een rpo van vijftien minuten en een rto van zestig minuten moet na een ramp het systeem weer binnen zestig minuten beschikbaar zijn en er mag maximaal vijftien minuten aan data verloren zijn gegaan.
Bij de veruit meeste organisaties waar ik over de vloer kom, is een uptime van 99,8 procent of 99,9 procent gebruikelijk. Microsoft’s Windows Azure PaaS-platform garandeert bijvoorbeeld voor de meeste daarop geleverde diensten 99,9 procent beschikbaarheid. In dat geval is Microsoft verantwoordelijk voor het inderdaad leveren van die beschikbaarheid, volgens de service level agreement (sla). Indien de spullen bij een hosting provider draaien, is de hosting provider veelal verantwoordelijk voor het garant staan voor de afgesproken beschikbaarheid. Boetes of andersoortige compensatie bij het niet halen van de beschikbaarheidsafspraken staan beschreven in de algemene voorwaarden van de leveranciers. Meestal is het hoogste compensatiebedrag gelijk aan de gebruikelijke maand of jaarfactuur. Voor gevolgschade is men niet aansprakelijk.
Schijnveiligheid
Indien jouw it-organisatie zelf (deels) verantwoordelijk is voor het hosten van de applicaties of het platform heb je zelf nog wat meer verantwoordelijkheid. Zeker als technisch beheer bij jou ligt. Maar vergeet niet dat gemaakte fouten door functioneel (applicatie)-beheerders ook effecten kunnen hebben op de uptime van je applicaties. Hier heeft de partij waar de applicaties gehost worden niets mee van doen. De sla’s, afgesproken met je hosting provider of cloudleverancier, bieden, als je kijkt naar de gehele keten waarin het fout kan gaan, dus een stukje schijnveiligheid. Het aloude spreekwoord geldt hier ook: de keten is zo sterk als de zwakste schakel. Waarbij in dit geval de zwakste schakel vaak óf de mens óf slechte (test)-procedures zijn, die ook door mensen zijn opgesteld.
Het wel of niet beschikbaarheid zijn van een software oplossing zit hem veelal in kleine dingen. Dingen die bijvoorbeeld niets met hardware of netwerk te maken hebben. Dingen die vaak afhankelijk van elkaar zijn. Die ook vaak een sneeuwbaleffect tot gevolg hebben en kunnen leiden tot een complete meltdown. Denk aan een volle schijf op een database server. Nog steeds leidt dit in de meeste gevallen tot zéér onvoorspelbaar gedrag van applicaties en het weer terug naar normaal krijgen valt in dat soort situaties echt niet mee. Hierdoor is de rto vaak een echte uitdaging. Het goed, pro-actief monitoren van het platform is hierbij cruciaal.
Voordat iets een echt probleem gaat worden moet je al op de hoogte worden gesteld. De inzet (en juiste configuratie) van monitoring tools en het op de juiste manier melden en escaleren van incidenten helpen om de uptime hoog te houden. En niet te vergeten: de procedures (inclusief disaster recovery) moeten regulier getest worden!
Tot slot, vergeet ook niet dat de uptime niet alleen belangrijk is voor productieomgevingen. In sommige gevallen is de uptime van ontwikkel- en testomgevingen misschien nog wel belangrijker, zeker als er een leger aan inhuurkrachten op deze machines werkt. Wat kost het wel niet aan verloren productietijd per uur als een aantal Scrum-teams tegelijk werkeloos toe moet kijken in jouw tijd?
Gijs,
Er is een leuke SLA uptime calculator, deze kun je wat fijnmaziger afstellen want ik heb niets aan uptime als ik vrij ben of lig te slapen. Even voor de duidelijkheid, 2 maal een werkdag niet kunnen werken kan nog prima voldoen aan SLA van 99,8% maar is behoorlijk vervelend. Ook de door jouw genoemde schijnveiligheid lijkt me een open deur, het gaat niet om wie de toegang bewaakt maar vooral wie deze controleert. Als je geen toegang hebt tot de logfiles vaar je gewoon blind en nu zal ik wel weer de ‘edge’ opzoeken maar beheren van diensten in publiek cloud met een beheermodel dat ontwikkeld is voor een mainframe werkt niet, het is allemaal meer geluk dan wijsheid. Nu geldt dit ook voor private cloud oplossingen, oplossingen waar met server virtualisatie alleen maar de fysieke footprint in het datacenter is verkleind.
“Almost all ITIL and Service Management functions are impacted by a move to a virtual infrastructure” – BearingPoint
“ITSM Deployment strongly correlates with virtualization and consolidation success…. the complexity of these dynamic architectures requires customers to adopt an end-to-end service view of IT operations and service levels” – Ovum
“The fact is, too many IT departments are likely to follow the same path with virtualization that they did with SANs a few years back, and IP networks before that: deploying a technically-elegang solution and finding that without the right management tools, they’ve just sent themselves over a cliff at 60 mph instead of 30 mph.” – Richard Scannel, Glasshouse Technologies.
Ik heb het al eens gezegd de cloud geeft beheersbare kosten maar geen beheerbare oplossingen, zeker niet met de gebruikelijk ‘verkeerstoren’ mentaliteit van meeste I(T)SM boekhouders. Operationeel management in de cloud zal dus ingericht moeten worden vanuit de visie van een straaljager piloot: Lean, Mean and Agressive. Sturen vanuit de cockpit dus en niet zoals meeste IT-regisseurs het nu doen vanuit de business class met door stewerdessen geserveerde cocktails.
Ewout je laatste zin is een pareltje, die houden we er in.
Het artikel vindt ik echter niet slecht, op z’n duits “bodenstaendig”.
Prachtig verhaal maar ik denk toch voor veel lezers misschien wel een beetje ’te’ vaktechnisch geschreven. Ik kan me overigens wel vinden in een deel van het commentaar van Ewout.
Voordat iets echt een probleem gaat worden….
Wat ik in toenemende mate bespeur is dat het bedroevend gesteld is met de IT ketenregie bij steeds meer professionals. Het grote gevaar, iets waar de meer senior IT professional telkens voor waarschuwen, het Black Box Syndroom, vind meer en meer opgang. Het gegeven namelijk dat IT professionals te sterk vanuit eigen vakdiscipline denken en schrijven maar verder weinig oog hebben voor de eigen positie in de keten en de aansluiting met omringende disciplines.
Voor iets echt een probleem word is voor mij zoiets als…. iets IS een probleem of iets is dat niet. Geheel gelijk aan de mate waarop IT als vehikel word gebouwd. I/O, ja nee, true false. Zo eenvoudig moet het zijn en als dat niet zo is dan…..
Ik begrijp je laatste alinea eigenlijk niet zo. Je hele verhaal gaat over uptime van….. en in de staart kom je plots met ‘scrum’teams. Als je namelijk je IT, en dan natuurlijk ook de professionals, goed hebt geinstrueerd, dan heb je hen vast ook al uitgelegd hoe men met elkaar moet communiceren en samen moet kunnen werken. Scrum is dan wat mij betreft een nin argument.
hetgeen je hier aanhaalt geld veel meer nog voor de gebruikers en benefactors van de gehele IT keten. HR x DT x LoP is een veelgebruikte formule inzichtelijk te maken wat het verlies is bij ‘niet beschikbaar’ zijn van de IT infrastructuur en applicaties of data.
En de reden van onbeschikbaarheid beperkt zich echt niet door wat jij hier stelt alleen maar ook door leveranciers van nodes en de ‘kabelaar’, disciplines die niet sec gebonden zijn aan de hoster of cloudlevcerancier. Want de intentie van jou artikel gaat eveneens op voor de lokale IT infrastructuur en de lokale applicatieserver.
@NumoQuest
Hoe Gijs het bedoeld en in welke context weet ik niet maar wat ik wel weet is dat agile development en statisch beheer niet zo goed samengaan. Er is momenteel veel buzz rond DevOps maar hier is vaak de wens de vader van de gedachte want de door moeder afgesloten contracten beperken de bewegingsvrijheid. Gevolg hiervan is dat er nogal wat officieuze oplossingen zijn, rapporten geven aan dat 1/3 van de ICT diensten buiten de IT afgenomen worden. Zeg maar de IT regiseurs die met een paar klikken bedrijfprocessen en bedrijfsdata in de cloud brengen zonder zich druk te maken om de consequenties op termijn. Er is een Hall of Shame waar parels van ‘Rogue IT’ voorbeelden aantonen dat lichtvaardigheid tot grote schade kan leiden. Je black box syndroom is trouwens wel (gedeeltelijk) transparant te maken maar vaak is het politiek niet wenselijk, succes heeft misschien vele vaders maar mislukking blijft altijd een wees.
P.S.
In mijn reactie beperk ik me trouwens ook niet tot hosting providers, de fouten zijn namelijk systemisch want een wetmatigheid is dat als de kwaliteit goed is er altijd weer gezeurd wordt over de prijs.
Het feit dat ik over Scrum teams praat is niet zo heel relevant. In die paragraaf gaat het met name over het belang van beschikbaarheid van O, T en A omgevingen in een OTAP straat. Dat dat vaak onderschat wordt. Omdat als O, T of A omvalt er hele ontwikkel en test teams werkeloos toe zitten te kijken en de uurtjes doortikken.
Verder is de strekking van het verhaal dat uptime niet alleen in infra en platform health zit.
Ik ben het helemaal eens met jullie v.w.b. de keten verantwoordelijkheid en regie. Een blackbox filosofie is op zich prima, mits men aan een aantal (misschien wel SOA) principes voldoet.