‘Beheer-esperanto’ vermindert communicatiestoringen

In tegenstelling tot de algemene veronderstelling is de beheermethodiek ‘IT Infrastructure Library’ ook goed toepasbaar in gedecentraliseerde omgevingen, stelt ir A.J. de Vuyst. Zo voorkomt de uitvoering van probleembeheer volgens Itil, dat verschillende specialisten onafhankelijk van elkaar zoeken naar een oplossing voor hetzelfde probleem.

In een complexe IT-omgeving valt of staat een goed beheer met de mogelijkheid om nauwkeurig te weten wat er in de systemen gebeurt. De mainframe-wereld loopt op dat punt fors voor op de decentrale wereld, al wordt het gat wel snel kleiner. Er komen bijvoorbeeld steeds meer middelen om centrale beheertools te koppelen aan decentrale stukken van de IT-infrastructuur. Maar de hulpmiddelen voor processen als capaciteitsbeheer, beschikbaarheidsbeheer en kostenbeheer zijn nog steeds erg magertjes voor decentrale delen van de infrastructuur .
Dit heeft te maken met het feit dat de beheerproblematiek bij gedecentraliseerde omgevingen groter en vooral complexer is dan in met name centraal gerichte organisaties. Hoe moet je bijvoorbeeld omgaan met versnipperde databases en afdelingen die elk hun papieren lijstje bijhouden van IT-middelen? Hoe moet je reageren op de autonomie van decentrale delen van de organisatie? De beheerproblemen bij gedistribueerde en gedecentraliseerde omgevingen zijn groter en complexer dan in voornamelijk centraal gerichte organisaties. En de complexiteit wordt groter naarmate de decentralisatie of gedistribueerdheid toeneemt.
Een oplossing voor het probleem dient te worden gezocht in het toepassen van een beheermethodiek in plaats van het opstapelen van ad-hoc maatregelen. De beheermethodiek Itil (Infrastructure Library) kan in een gedecentraliseerde omgeving prima voldoen, omdat het geen centrale concepten veronderstelt.

Misverstand

Itil is een beschrijving van beheerprocessen binnen IT-organisaties in de vorm van – publiekelijk verkrijgbare – boekjes. Behalve handleidingen voor de basisprocessen bevat Itil ook titels die van belang kunnen zijn voor decentrale omgevingen. Voorbeelden zijn ‘Management of Local Processors and Terminals’, ‘Office Design and Planning’ en bijvoorbeeld ‘Management of Electrical Interference’. De titels duiden er al op dat het een misverstand is dat Itil zou zijn toegesneden op centrale omgevingen.
Ook de beschrijvingen van de basisprocessen zelf besteden regelmatig aandacht aan juist decentrale organisaties, als het bijvoorbeeld gaat om mogelijke organisatievormen voor helpdesks.
Voor elk van de basisprocessen geldt dat de meerwaarde in een decentrale omgeving groter is dan in een ‘puur’ centrale omgeving. In het algemeen neemt het aantal communicatiestoringen binnen een organisatie drastisch af bij het toepassen van een gezamenlijk, compleet en consistent beheermodel. Itil fungeert daarbij als een soort beheer-esperanto.

Operationele processen

De processen helpdesk en probleembeheer beschrijven onder andere het strikte onderscheid tussen verstoringen in de dienstverlening ( ‘incidenten’) en de oorzaak van die verstoringen (‘problemen’). De helpdesk probeert incidenten op te lossen en, als dat niet lukt, toe te wijzen aan ‘oplosgroepen’. Incidenten worden niet alleen gemeld door gebruikers, maar ook opgemerkt en (veelal) afgehandeld door systeem- en netwerk-operators. De voortgangsbewaking van alle open incidenten is een verantwoordelijkheid voor de helpdesk. Het helpdesk-proces kan waardevolle management-informatie opleveren over de effectiviteit van alle beheerprocessen, doordat het overzicht heeft over alle incidenten. Nieuwe incidenten worden zo snel mogelijk gekoppeld aan bestaande problemen, met informatie over bijvoorbeeld een work-around of het verwachte tijdstip van een definitieve oplossing. Als het niet lukt een incident te koppelen, is er sprake van een nieuw probleem. Problemen kunnen langer openstaan dan de eruit ontstane incidenten, zodat niet ten onrechte problemen – die toch al opgelost zijn – uit het gezichtsveld verdwijnen. In een decentrale omgeving hebben alle betrokkenen inzage in de lopende problemen (niet per se in alle lopende incidenten).
Zo voorkomen deze processen dat een op meerdere plaatsen ondervonden probleem ook op meerdere plaatsen wordt opgelost. ‘Probleembeheer’ voorkomt ook dat een probleem dat op een bepaalde site werd opgelost, nog eens optreedt op een andere site.
Configuratiebeheer heeft een breder bereik dan alleen hardware en software, zoals we in de praktijk vaak zien. Beheer moet immers alle componenten omvatten die nodig zijn voor het leveren van de gewenste diensten, inclusief zaken als documentatie, contracten met leveranciers, gebouwinstallaties (bijvoorbeeld airco), procedures, en dergelijke.
Wijzigingsbeheer beschrijft een proces, waarbij gezamenlijke autorisatie van wijzigingen plaatsvindt aan het begin van het traject in plaats van op het moment dat de ontwikkelwerkzaamheden al achter de rug zijn en ontwikkelafdelingen wijzigingen bij de produktiegroep ‘over de muur gooien’. Een belangrijk hulpmiddel voor communicatie is daarbij de (openbare) wijzigingskalender, waarop voor elke wijziging is aangegeven wanneer deze in produktie gaat. Zo’n kalender kan een horizon van meerdere maanden hebben. Tijdige en complete communicatie is de sleutel tot het voorkomen van urgente wijzigingen.
Zonder ordentelijk configuratie- en wijzigingsbeheer is een sterk gedistribueerde omgeving met losse koppelingen tussen autonome subnetwerken in feite niet stabiel te houden. Uniform wijzigingsbeheer vermindert in gedeconcentreerde organisaties willekeur in de behandeling van aanvragen van verschillende ‘business units’ door verschillende ontwikkelafdelingen.
Programmatuurbeheer gaat uit van één centrale opslagplek voor alle programmatuur-onderdelen (dus ook handleidingen en dergelijke), van waaruit overdracht plaatsvindt naar ontwikkel-, test-, en produktie-omgeving. Alleen binnen de ontwikkelomgeving mogen nieuwe versies ontstaan. ‘Snelle reparaties’ in test- en produktie-omgeving kunnen anders verloren gaan bij nieuwe releases. Het proces schenkt verder aandacht aan het ontwikkelen van eigen release-strategieën in plaats van het blindelings volgen van de leverancier.
De problemen, die een goede programmatuurbeheer oplost, zijn in decentrale omgevingen vele malen groter dan in een centrale omgeving. Sommige problemen bestaan daar niet eens, zoals onbekende illegale kopieën. Een formele vorm van programmatuurbeheer is daarnaast de basis voor effectieve viruspreventie. Een eigen release-strategie in combinatie met een telkens te gebruiken moederkopie voorkomt het ontstaan van vele varianten van PC-software.

Tactische processen

Kostenbeheer richt zich op het sturen van de uitgaven van de IT-organisatie, en niet alleen op doorbelasting. Bij dat laatste is het overigens van belang om voor de gebruiker hanteerbare entiteiten te gebruiken in plaats van vage en niet goed stuurbare begrippen zoals cpu-ticks, cilinders en dergelijke. Kostenbeheer is door de versnipperdheid van de infrastructuur in decentrale omgevingen nog belangrijker dan in centrale omgevingen.
De verborgen kosten – waarover de discussie enige jaren geleden werd aangeslingerd door de Gartner Group – zijn in een gedistribueerde omgeving veel meer verborgen en veel minder in de hand te houden. Omdat de klanten in gedeconcentreerde omgevingen vaak zelf minder verstand hebben van IT-jargon is het belangrijker (en lastiger) om dóór te belasten en te communiceren in voor de klant begrijpelijke begrippen (bijvoorbeeld bij naam genoemde transacties in plaats van
CPU-ticks).
Capaciteitsbeheer heeft voor een centrale omgeving een planhorizon van twee tot vijf jaar. Voor decentrale omgevingen is dat vaak niet haalbaar. Het proces legt de nadruk op vooraf sturen in plaats van af te wachten tot er zich weer ergens een tekort manifesteert. Ook activiteiten als afstemming en performance measurement krijgen een gestructureerde plaats in dit proces.
Ook beschikbaarheidsbeheer legt de nadruk op actief sturen in plaats van reactief afwachten. Het besteden van aandacht aan de noodzakelijke afspraken met interne en externe leveranciers is daarvan een voorbeeld. Beschikbaarheidsbeheer pleegt men ook door het aanreiken van structurele methoden voor het berekenen en optimaliseren van de beschikbaarheid van geleverde diensten.
Capaciteits- en beschikbaarheidsbeheer geven structuur aan het uitrollen van netwerken en servers, en voorkomen het plotseling dichtslibben daarvan. Potentiële problemen van capaciteitsgebrek zijn bij servers en netwerken groter dan bij mainframes. Die slibben meestal langzamer dicht en laten de beheerder zo nog wat tijd zijn fouten te herstellen.
Calamiteitenplanning beperkt zich niet alleen tot totale uitwijk, maar vraagt ook aandacht voor andere vormen van omgaan met calamiteiten, zoals het grotendeels wegvallen van de rekencapaciteit. Welke applicaties mogen dan blijven doordraaien en welke gaan ‘uit de lucht’?
Tevens is er ruime aandacht voor de relatie tussen calamiteitenplanning en wijzigingenbeheer. Zo kan elke wijziging gevolgen hebben voor het calamiteitenplan. Calamiteitenplanning zal in gedistribueerde omgevingen meer de aandacht leggen op uitwijk van subdelen van de infrastructuur dan op complete uitwijk. Dat is aan de ene kant complexer, aan de andere kant goedkoper realiseerbaar. Uitwijk binnen de eigen organisatie is beter mogelijk bij decentrale systemen. Het bereikbaar maken van de in geval van uitwijk draaiende toepassingen vormt bij wijdvertakte netwerken trouwens een uitdaging op zich.
Uitgangspunt van dienstenniveaubeheer is de gebruiker te behandelen als klant. Dit proces omvat activiteiten als het opstellen van een dienstencatalogus, het meetbaar maken van dienstenniveaus en het onderhandelen daarover met gebruikers. De eerder genoemde processen ondersteunen het dienstenniveaubeheer, dat er zichtbaar en verifieerbaar voor moet zorgen dat een belofte ook kan worden nagekomen. Beheer van dienstenniveaus is een ‘must’ in gedeconcentreerde organisaties met zelfstandige ‘business units’, al is het alleen maar omdat je die units niet over één kam kunt scheren. Toch kan een organisatie niet volstaan met alleen het invoeren van ‘service level agreements’. Het is juist de samenhang tussen dienstenniveaubeheer en de hiervoor genoemde processen, die er voor zorgt dat formele overeenkomsten met gebruikers meer zijn dan een hol vat en dat klanten de overtuiging krijgen dat ze zich geen zorgen meer hoeven te maken om hun IT-voorziening.