Beheer en Onderhoud: niet hetzelfde, beide nodig

Als het gaat om IT worden de termen beheer en onderhoud nog wel eens verward. Geen van beide is populair, er is geen ontkomen doen aan dat "beheer en onderhoud" maar wat precies het verschil is blijft onbenoemd en onduidelijk. In dit artikel wil ik een nuttig onderscheid duidelijk maken en wil ik lezers een beeld schetsen van wat onderhoud en beheer respectievelijk inhouden, wie zich wanneer waarmee bezighoudt en hoe ze passen in DevOps.

Benzine tanken of je elektrische auto opladen is geen onderhoud. Dat is (operationeel) beheer van je auto, net als je ruiten ijsvrij maken een blad verwijderen van de parkeersensor, de ruitverwarming aanzetten en het in de gaten houden van waarschuwingslampjes . De primaire functie van de auto direct beschikbaar houden - dat is beheer. Tijdens de 40.000 km beurt (of 43.621, want dat haalt hij ook wel) van je auto vindt onderhoud plaats. Schoonmaken, inspecteren, bijstellen, repareren, vervangen van onderdelen, installeren van de nieuwste versie van de systeemsoftware en het navigatiesysteem. Allemaal zaken die op middellange en langer termijn nodig of op zijn minst zeer nuttig zijn om primaire functie van de auto - het rijden - op de langere termijn ook beschikbaar en efficiënt te houden.

Voor IT systemen geldt ook dat zowel beheer als onderhoud nodig is. Met een vergelijkbare verdeling tussen dagelijkse, operationele activiteiten om systemen van 8.00 tot 17.00 of zelfs 24/7 draaiend te houden (beheer) en werkzaamheden om de langere termijn werking van systemen te kunnen waarborgen (onderhoud).

Beheer en Onderhoud van IT systemen

Beheer is de Ops in DevOps - zie onderstaande afbeelding. Onder beheer vallen monitoring van het gedrag van systemen - de waarschuwingslampjes - en het beschikbaar stellen van de actueel benodigde fysieke resources zoals storage, netwerk, geheugen en compute. Ook security-voorzieningen als bescherming tegen DDOS-aanvallen en failover naar backup-systemen in geval van systeemfalen vallen onder beheer. Vooral in cloudomgevingen is (realtime) kostenbewaking steeds vaker een aspect waar beheer voor wordt ingericht.

Beheer is in eerste instantie gericht op de functionele werking van IT-systemen (aangezien daar de businesswaarde en het bestaansrecht van het systeem aan ontleend wordt). Om de functionele werking te realiseren is ondersteunend beheer nodig van non-functionele aspecten - zoals het onderliggende applicatieplatform (applicatieserver, container, database) en de infrastructuurcomponenten (containerplatform, server, netwerk, storage).

Onderhoud valt in DevOps-termen onder Dev; het is niet gericht op de live-status van productiesystemen en valt niet onder een 24/7-regime. Dat gezegd hebbend: als onderdeel van de agile, continuous delivery en DevOps-bewegingen zijn de evolutie van functionele en non-functionele aspecten van applicaties en hun onderliggende stack steeds meer een continue proces.

Misschien nog niet 24/7 maar ook zeker niet meer de kwartaalgebaseerde cycli van niet eens zo heel lang geleden. Zelfs voor auto's zien we deze trend, bijvoorbeeld in de nachtelijke updates van het Tesla operating system die een vorm van continuous onderhoud zijn.

Het traditionele onderscheid tussen functioneel (applicatie-features waar softwareontwikkelaars mee aan de slag zijn) en non-functioneel (de technische componenten als database, applicatie server, operating systeem, netwerk en storage waar DBAs en systeembeheerders de scepter over zwaaien) vervaagt. Specialisten op verschillende lagen in de stack werken samen - binnen één team - om functionaliteit volgens non-functionele randvoorwaarden als performance, beveiliging, beschikbaarheid en kosten te realiseren. Fasen waarin ontwerp, realisatie en test plaatsvinden waarna release plaatsvindt naar de live-omgeving en het daar geldende operationele beheer zijn nog steeds te onderscheiden - hoewel deze fasen steeds sneller en steeds meer geautomatiseerd doorlopen worden.

Onderhoud en Ontwikkeling

Het klassiek gehanteerde onderscheid tussen ontwikkeling en onderhoud is niet betekenisvol. De evolutie van applicaties op functionele en non-functionele aspecten vindt plaats vanuit business-wensen en architectuur-eisen op basis van een product backlog. Projecten zijn een tijdelijke opschaling van de capaciteit van het DevOps-team teneinde een versnelling in de evolutie te bewerkstelligen - en niet een activiteit naast of zelfs buiten het DevOps team.

Binnen een DevOps-team zijn sommige activiteiten minder ingrijpend en veeleisend (zoals correcties van kleine implementatiefouten of beperkte aanpassingen in bestaande functionaliteit) en daarmee meer geschikt voor minder ervaren teamleden dan grootschalige vervangingen of complexe uitbreidingen. Dat maakt deze activiteiten - die voorheen nog wel eens aan een apart onderhouds-team werden toebedeeld - niet minder de verantwoordelijkheid van het DevOps team. Bewust omgaan met de sterke kanten en beperkingen van teamleden is een impliciete opdracht aan ieder team. Een kunstmatig onderscheid tussen ontwikkeling en onderhoud is geen goede strategie.

Kortom

Beheer en onderhoud zijn cruciaal voor IT systemen. Beheer zorgt ervoor dat IT systemen 'het doen': hun business functie leveren, in het hier en nu. Onderhoud borgt het blijvend functioneren en de noodzakelijke evolutie op langere termijn. Onderhoud voorkomt [de negatieve effecten van] slijtage. Zowel beheer (ook wel Ops) en onderhoud (ook wel Dev) hebben betrekking op de volledige applicatie-stack, van applicatie-code en -configuratie via platform tot infrastructuur.