Maak opruimen onderdeel van reguliere proces

In een it-omgeving komt er doorgaans alleen maar apparatuur bij. Het opruimen en verwijderen van oude systemen daarentegen wordt veelal veronachtzaamd. Dat is een gemiste kans; we zouden geld en doorlooptijd kunnen besparen als we voortdurend blijven opschonen en opruimen.

In een it-omgeving hebben we het vrij druk. Met betrekking tot het operationele proces gaat de meeste tijd zitten in het uitzoeken en oplossen van incidenten, op het spoor komen van structurele problemen en het uiteindelijk doorvoeren van wijzigingen. Daarnaast is er een voortdurende druk vanuit 'de business' om middels projecten nieuwe functionaliteit toe te voegen en om de bestaande capaciteit uit te breiden.

Een logische maar essentiële constatering is dat de klant er alleen maar last van heeft als er iets niet of minder goed werkt. Dit geldt voor de bestaande it-infrastructuur maar helemaal voor nieuwe bij te plaatsen systemen waardoor uiteindelijk een nieuwe applicatie kan gaan draaien; zolang het nieuwe er nog niet is kan het niet in gebruik worden genomen.

Anders gezegd: er is een groot belang voor de klant en een grote druk op de it-organisatie om apparatuur te op te schalen, uit te breiden en bij te plaatsen. Vanuit de it-organisatie zelf komt daar nog bij de extra hard- en software om de bestaande infrastructuur redundant te maken en om de werking nog beter te kunnen monitoren en beheren. De trend naar meer apparatuur is hardnekkig; het wordt gesteund en gestuwd vanuit de vraagkant.

Grenzen

De trend naar groter en meer loopt als eerste tegen grenzen aan op die plaatsen waar de schaarse ruimte, in de ruimste zin van het woord, moet worden gedeeld met andere partijen. In het datacentrum, op de computervloer moeten de systemen fysiek worden geplaatst. Hier komt veel bij kijken. Voor elk te installeren component moet worden bepaald wat de impact is op: rackspace, stroomvoorziening, warmteafgifte/koeling, beschikbaarheid van Vlan's en een bijbehorende switchpoort, vrije aansluitingen op een patchpaneel, vrije aansluiting op een KVM switch. Maar niet alleen in het fysieke zijn er capaciteitsgrenzen: op een hogere abstractie laag raken (publieke) ip-adressen op of kan je bijvoorbeeld geen nieuwe vlan's meer aanmaken.

Het komt wel eens voor dat er geen centrale regie is over de allocatie van bovengenoemde datacentrumfaciliteiten, zodat de partij die achteraan in de rij komt onverwacht te maken krijgt met een tekort aan een of meerdere zaken (rackspace, stroom, et cetera). De koektrommel wordt door iedereen leeggegeten en degene die het laatste koekje pakt moet de hond uitlaten of op zijn minst een nieuw pak koekjes bestellen. De uitbreiding van datacentrumfaciliteiten die dan nodig zijn leiden tot een onvoorziene vertraging en dus langere doorlooptijd van het betreffende project en alle projecten die daarna komen.

Maar ook in het geval er wel een centrale regie is, loopt de capaciteitsuitbreiding vaak achter de feiten aan en is het tempo van de fysieke uitrol van projecten moeilijk bij te houden. Daarbij komt ook nog eens dat de bestelling en uitbreiding van stroomvoorziening, racks en netwerkswitches een langere doorlooptijd kent dan de uitgifte van deze faciliteiten en het erop aansluiten. Een extra complicerende en vertragende factor in deze is de discussie over financiële doorbelasting en de angst voor overcapaciteit; doorgaans zal men pas opnieuw investeren in capaciteitsuitbreiding op zaal zodra er zicht is op de projecten die op de uitrolplanning staan.

De nieuwe systemen zijn geïnstalleerd op zaal, geconfigureerd, getest, geaccepteerd en opgeleverd…En toen werd het stil. Afgezien van de periodieke updates van (operating)software wordt het stil in en rondom de machine. Hij zoemt dag en nacht door en volgt braaf het ritme van processing, backups, syslog en SNMP-meldingen enzovoort. Na een jaar of vijf krijgt het apparaat steeds minder te doen omdat de oorspronkelijke gebruikers geleidelijk zijn gemigreerd naar diensten en processen die elders draaien, tot het moment dat de server werkloos in het rack blijft zoemen.

Geen hinder

In tegenstelling tot wat we zagen in de beginfase is er geen enkele partij die direct hinder ondervindt van de aanwezigheid en het aan blijven staan van het inmiddels verouderde component. Niemand ondervindt er hinder van als er iets wel werkt, ook al is het overbodig. De eindgebruikers zijn al lang weg en hebben niets meer van doen met het oorspronkelijke apparaat. Daar komt nog bij dat de beheerorganisatie uit angst voor verstoring en incidenten het systeem niet durft uit te zetten. 'Laat maar draaien; niet aankomen; niet naar kijken..kan er ook niets misgaan.'

De jaren verstrijken en er ontstaan steeds meer 'legacy'-kasten, waarvan niemand meer weet van wie ze zijn en welke applicaties erop draaien. Intussen consumeren die machines dag en nacht stroom, nemen ze ruimte in (vloeroppervlakte en rackspace), doen ze aanspraak koeling, nemen ze switchpoorten en ip-adressen in beslag en hangen er abonnementen aan van isdn (beheer)-lijnen, adsl-connecties, X25- en seriële-verbindingen enzovoort. Nog steeds heeft niemand er last van; er komt toch altijd maar weer capaciteit bij voor nieuwe projecten.

Opruimen

Hoogste tijd om oude spullen op te gaan ruimen. Niet incidenteel tussen Kerst en Oud & Nieuw maar opruimen als onderdeel van het dagelijks proces. Wees bij aanvang van een nieuw stuk infrastructuur je ervan bewust dat er ooit een tijd komt dat het weer moet worden uitgefaseerd en opgeruimd. Maak dit inzichtelijk door met de klant of eigenaar een datum vast te stellen waarop de spullen weer worden bekeken en waarop wordt bepaald of het nog kan blijven bestaan of niet. Houd in de tussenliggende jaren een lijst bij met eigenaren of diensteigenaren van de componenten. Houd voor ogen dat je op ieder gewenst moment moet kunnen achterhalen wie de klant/eigenaar/gebruiker is van een component (dat zou je zonder meer al moeten weten omdat je ook wel eens wijzigingen op een apparaat moet uitvoeren). Leg een directe relatie tussen de afzonderlijke faciliteiten waarvan een component gebruik maakt en het doorbelastingsbedrag; zorg dat de klant ook een eigen (financieel) belang heeft om uiteindelijk zijn spullen weer weg te halen.

Een andere situatie is er indien de eindklant/eindgebruiker geen eigenaar van de hardware is maar enkel een dienst afneemt. Maar ook hierbij geldt dat je bij oplevering en tussentijds afspraken moet maken voor de uiteindelijke uitfasering of vervanging. Een aspect hierbij is de 'end-of-support'/'' end-of-life' die de leverancier van het component vaststelt. Probeer bij het begin al afspraken met de klant/eindgebruiker te maken over zijn medewerking en de mogelijkheid tot een zekere downtijd als het moment aanbreekt dat een systeem moet worden vervangen door een nieuwe versie. Het mag niet zo zijn dat de klant aan het einde van de levenscyclus de verbaasde vraag gaat stellen 'Waarom? het draait toch goed zo?'

Hoe heerlijk zal het zijn om oude systemen uit te kunnen zetten, uit het rack te schroeven, kabels verwijderen, switchpoorten vrij te maken en ip-adressen weer vrij te kunnen geven. Je zal versteld staan hoeveel ruimte dat zal creëren. De tijd die je aan het begin en tussentijds investeert in bewustwording van de eindfase en het nauwgezet bijhouden van informatie zal zich in veelvoud terugbetalen als je snel en regelmatig oude systemen kan uitzetten en verwijderen.

Een grote besparing in geld; je hoeft minder vaak capaciteit uit te breiden en je bespaart op stroomgebruik. Maar ook een grote besparing in doorlooptijd; vrijgekomen datacentrum capaciteit, in al zijn verschijningsvormen, is direct inzetbaar voor systemen van nieuwe projecten die aan de poort staan te trappelen om naar binnen te worden gereden.