Dagboek van een Site Reliability Engineer

De praktijksituatie

Via mijn bedrijf HCS Company, heb ik een opdracht als SRE gekregen bij IVO Rechtspraak. IVO Rechtspraak is de organisatie die de informatievoorziening voor de Rechtspraak vernieuwt en beheert. Denk hierbij aan applicaties voor rechtbanken en ketenpartners in Nederland. Maar ook applicaties die gebruikt kunnen worden door iedere Nederlandse burger. Het is een waanzinnige gedachte dat hier zoveel spraakmakende zaken beschikbaar gesteld worden aan rechters, de advocatuur en burgers. Om de Rechtspraak digitaal toegankelijk te maken, bevordert, faciliteert en realiseert IVO Rechtspraak vernieuwing samen met de Raad voor de rechtspraak, gerechten en ketenpartners. Daarnaast zorgt IVO Rechtspraak voor kwalitatief ICT-beheer & -onderhoud zodat rechtszaken soepel en zonder storingen plaatsvinden. In deze omgeving helpt HCS Company IVO Rechtspraak bij het inrichten van de nieuwe rol als Site Reliability Engineering (SRE).

Mijn positie binnen IVO Rechtspraak als SRE

Hoe is mijn rol als SRE in deze organisatie gepositioneerd? IVO Rechtspraak is in transitie om DevOps te gaan werken. Met als doel de verschillende IT-afdelingen samen te brengen. Van ontwikkelaar tot beheerder, van tester tot IT-management. Door DevOps te werken wil men sneller deployen, hogere kwaliteit aan software en een gedeelde verantwoordelijkheid bewerkstelligen. Als SRE bevind ik me in het midden van twee ontwikkelteams die druk bezig zijn om “DevOps” te omarmen. Met als doel beide teams te helpen met het maken van software die toekomstvast, veerkrachtig en gemakkelijk te beheren blijft.

SRE: de olie in de applicatieketen

Ter beeldvorming: hoe ziet de teamverdeling en situatie er nu uit? Beide ontwikkelteams zijn samen verantwoordelijk voor het leveren van software genaamd: De Postkamer. In deze applicaties leveren wij op dit moment voor ketenpartners en griffies, de mogelijkheid om zaken in te dienen en te verstrekken. Een griffie houdt zich voornamelijk bezig met voorbereidend werk voor een zitting van een rechtbank. Zij zorgen ervoor dat alle partijen voorzien zijn van de juiste informatie. Daarnaast is er, voor functioneel beheerders die werkzaam zijn bij de rechtbanken, een beheerapplicatie gemaakt. Hierin wordt voornamelijk de toegang en rechten ingeregeld. Maar dit is nog maar het begin. Meer en meer ketenpartners zullen zich aansluiten. Daarnaast liggen er plannen klaar om formulieren van burgers ook op te nemen in De Postkamer. Een van de teams genaamd Aansluitpunt Rechtspraak (S2S) levert een aansluitpunt op voor ketenpartners en regelt het in- en uitgaande berichtenverkeer. Team Postkamer houdt zich bezig met De Postkamer applicatie zelf. Beide teams zijn afhankelijk van elkaar. Team overstijgend zijn er de Scrum Master, Product Owner, Architecten en ik, in de SRE rol.

Wat ik hier nu doe? De ervaringen die ik heb opgedaan in eerdere beheerfuncties pas ik toe binnen de teams. Denk bijvoorbeeld aan het meedenken tijdens het bouwen door goede logging en/of metrieken in te bouwen om performance en fouten te meten. Maar ook het automatiseren van de build, test en deploy processen. Ervaringen uiteenlopend van beginnend operationeel beheerder tot netwerk engineer en datacenter beheer. Door actief samen te werken met de development teams wordt de bestaande ontwikkeling- en operationele beheerkennis gecombineerd om beheersbare applicaties te creëren. Het beste van beide werelden. Beheersbaar door als team de applicatie te splitsen in microservices of door de build, test, deploy en change management weg te automatiseren. Dit allemaal zodat we ons kunnen richten op het doel: stabiele en functionele software leveren voor de rechtspraak en eindgebruikers.

Hoe ziet de teaminvulling eruit? Beide ontwikkelteams vallen onder de afdeling genaamd Digitale Toegang (in het kort DT). Binnen de afdeling bevinden zich nog meer ontwikkelteams en één beheerteam. Het beheerteam (Team Run) houdt zich bezig met operationele werkzaamheden voor een mix van de meer traditionelere applicaties. Ik rapporteer aan een van de delivery managers binnen dit beheerteam. Team Run behandelt het uitrollen en het beheer van de bestaande applicaties. Een aantal van de medewerkers van Team Run werkt net als ik samen met de overige development teams binnen de afdeling DT. Naast afdeling DT is er een afdeling Infrastructuur die zich bezighoudt met het opleveren en beheren van de infrastructuur waar software van DT op draait. De afdeling Infrastructuur is onderverdeeld in teams die op hun buurt verantwoordelijk zijn voor een gedeelte van de IT-infrastructuur.

Zorgen meerdere IT-afdelingen en teams voor meerdere interpretaties van DevOps? Is daarnaast de SRE-functie goed gepositioneerd binnen de Rechtspraak? Hoe zit dat eigenlijk met DevOps en SRE?

DevOps en SRE

Ik heb eerder grote culturele veranderingen binnen bedrijven meegemaakt. Mede door dit verleden pikte ik al gauw op dat er een culturele verandering gaande is bij de Rechtspraak. De zoektocht is nog gaande naar een geslaagde DevOps werkwijze in de praktijk. Hier en daar zijn er best practices op het gebied van DevOps toegepast, maar hoe til je dit nu als een geheel samen naar een hoger niveau en compleet doorgevoerde werkwijze? Vaak worden DevOps en SRE gezien als een proces: iets wat je gemakkelijk kunt vastgrijpen, volgen en implementeren. Maar dat is het niet. DevOps en SRE zijn een filosofie, een culturele beweging die voortkomt uit een behoefte aan betere coördinatie, samenwerking en empathie tussen ontwikkelings- en operatieteams of afdelingen. Lees ook mijn blog over DevOps & SRE.

Dit verklaart mijn huidige rol als Site Reliability Engineer en mijn positionering binnen de organisatie: geplaatst binnen de ontwikkelteams. Geplaatst vanuit het beheer Team Run dat het beu is dat er software op hun deurmat wordt gegooid. Het toeval wil dat Team Run verder is in de culturele transitie naar DevOps dan andere teams of afdelingen. Vanuit deze positie kan ik, samen met mijn collega’s een fundament voor SRE binnen de organisatie neerzetten: van monitoring en non-functionele vereisten tot automatisering en alles wat daartussen zit.

Mijn ervaringen: de valkuilen

Ik heb gemerkt dat binnen de Rechtspraak niet alle teams even ver zijn met het omarmen van DevOps best practices. Dit levert doorgaans frustraties op bij het toepassen hiervan, vooral bij team overstijgende processen.

Beide ontwikkelteams (De Postkamer en Aansluitpunt Rechtspraak) hebben sinds live gang in januari hun creaties beheert. Dit is de eerste keer dat ontwikkelaars, ontwerpers en testers hun eigen creaties ook beheren. Gaat dit zonder slag of stoot? Zeker niet. We bevinden ons immers in een omgeving waarin de best practices van DevOps nog maar gedeeltelijk beoefend worden. Het blijft zoeken. Een nieuwe aanpak in het mitst van een culturele verandering verloopt niet zonder slag of stoot. Wij bevinden ons als het ware op een DevOps eiland, in afwachting tot het vasteland met de frisse DevOps wind meegaat. Waar trekken we de grens van verantwoordelijkheid van een DevOps team? Op welke manier gaan we onze applicatieketen bezitten en beheren? Hoe gaan de andere ontwikkelteams hiermee om? Deze vragen beantwoord je alleen door het te doen en bij te sturen waar nodig.

Technische & operationele verantwoordelijkheid

Hoe zijn de verantwoordelijkheden verdeeld? Ik ben van mening dat de operationele verantwoordelijkheid van de applicatieketen zo dicht mogelijk bij de kern moet liggen. In Nederland heeft men de functionele en technische operationele werkzaamheden opgesplitst. Functioneel is men verantwoordelijk voor het ondersteunen, verbeteren, specificeren, testen en implementeren van de applicatieketen. Technisch is men verantwoordelijk voor het dagelijks beheer. Bijvoorbeeld software upgrades en het beheren van de omgeving, het platform of de middleware waar applicaties op landen. Hier kan je een grens trekken. Als ontwikkelteam wil je niet verantwoordelijk zijn voor het middleware-platform dat gebruikt wordt. Wel wil je als ontwikkelteam verantwoordelijk zijn voor de functionele aspecten van de operationele werkzaamheden. Dan zit de verantwoording op de juiste plek.

Daarnaast mogen we niet vergeten dat we ook te maken gaan hebben met bedrijfsprocessen als bijvoorbeeld verandermanagement, het geven van informatie aan de business en het verkennen van verbeterpunten in de gehele applicatieketen. Als ontwikkelteam wil je niet verantwoordelijk zijn voor overlappende bedrijfsbrede processen, contractmanagement, ketenbeheer of architectuur op een hoger niveau dan de applicatie zelf. Deze taken liggen niet dicht genoeg bij de werkzaamheden van een ontwikkelteam.

En nu?

De ontwikkelteams willen het middleware-platform als dienst te gebruiken. Eenmaal in productie houden de ontwikkelaars zich liever bezig met het leveren van nieuwe functionaliteit. Zij willen niet te maken krijgen met een berg van operationele werkzaamheden. Dit zal er deels voor zorgen dat het team gemotiveerd is om zoveel mogelijk werkzaamheden te automatiseren. Van snelle hapklare implementaties met geautomatiseerde tests in pipelines, tot het gebruik van de toepasbare logging- en metrieken. Gecombineerd met alerting om eventuele problemen snel op te kunnen pakken, te ontleden en op te lossen. Precies weten waar en wanneer de problemen zich voordoen is slechts het begin. Het volgende niveau is om eventuele problemen automatisch op te lossen met behulp van de alerts als trigger. Een voorbeeld is om databases automatisch te vergroten mochten deze vollopen.

Van eiland naar vasteland

Er is nog genoeg te doen. Ook al draaien beide ontwikkelteams in productie. Alle opgedane ervaringen binnen ontwikkelteams als de Postkamer en Aansluitpunt Rechtspraak kunnen worden gebruikt binnen andere ontwikkelteams of DevOps-eilanden en andersom. Op deze manier groeit de DevOps footprint binnen IVO Rechtspraak. Langzaam maar zeker wordt het vasteland verleid tot het gebruik van best practices die leiden tot een nauwere samenwerking. Uiteindelijk zitten we allemaal in hetzelfde schuitje. Laten we samen de koers bepalen waarmee we DevOps en SRE omarmen! Deze Schipper helpt je er graag mee 🙂