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.
@Ruud,
https://www.computable.nl/artikel/nieuws/security/4503748/1276896/berenschot-biedt-gemeenten-apk-voor-ict.html
misschien iets voor jou?
APK is een begrip omdat het wettelijk verplicht is. Natuurlijk vindt bijna iedereen het nuttig, maar wie zou het nog doen als je niet jaarlijks die brief in de bus kreeg, dat je binnenkort niet meer de weg op kan als APK niet gedaan is ? Men stelt waarschijnlijk uit tot later, tot nooit, want het kost geld, tijd en iets anders zal prioriteit krijgen. Niet anders dan in ICT overigens.
Aardige van ICT is dat het zich technisch meestal eenvoudig automtisch laat monitoren. Niet jaarlijks, maar om de 5 minuten. Stuk efficienter dan jaarlijkse controle door dure consultants. Data wacht geen jaar om disk vol te maken. Techneut zet bijv debugging aan en nooit meer uit. Disk vol. EK voetbal streaming video, is ook niet precies tijdens APK.
@ Mauwerd,
Ik deel je mening dat ICT eenvoudig automatisch te monitoren is. Echter zal het je nog verbazen hoeveel mensen dit (pro)actief doen. En monitoren is natuurlijk 1 ding. Maar de juiste conclusies trekken is een stuk lastiger.
Tevens kom je in het geval van een escalatie er vaak pas achter of je omgeving echt hoog beschikbaar is. Het niet halen van je RPO/RTO is vaak dan pas echt inzichtelijk. Zeker op dit laatste gebied is een geregelde check-up geen overbodige luxe.
@mauwerd
Zoals ik ook al in mijn antwoord aan Reza aangaf is monitoren van de infrastructuur niet moeilijk maar zeggen die cijfers vaak niet zoveel. Vaak worden deze gegevens ook nog eens apart verzameld voor het SAN, de servers en het netwerk waarbij centralisatie en virualisatie niet voor meer transparantie zorgen. Mede door deze ontkoppeling zijn er vaak problemen met response en belasting van applicaties wat ook niet altijd op te lossen is met opschalen. Bijvoorbeeld als de database te weinig bandbreedte heeft voor de IOPS dan zal het bij zetten van extra presentatie servers niet helpen. Door de tiering, de lagen in applicatie modellen ontstaan dus nog weleens omgekeerde pyramiden welke niet echt doelmatig zijn. Om in de APK termen te blijven, er is meer uitstoot doordat de ontsteking niet goed afgesteld is.
Goed verhaal, waarin je het probleem juist verwoord.
Een goede reactie die ik gelezen heb is de reactie waarin wordt aangegeven dat het doen van een APK een vorm van betaalde acquisitie zou kunnen lijken. Zo ervaar ik het ook vaak bij mijn garage, toch laat ik het gebeuren, maar ik blijf kritisch. En dat is ook wat de klant moet doen. Kritisch zijn op wat hij heeft, APK laten uitvoeren en het resultaat kritisch bestuderen.
Ik ben ook een voorstander om de APK elk jaar door dezelfde partij te laten doen. Voorspelde groei, vergelijkingen met voorgaande jaren, extra polatie, etc. zijn dan veel beter te doen en zorgen voor een meer betrouwbaar eindresultaat.
Een fixed price moet mogelijk zijn als je vooraf duidelijk maakt wat je wel en wat je niet doet. Ook bij een APK wordt een vaste prijs genoemd. Daar zitten de reparaties en/of vervangingen niet bij.
Wij doen bijvoorbeeld in drie dagen de volgende activiteiten …. Dan schrijven we een rapport waarin we aangeven wat er aangepast moet worden. De klant kan dan zelf bepalen wat wel en wat niet uitgevoerd moet worden.
Heerlijke stof om te bespreken.
APK in de autobranche is ooit ingesteld om wrakken van de weg te halen en te houden, vandaag de dag worden nieuwe auto’s pas na 3 jaar gekeurd en de keuring is erg basaal. Ondertussen is er een toename bij de wegenwacht van auto’s die stranden, zowel in binnen als in buitenland. APK is een moment opname en geeft geen garanties op beschikbaarheid en betrouwbaarheid van de auto.
Binnen IT-beheer organisaties lopen verschillende groepen beheerders rond, functionele, applicatie en infrastructuurbeheerders en alle vormen daartussen. Het onderhoudspersoneel loopt constant rond de “auto” en dat mag een paar centen kosten.
APK invoeren, uitgevoerd door een extern bedrijf is bij gebrek aan normen en waarden, lees een generiek te definiëren standaard in mijn optiek onmogelijk. Iedere IT-er heeft zijn eigen perceptie, marges, technieken, tools, etc en dit is extern moeilijk te beoordelen, totdat er incidenten en calamiteiten optreden. Remvermogen bij een auto kun je eenvoudig vaststellen, performance is een subjectieve waarneming door verschillende mensen op verschillende niveau’s.
IT organisaties moeten zichzelf op een hoger plan tillen door diensten te leveren met vooraf gedefinieerde specificaties. Vervolgens kan je die specificaties meten en testen. Bij gebrek aan diensten met een specificatie blijft het dweilen met de kraan open. Als voorbeeld noem ik de ICT dienst SAP binnen een onderneming. Die wordt aan verschillende doelgroepen aangeboden en mensen worden geïnstrueerd en gaan aan het werk. Meestal houd het hier op en de serviceverlening wordt via de servicedesk, lees ANWB, geoptimaliseerd en in de lucht gehouden door het servicepersoneel dat om de “auto” heen loopt.
Voor wat betreft functionaliteit is er vandaag alleen nog maar invloed als het om maatwerk gaat. Je krijgt gewoon veel meer functies dan je nodig hebt en dat deze storen of klachten veroorzaken, dat heb je maar te accepteren, bij sommige auto’s is dit overigens ook zo.
Met een aantal eenvoudige tools kan je eenvoudig zelf een APK uitvoeren. Zo kan je patchlevels checken, capaciteit checken, trends signaleren en ook beveiligingsniveaus. Vaak zijn deze tools nog gratis te downloaden ook. alleen niemand gebruikt ze en klaarblijkelijk is er binnen de IT organisatie niemand die om informatie vraagt. Laten we daar nu eens beginnen, vervolgens normen en standaarden instellen en na een paar jaar kan een externe check laten uitvoeren.
Ik hoor veelal dat er veel tools zijn om automatische checks uit te voeren, zeg maar een deel van de APK, en vaak nog gratis ook.
Welke tools doelen jullie op en/of adviseren jullie hiervoor ?
@ibba
Er zijn heel veel hulpmiddelen, al dan niet gratis die de ‘health’ van een stukje van de infrastructuur controleren. De werking hiervan komt vaak op hetzelfde neer door configuratie te vergelijken met een ‘best practice’ en afwijkingen hierop te rapporteren. Microsoft Baseline Advisor doet dat bijvoorbeeld voor patches, VMware Health Analyzer voor de hypervisor en weer anderen voor de opslag of het netwerk. Gebruik hiervan geeft dus stukjes van de puzzel maar nog niet altijd een compeet beeld. Adviezen vanuit de ‘best practices’ kunnen ook onbruikbaar zijn omdat er andere technologie gebruikt wordt of er redenen zijn voor afwijkingen. Bijvoorbeeld dat een applicatie niet meer werkt na aanbrengen van een servicepack of dat gedeelde resources overbelast raken door ontbreken scheduling.
Gebruik van tools is dus een deel van de oplossing, het verzamelen van de gegevens. Om deze echter tot informatie en inzichten te verwerken is vaak nog een monteur nodig. Niet voor niets wordt bij brengen van de auto gevraagd of er nog klachten zijn.