ICT-beheer volgens McDonald’s-methode

Wie zijn serverpark virtualiseert moet zijn beheertactieken aanpassen. Ik gebruik vaak het voorbeeld van de slag bij de Somme in de Eerste Wereldoorlog. Het Britse leger kon als eerste over de tank als nieuwe techniek beschikken. Helaas was de gevechtstactiek die de toenmalige generaal Haig toepaste ouderwets en niet toegesneden op de mogelijkheden die de tank bood. Door dagenlange artillerie beschietingen op de Duitse stellingen was het terrein onbegaanbaar voor de tanks. De enige reden dat infanteristen bereid waren ze aan te duwen was dat achter de tank men veiliger was tegen mitrailleurvuur. De slag werd een fiasco voor het Britse leger. Pas later ontdekte men dat vroeg opstaan, met de tanks als voorhoede naar de stellingen rijden en later de infanterie sturen veel effectiever was. Dit idee om de tactieken aan te passen kwam van de tankcommandanten zelf.

De grote sprong voorwaarts die virtualisatie je oplevert is dat data alomvattend en centraal wordt. De data bevat het operating system- en de applicatieconfiguratie, maar belangrijker nog; je gegevens. Samen vormt het alles wat nodig is om jouw gegevens middels je applicaties te ontsluiten. Dit geeft nieuwe mogelijkheden die pas wat opleveren als je niet verdergaat met dagenlange artilleriebeschietingen zoals je gewend was. We gaan de tactieken hierop aanpassen.
Na je de vorige keer in verwarring te hebben achtergelaten over de leveringsbetrouwbaarheid van jouw ict en die van McDonald's wordt het tijd eens na te gaan hoe ict-beheer ver-McDonald's-iseerd kan worden. Daarbij is de doelstelling natuurlijk de leveringsbetrouwbaarheid te verbeteren. Virtualisatie kan daarbij een rol spelen, maar heeft pas een effect als de de keuken op de hoogte is van de recepten. We beginnen daarom precies daar; bij de recepten! Waarom vraag je je af?

Jouw huidige ict-beheer heeft procedures (recepten) voor het beheren. Deze procedures zitten in de hoofden van het personeel en misschien zijn ze al in een handboek soldaat beschreven. Dat laatste zou mooi zijn, maar er is een grote kans dat je er nog nooit de tijd voor hebt genomen. Nou had je het elke leverancier kunnen vragen om bij implementatie een beheerdocument op te leveren waarin stap voor stap de handelingen voor het bereiken van een doel staan omschreven. Zelfs al had je dat gedaan, dan is er nog een kans van dat jouw leverancier dat niet heeft geleverd. Is dat erg? Ja. Deze procedures zijn je menu's en het lukt McDonald's deze procedures de keukens in te schuiven waar vervolgens honderden 'koks' in den lande hetzelfde produc opleveren, door de procedure te volgen. Dat gaan we nu voor jouw ict regelen!

Waar te beginnen? Allereerst is het in kaart brengen van de huidige situatie vereist. Die bevat namelijk de diensten/producten die je moet leveren aan jouw organisatie. Omdat bij de meeste organisaties waar ik mee in contact ben geweest deze dienstverlening complex is en allerlei afhankelijkheden heeft, is de makkelijkste en meest betrouwbare benadering die van de bouwsteenbeschrijving. Elk onderdeel van jouw dienstverlening is terug te brengen naar vier delen: hardware, operating system, RDBMS en applicatie. Voor elk onderdeel wordt vastgelegd welke configuraie-items er zijn en hoe die zijn geconfigureerd. Het RDBMS (relationeel database management system) is daarbij een vreemde eend, het wordt ook als middleware betiteld. Dat deel mag daarom als het niet aan de orde is wegvallen, de overige drie niet.

Het voorbeeld dat ik wil gebruiken is de DNS-server. We definieren DNS als dienst. Van de dienst maken we een dienstbeschrijving waar dit in staat. Welke hardware levert de dienst? Dat is bijvoorbeeld een computer ergens op de vliering van de opslagruimte. Deze computer heeft een aantal kenmerken, zodat een persoon die de dienstbeschrijving leest weet om welk apparaat het gaat. Een naamsticker wil wel eens helpen. In dit apparaat zitten onderdelen, ook deze zijn beschreven, zoals de netwerkkaart. Deze heeft een specifiek adres en dat noteren we ook. Voor hardware moet ook vaststaan welke stroomgroep gebruikt wordt.

Als deze lijst compleet is gaan we naar het operating system. Bij deze DNS-server is dat toevallig Ubuntu Linux. Dit operating system heeft een driver voor de net beschreven netwerkkaart. Daar hoort een versie bij. Er is een IP-adres geconfigureerd voor die netwerkkaart.

De applicatielaag is nu de DNS-services. Huh? Dat is toch geen applicatie? Nou, voor dit bouwblok wel. Andere computers vragen via bijvoorbeeld Internet Explorer (een applicatie) wel gegevens aan deze service, maar voor het apparaat op de vliering is dit de applicatie; een applicatie die IP-addressen en namen koppelt. De configuratie hiervan is beschreven.

Maar Willem, dat is toch gewoon een CMDB? Dat is juist. Ik ben dan ook nog steeds een ITIL-adept. Heb je die CMDB al dan? Zo ja, we gaan gewoon verder, zo nee, laat we het maken dan.

Van al deze delen hebben we een installatiehandleiding nodig. Niet de algemene, maar degene die is gebruikt voor de installatie van deze dienst. Dus van hardware tot applicatie een beschrijving waarin staat hoe je de dienst moet installeren, liefst met plaatjes natuurlijk, in kleur. Wanneer dit goed beschreven is, en dat is te controleren, moet iemand aan de hand van de handleiding de installatie na kunnen doen. In de handleiding zit een beschrijving van de afhankelijkheden van deze dienst. Dus antwoord op de vraag: van welke onderdelen is deze dienst afhankelijk? Bij elk onderdeel. Daarbij is het voor onze voorbeeld-DNS-server belangrijk aan te geven dat deze machine de internetnamen ophaalt bij een andere DNS-server, die via een adsl-lijn wordt bereikt.

Het aardige is dat als je iets nieuws toevoegd aan het serverpark, dat je deze installatiebeschrijvingen en daarmee de CMDB direct kan maken. Dus ga je virtualiseren, maak dan direct van deze gelegenheid gebruik!

Vervolgens moeten we weten hoe deze onderdelen op werking getest kunnen worden. Dat wordt het volgende deel van het handboek. Bij troubleshooting is het heel handig als men via de klacht 'hij doet het niet' in stappen langs de beschreven afhankelijkheden naar de kern van het probleem kunt komen. Vandaar die afhankelijkheden. Deze worden uitgewerkt door een beschrijving te maken van het effect dat verkregen wordt als de dienst werkt. Om bij de DNS-server te blijven; als ik in Internet Explorer www.altavista.com intyp, dan kom ik bij een zekere zoekmachine op het internet uit. Wanneer dit niet gebeurt moeten er stappen ondernomen worden om tot een oplossing te komen, iets wat in het testprotocol van de dienst zit. Voor de DNS-server kan dat dus zijn: gebruik nslookup, wat als ik 'zus' in tik, wat als ik 'zo' in tik. Deze omschrijving toetst dus de werking op de dienst, maar niet van alle afhankelijkheden. Alleen de tests die binnen het apparaat op de vliering kunnen worden gedaan om vast te stellen dat de dienst werkt. Zouden we dat niet hebben, dan zoeken we naar een speld in een hooiberg bij mensen die www.altavista.com niet kunnen bereiken. Voordat we de DNS-server de schuld geven en testen, kijken we dus bij dat apparaat bij die gebruiker. Klinkt logisch? Mooi, want dat is het ook. Dat ding bij die gebruiker is namelijk ook een bouwblok en die moet ook nog beschreven worden.

Als dit een hoop werk lijkt, dan klopt dat. Voor elke applicatie moeten we tot installatie, afhankelijkheden en een testprotocol komen. Het voordeel van het 'van onder af aan beginnen' zit daarin dat het antwoord wordt gegeven op de vraag "Wat gebeurt er als ik deze stekker lostrek?", op een eenvoudige manier. Wat volgt op het hebben van de installatiehandleiding en het testprotocol is het onderhoudsdocument. Aha, daar is het handboek soldaat. Want daarin komt te staan wat er moet gebeuren om de dienst in de lucht te houden.

We zijn er dus nog niet maar geef de hoop niet op: via installatiehandleiding, testprotocol en onderhoudsdocument komen we tot het hart van de zaak: de beheeruren. Die bepalen namelijk of het aanpassen van de tactieken wat oplevert. Het stappenplan dat daarvoor gevolgd wordt is dit:

1. Behoud de strategische doelen.
2. Begin met de huidige SLA.
3. Maak een CMDB als die er nog niet is.
4. Monitor de beheeruren en deel in.
5. Bereken het TCO-effect.
6. Bepaal de te kiezen virtualisatiemethode.
7. Pas de beheertactiek aan aan het gekozen model.

We zijn nog maar bij stap 3, maar houdt moed. McDonald's had het proces ook niet zomaar in orde. Pas als we weten welke beheerhandelingen er verricht worden en hoeveel tijd die kosten, kunnen we het nut van virtualisatie bepalen. Want uiteindelijk wil je toch weten of virtualisatie de beheerlast vermindert? Dat hadden ze wel gezegd! Maar ja, over de eerste tank werd ook vanalles beweerd. Tot de volgende keer!