Al jarenlang is de algemene periodieke keuring (apk) in de autobranche een begrip. Afhankelijk van de leeftijd van de auto wordt deze onderworpen aan een grondige keuring. Tijdens deze apk wordt de auto nagekeken op essentiële zaken als remmen, wielophanging, schokdempers, banden, stuurinrichting, verlichting en carrosserie. Als een auto is gekeurd, ontvangt de eigenaar een keuringsrapport, waarin zo nodig geconstateerde gebreken zijn opgenomen die niet tot afkeuring van de auto leiden maar wel binnen afzienbare tijd gerepareerd moeten worden.
Een apk-keuring kan ook in de ict van toegevoegde waarde zijn. Een periodieke controle op bijvoorbeeld de storage en back-up omgeving kan een hoop problemen voorkomen. Het gaat te ver om dit bij wet te verplichten en hier een keurmerk aan vast te hangen, maar zou het niet prettig zijn om op tijd te weten waar de pijn en verbeterpunten van jouw ict-omgeving zich bevinden? Helaas wordt bovengenoemde check nog veel te weinig of helemaal niet uitgevoerd. Het uitvoeren van periodieke check-ups en onderhoud is voor ict-omgevingen en platforms echter cruciaal. Gebeurt dit niet, kan men tot grote verassingen en uitdagingen komen te staan. Met grote gevolgen voor de beschikbaarheid en functionaliteit van de omgeving.
Welke zaken dienen opgenomen te worden in deze apk-keuring? Met alleen een paar keer per jaar de software, drivers en firmware update kom je er helaas niet. Onderstaand enkele aandachtspunten die belangrijk zijn bij een dergelijke keuring.
• Prestaties/capaciteit:
Voldoet mijn omgeving/platform nog wel aan de performance wensen en eisen die we initieel hebben vastgelegd?
Het inzichtelijk krijgen van de prestaties van het platform is in mijn ogen iets wat geregeld gedaan dient te worden. Groei je uit je jasje dan schakel je extra resources bij en kan je omgeving het met twee vingers in de neus af, dan kun je de vrije resources voor andere doeleinden gebruiken.
Doe je dit geregeld dan kan je deze cijfers ook voor trending/toekomst prognoses inzetten. Onderstaande zaken zullen dan een stuk inzichtelijker worden:
1. Wanneer moet ik uitbreiden?
2. Wat is mijn periodieke groei?
Zeker voor het bepalen van het jaarlijkse budget is het geregeld in kaart brengen van de prestaties en capaciteit essentieel.
• Beschikbaarheid:
Voldoet de omgeving nog aan de geldende sla's (service level agreements)? En in het geval van een back-up omgeving is het functioneel /operationeel controleren van de rpo (recovery point objective) en rto (recovery time objective) geen overbodige luxe.
Dit is ook het moment om één keer in de zoveel tijd opnieuw de discussie te voeren omtrent de wensen en eisen met betrekking tot de beschikbaarheid. Dit kan gedurende het jaar namelijk nog wel eens veranderen. Twee voorbeelden:
1. Niet alles is even belangrijk en dient bijvoorbeeld hoog beschikbaar te zijn.
2. Misschien is de pilot-applicatie wel cruciaal geworden voor de organisatie en dient deze hoog beschikbaar te zijn
Een controleslag op de sla ,rpo en rto is essentieel. Je wilt er in het geval van een back-up omgeving natuurlijk niet pas achter komen dat je rto niet haalbaar is omdat je platform te weinig performance, functionaliteit en beschikbaarheid biedt.
• Functionaliteit:
Biedt de omgeving nog wel de gevraagde functionaliteit of is er extra functionaliteit nodig? Of zijn bepaalde functionaliteiten wellicht overbodig geraakt? In dat laatste geval zijn er mogelijk kostenbesparingen te behalen.
• Patching/software/firmware:
Nog te veel ict-omgevingen maken geen gebruik van de laatste versies/updates. Denk hierbij aan het niet up to date hebben van cruciale firmware. Of het achter lopen op het gebied van updates. Dat laatste kan grote invloed hebben op de prestaties en beschikbaarheid van de omgeving.
Bovenstaand heb ik vier voorbeelden genoemd die in mijn ogen altijd onderdeel van de zogenaamde apk-controle dienen te zijn. Nu ben ik mij ervan bewust dat dit per type omgeving, platform en gebruikte technologie kan verschillen. Maar hoe je het ook wendt of keert, een jaarlijkse apk-controle en de daarbij behorende periodieke onderhoudsbeurten kunnen een hoop problemen voorkomen. Iets wat goed wordt onderhouden gaat nu eenmaal langer mee.
Wat je hier noemt is een selectie uit ITIL of een andere beheer framework. Laten we niet nog een control framework bedenken er zijn er genoeg. Good-practices delen voor infrastructurele diensten is natuurlijk altijd welkom. Niet steeds weer het wiel opnieuw uitvinden, maar tegen een ‘good-practice’ tegen het licht houden.
– Budgettering hulp: hoeveel procent van het beheer moet gereserveerd worden voor onderhoud?
– checklisten en process inrichting voorbeelden voor capacity management, demand-supply management (service portfolio), security management etc.
De beheer(organisatie) die geen periodiek onderhoud uitvoert is geen beheer organisatie.
@Ruud:
Wat opmerkelijk is, is dat de meeste bedrijven die hun ict-omgeving al uitbesteed hebben, ook deze dienst (jaarlijkse uitwijktest en overzicht beschikbare resources “SAN, Storage, geheugen, netwerk etc”) bij hun leverancier afnemen. Maar als hun ict-omgeving “in house” is dan wordt hier weinig tot geen aandacht aan besteed!
Klanten verwachten een fixed-price offerte voor dit soort activiteiten (apk-pakket. Maar een fixed-price offert aanbieden is niet zo simpel als die van auto! Dit komt doordat elke type auto standaardisatie in zijn bouw heeft terwijl elke ict-omgeving anders is ingericht en opgebouwd.
Hierdoor zou een leverancier veel dagen in zijn offerte moeten opnemen voor alleen het bestuderen en begrijpen van processen en inrichting van de ict-omgeving van de klant (afhankelijk van de business en inrichting, kan dit best ingewikkeld zijn) Pas hierna kan hij met aanbeveling over efficiëntie, Disaster Recovery binnen gestelde rto/rpo en andere zaken komen.
Ik vraag me af:
Als je ict in house hebt, moet je als klant deze keuring elk jaar door 1 vaste bedrijf(partner) laten doen of kies je elk jaar voor een ander bedrijf?
Als je voor een vaste partner kiest dan heeft dit een voordeel dat ze je omgeving goed kennen en efficiënt te werk gaan. Nadeel is dat ze hierdoor veel zaken kunnen overslaan en minder scherp zijn (want de klant is al binnen!)
Als je elk jaar voor een ander bedrijf kiest dan maak je meer kosten want deze partner moet eerst een paar dagen je omgeving en je business en ict-processen bestuderen om te weten hoe een DR/BC moet getest of ingeregeld worden.
Reza,
Je slaat de spijker weer eens op zijn kop! Zodra de omgeving nog in huis staat wordt dit nog te vaak vergeten.
Een fixed price voor dit soort checks blijft ook erg lastig. Belangrijk is dat er dan goed wordt aangegeven wat er wel en niet gedaan wordt. Voor dat je je auto bij de dealer achter laat maak je ook eerst duidelijke afspraken wat er wel en wat er niet mag gebeuren. Doe je dat niet dan kan je nog wel eens voor een verassing komen te staan.
Een vaste partner biedt absoluut zijn voordelen. Ieder jaar een ander kan gevolgen hebben voor de kwaliteit en mogelijke standaardisatie. Om nog maar niet te spreken over de kennis en ervaring van de omgeving. Die bouw je als uitvoerder van een dergelijke APK alleen maar op door het enkele keren te doen.
En ook hier is het vergelijk met een auto ook weer snel gemaakt. Je onderhoud en keuringen laat je ook niet iedere keer door een ander uitvoeren. Dat doe je alleen maar op het moment als je ontevreden bent.
Eigenlijk lijkt me die APK keuring een beetje overbodig. Het antwoord staat namelijk al in het stuk: de SLA. Voor de instantie die de SLA dient in te vullen is het van enorm belang om de randvoorwaarden voor die SLA te blijven volgen. Als ik in de SLA heb gegarandeerd dat de response tijd binnen die-en-die grenzen blijft, dan moet ik voor mijn eigen geruststelling de response tijden gaan monitoren en als die een trend vertonen die over niet al te lange tijd (zeg maar over 2 maanden) ervoor zouden kunnen zorgen dat ik de SLA niet meer haal, moet ik actie gaan ondernemen (of meer ijzer, of andere SLA of wellicht een andere mogelijkheid).
Dit gaat op voor andere zaken ook (SAAS, IAAS, etc., etc.). De SLA is voor de aanbieder van de dienst de handleiding voor de APK.
Voor de afnemer van de dienst is de SLA ook een handleiding voor de APK. Ook deze instantie zou (omdat anders zijn bedrijfsvoering plat dreigt te gaan) de SLA punten moeten blijven nameten en actie ondernemen indien het fout dreigt te gaan (uitgaande van de waargenomen trends). De afnemer mag er niet van uit gaan dat de aanbieder van de dienst dit ook doet.
Dat een aanbieder intern of extern is maakt in feite niet uit, maar bij interne aanbieders is er minder vaak sprake van een SLA.
Alles gelezen hebbende lijkt me de SLA juist de basis voor APK die wordt voorgesteld (op zich is dit overigens een goed voorstel).
@ Ruud,
op zich niet verkeerd, maar….
wanneer het door het bedrijf gebeurt, dat belang heeft bij de uitvoering van de apk, wordt het al snel betaalde acquisitie. Dat is ook de reden waarom dit toch niet zo aanslaat in de markt.
Fixed price kan prima, mits je vooraf goed weet wat er staat en je veel ervaring hebt in je vak……
@ Maarten,
Zoals je al aangeeft is het bij een fixed price van belang dat je weet wat er precies allemaal staat. Is dat niet het geval dan wordt fixed price lastig.
Het is dan een optie om eerst het landschap in kaart te brengen door middel van een inventarisatie onderzoek. Pas als het landschap duidelijk is kan er gekeken worden hoeveel effort er voor de APK dienst benodigd is.
We weten allemaal dat als je oliepeil te laag is de motor beschadigd raakt, misschien zelfs wel vastloopt. We weten ook dat als de brandstof op is je stil komt te staan en je dus niet alleen op tijd moet tanken maar ook de goede moet innemen. ICT is de motor van veel processen maar de goede werking ervan wordt zeker niet altijd gecontroleerd. Hierdoor hebben sommige applicaties teveel PK’s en andere weer te weinig. Regelmatig controleren hoe e.e.a. verdeeld is kan dan ook zeker geen kwaad.
@Ewout:
Controleren van de benodigde of gebruikte resources vind ik niet zeer moeilijk, daar zijn genoeg tools voor. wat ik juist belangrijk vind is controleren van de opbouw en inrichting van je ict-processen!
Ik heb vaak meegemaakt dat een omgeving 6 maanden naoplevering veranderd was in een oerwoud!
Ik was betrokken bij het maken van een draaiboek voor een disaster recovery business continuity (DR/BC) van bedrijfskritische applicaties van ene klant. Tijdens deze test waren veel problemen naar boven gekomen die afkomstig waren van applicatie-oerwoud, onoverzichtelijke ict en businessprocessen en nog meer. Deze waren zaken die in de dagelijkse beheeractiviteiten niet zichtbaar waren. Deze rommelige processen waren ook de bron van veel overhead en extra kosten voor de ict van dat bedrijf.
Ik pleit voor uitbereiding van APK-voorstel van Ruud met een DR/BC activiteit per jaar.
@Reza
Het meten van resource belasting is inderdaad niet moeilijk, wel om dit te verbinden aan applicaties en sevices zoals je zelfs volgens mij ook stelt in reactie. Oftewel de motor draait soepel maar door de ontkoppeling is er geen voortdrijving. De overhead waar jij het over hebt en ik spreek over teveel of te weing PK’s. Hiermee bedoel ik dus de processorkracht, opslagcapaciteiten en bandbreedten. Hoe meer, hoe beter wordt er vaak gedacht waardoor dingen uit de pas gaan lopen, niet goed op elkaar afgestemd zijn en je inderdaad problemen krijgt als een applicatie- en proces oerwoud waar veel verspilling in zit.
Reza,
Het in kaart brengen van de resources en deze aan bijvoorbeeld ervaringsgetallen of best practices toetsen kan nooit geen kwaad.
Zo kan je inzichtelijk maken of je omgeving/platform het goed doet. Of waarbij nodig naar boven of naar beneden aangepast te worden.
140 in je 2e versnelling rijden houdt een auto ook niet lang vol.