Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

APK voor de ICT-omgeving

 

Computable Expert

Ruud Mulder
Advisory Systems Engineer, Dell EMC. Expert van Computable voor de topics Cloud Computing, Infrastructuur en Loopbaan.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4549928). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

@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.

@Ruud,

http://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.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×