De eerste 90 dagen: stapsgewijs draaiboek voor DevOps-engineers
Hé, nieuwe medewerker. Ik heb over je gehoord!
Je hebt Kubernetes van binnen en van buiten geleerd, alles geautomatiseerd wat maar geautomatiseerd kon worden en pipelines beheerd. Je hebt CI/CD-strategieën, IaC-tools en YAML-eigenaardigheden bestudeerd alsof je leven ervan afhing.
Gefeliciteerd, je hebt de baan van DevOps-engineer gekregen!
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Ze hebben je toegang gegeven tot de cloudconsole, de buildpipeline en mogelijk—huiveringwekkend genoeg—roottoegang tot productie (geen druk).
De meeste DevOps-inwerktrajecten zijn een kwetsbare cocktail van “lees dit willekeurige document uit 2021”, “vraag het even rond” en “kom niet aan dat script, we denken dat het nog steeds iets doet.”
De rol is zelden goed gedefinieerd en de verwachtingen zijn belachelijk hoog, terwijl de documentatie schaars is. En dan zijn er nog... implementaties die aanvoelen alsof ze een eeuwenoude vloek kunnen wekken.
Hoewel het sollicitatiegesprek misschien over tools ging, draait je eerste 90 dagen volledig om mensen, processen en prioriteiten. Hier verdien je geloofwaardigheid, leg je de ongedocumenteerde zaken bloot en leg je de basis voor de infrastructuur waarop je team kan vertrouwen.
Dit draaiboek lost de infrastructuur van je team niet van de ene op de andere dag op. Maar het helpt je wel voorkomen dat je eruitziet als degene die alles stuk heeft gemaakt.
De rol: DevOps versus platform versus SRE
Laten we beginnen met de eeuwige disclaimer: “DevOps is een cultuur, geen functietitel.” Zeker, Jan—maar de functietitel bestaat nog steeds. En in de praktijk betekent dat vaak een combinatie van automatiseringsspecialist, systeemarchitect, SRE en expert op het gebied van interne hulpmiddelen.
Het is de bedoeling dat je een facilitator, een vermenigvuldiger en een kampioen van leveringssnelheid bent. Maar de waarheid is dat jij degene bent bij wie mensen aankloppen wanneer:
- De build mislukt en niemand weet waarom.
- Iemand nu meteen een nieuwe stagingomgeving nodig heeft.
- Er een compliance-audit aankomt en geheimen onversleuteld rondzwerven.
- “Dat zouden we echt moeten automatiseren” verandert in “Kun jij dat automatiseren?”
Platformengineering is DevOps met een betere naam.
SRE is DevOps met een SLA.
Hoe ze het ook noemen, jouw taak is ervoor te zorgen dat dingen kunnen opschalen, operationeel blijven en niet waardeloos zijn.
De eerste 30 dagen: kom nergens aan (voorlopig)
Tip #1: Breng de infrastructuur in kaart, niet alleen de architectuur
Leer waar je verantwoordelijk voor bent: cloudproviders, CI/CD-pipelines, containerorchestratie, geheimbeheer en incidentworkflows. Maak je eigen “infrakaart” om de stack te visualiseren. Extra punten als je links naar live dashboards of scripts toevoegt.
Tip #2: Bepaal de impactzone
Elke DevOps-organisatie heeft wel een opstelling waar je “alsjeblieft niet aan moet komen”. Breng alles in kaart wat kan exploderen als je het verkeerd aanraakt. Dit omvat:
- Deployscripts die via SSH verbinding maken met productie (waarom... waaróm?)
- Jenkins-jobs die voor het laatst in 2019 zijn aangepast
- Handmatige draaiboeken die in een pdf zijn opgeslagen
- Terraform-bestanden die nooit daadwerkelijk zijn toegepast
Vraag: Wat is ongedocumenteerd maar kritiek? Wie is ervoor verantwoordelijk? En wat is het terugdraaiplan als het misgaat?
Tip #3: Woon een implementatie bij—of nog beter: loop live met iemand mee
Je leert meer van één implementatie (en de haperingen ervan) dan van uren documentatie. Welke stappen zijn handmatig? Wat is instabiel? Wat is stammenkennis en wat is vastgelegd in code? Je bent er nog niet om geniale ideeën te spuien. Je bent er om de vuile was te verzamelen.
Je zou een codewijziging geblinddoekt van de samenvoeging tot aan productie moeten kunnen volgen. Begrijp:
- De CI/CD-pipeline (waar deze stukloopt, waar knelpunten ontstaan)
- Beheer van geheimen (gebruik hiervoor alsjeblieft geen omgevingsvariabelen)
- Goedkeuringsprocessen (implementeren we soms YOLO vanuit Slack?)
Lever geen code op. Houd alleen de infrastructuur in de gaten en schrijf dingen op.
De eerste 60 dagen: risico’s identificeren, wrijving verminderen
Tip #4: Lever een succesje van 5 minuten op
Zoek naar taken met veel wrijving en weinig risico die je kunt scripten of van een sjabloon kunt voorzien. Deze “1%”-verbeteringen maken je leven gemakkelijker en zorgen voor goodwill binnen het team. Zoek gewoon één ding dat 5 minuten te lang duurt en maak het sneller:
- Shell-omhulsel voor lokale ontwikkelconfiguratie
- Een CLI-hulpmiddel
- Een herbruikbare Terraform-module
- Script om vastgelopen testomgevingen te verwijderen
- Slack-melding voor mislukte builds
Kleine successen bouwen vertrouwen op. Vertrouwen geeft je de ruimte om grote veranderingen door te voeren.
Tip #5: Controleer de CI/CD-pipeline uiterst grondig
Bekijk de bouwtijden. Bekijk de testdekking. Bekijk wat er dagelijks stukgaat. Stel vragen zoals:
- Kunnen we tests parallel uitvoeren?
- Had dit eerder in CI voorkomen kunnen worden?
- Cachen we afhankelijkheden?
- Implementeren we na een samenvoeging… of op goed geluk?
Je bent hier niet om met vingers te wijzen. Je bent hier om de flow zonder wrijving te laten verlopen.
Tip #6: Maak dashboards die mensen daadwerkelijk gebruiken en verduidelijk het eigenaarschap
Grafana, Prometheus, Datadog—het maakt niet uit. Wat ertoe doet:
- Kan je team het succespercentage van implementaties zien?
- Betekenen meldingen iets, of zijn het gewoon ruis?
Houdt iemand de foutpercentages in de gaten voordat gebruikers klagen? Wie is eigenaar van de buildpipeline? Van de Helm-charts? Van de DNS-configuraties? De grenzen van het eigenaarschap zijn zelden duidelijk. Maak een lijst van grijze gebieden en verduidelijk ze met je team. Zo voorkom je later dat mensen met de vinger naar elkaar wijzen.
Jij bent nu verantwoordelijk voor de zichtbaarheid. Zorg dat die ertoe doet.
De eerste 90 dagen: vertrouwen opbouwen door betrouwbaarheid
Tip #7: Lever iets op dat de stabiliteit verhoogt
Dit kan bijvoorbeeld zijn:
- Bewaking toevoegen aan een systeem dat onvoldoende wordt gemonitord
- De testdekking in preproductie verbeteren
- Instabiliteit in CI-pipelines verminderen
- Een Bash-script refactoren dat met één rm -rf van een ramp verwijderd was
Het hoeft niet enorm te zijn. Het moet ervoor zorgen dat je team gemakkelijker kan ademhalen.
Tip #8: Schrijf een feedbackmemo over “DevEx”
Verzamel anonieme of informele feedback van ontwikkelaars over waar infrastructuur hen vertraagt. Presenteer wat je hebt geleerd en stel experimenten voor (bijvoorbeeld snellere lokale ontwikkeling, tijdelijke omgevingen en betere logging).
Schrijf een document met de titel “Dit heb ik geleerd en dit ga ik nu doen.” Dit is een routekaart (en misschien ook een lijstje om mee op te scheppen ;). Deel het met je manager en je team.
Maak een lijst “Dit mag ik niet vergeten”:
- De vreemde eigenaardigheden die je hebt ontdekt
- De schaduwinfrastructuur waarvan niemand toegeeft die te beheren
- De stilzwijgende kennis die alleen Carl van IT lijkt te kennen
Zet die lijst om in documenten, automatisering of tickets — of houd hem bij de hand. Zo laat je het leiderschap zien dat je systemen bouwt die niet zomaar uitvallen.
Tip #9: Kies één project met grote impact en begin het vorm te geven
Je zou inmiddels genoeg signalen moeten hebben om een belangrijk verbeterpunt te identificeren. Gebruik het laatste deel van je eerste 90 dagen om het af te bakenen, onder de aandacht te brengen en overeenstemming te bereiken.
- Verplaats onbetrouwbare taken naar GitHub Actions
- Vervang één unieke server door infrastructuur als code
- Bouw een standaardroute waarmee ontwikkelaars nieuwe diensten kunnen maken
Begin klein en bewijs je waarde. Leg alles vast.
Laatste woord
Hopelijk kun je binnen je eerste 90 dagen de boel stabiliseren, verdomme eens iets uitgerold krijgen en — het allerbelangrijkst — voorkomen dat de engineers het uitschreeuwen in het luchtledige.
Die eerste dagen draaien volledig om het opbouwen van momentum voor de lange termijn. Zoek de zwakke plekken en documenteer als een bezetene!
Niet je eerste technische rodeo?
Dit DevOps-draaiboek maakt deel uit van een groeiende reeks voor nieuwe medewerkers die impact willen maken voordat iemand hen het “eigenaarschap over legacy” in de maag splitst.
👉 Net begonnen in een rol als beveiligingsengineer? Wij helpen je op weg:
De eerste 90 dagen: editie cybersecurity
👉 Meer geïnteresseerd in codecommits dan in roottoegang? Bekijk dan:
De eerste 90 dagen: editie softwareontwikkelaar
En ja — er komen binnenkort meer rollen aan. Blijf op de hoogte, of nog beter: schrijf je in voor de nieuwsbrief, zodat je de volgende niet mist.