Direct naar content

Database Reliability Engineering – van Gatekeeper naar Accelerator

Herken je dit? Je kijkt terug op je werk en ziet dat je veel te lang bezig bent geweest met repeterende, saaie en handmatige handelingen die weinig duurzaam zijn. Bovendien nemen ze alleen maar toe als de omgeving groeit. Als Product Owner of IT-manager is dit ook moeilijk te begrijpen. Jij ziet alleen dat een team niet toekomt aan het opleveren van deliverables in de development-sprints. Dat ze verdrinken in brandjes blussen en handmatige database-changes, dat zie je niet. Hoe mooi zou de wereld eruitzien als de DBA voorover kan leunen in DevOps-teams, dezelfde taal spreekt als de software en system-engineers, teamleden in hun kracht zet en optreedt als trusted advisor. Zo’n DBA wil iedereen! In deze blog gaan we een stap verder over nuttige overtolligheid en hoe je met de shift naar Database Reliability Engineering een stabiele en veilige werkomgeving kan creëren.

Edco Wallet

Co-Founder & eigenaar
Edco Wallet - Co-Founder & eigenaar

Wat is Database Reliability Engineering?

Boek Database Reliability EngineeringEr zijn verschillende blogs, artikelen, keynote-talks en zelfs een compleet boek gewijd aan Database Reliability Engineering. Toch is het in Nederland nog niet echt geland. In de US – denk Google, Pinterest, Twitter en meer van die techreuzen – is het inmiddels een standaard rol in DevOps-teams. Om de visie achter Database Reliability Engineering te leren begrijpen is het boek van Laine Campbell en Charity Majors over Database Reliability Engineering een aanrader om te lezen. Ook de blogs van Hamish Watson (The Hybride DBA)zijn inspirerend leesvoer. Maar, wat is het nu precies? Een eenduidige en korte definitie van Database Reliability Engineering (DBRE) is niet gemakkelijk te geven, maar ik denk dat het op deze manier het best te omschrijven is:

Database Reliability Engineering creëert en faciliteert een stabiel, veilig en schaalbaar dataplatform dat integraal onderdeel is van de infrastructuur en het applicatielandschap binnen je organisatie en het is de verbindende brug tussen softwareontwikkeling en operations.

Basisprincipes

Je zou de volgende basisprincipes van DBRE kunnen definiëren:

Data-protection

Het beveiligen van de data met een feilloze back-up- en recovery-strategie en veilige operatie. Als dit goed functioneert en er is honderd procent vertrouwen, creëert dit ook een veilige werkomgeving waar fouten mogen worden gemaakt en er geen angst hoeft te zijn dat er iets kapot wordt gemaakt. Er is zo weer een nieuwe server opgespind en een back-up (zelfs geautomatiseerd) teruggezet. Geen zorgen. Dit geeft ook nog eens een versnelling aan development omdat er veel meer geëxperimenteerd kan worden.

Elemination of toil

Door efficiënt toepassen van standaardisering en automatisering worden saaie, niet uitdagende en foutgevoelige repeterende handmatige handelingen weggenomen en komt er tijd vrij voor expertise-inbreng, advies en optimalisatie. Zie hier de transitie van reactief naar proactief.

Guardrails

De DBRE zet op basis van zijn kennis en expertise een set aan richtlijnen op die software- en system-engineers helpt om veel zelf te doen zonder bang te hoeven zijn dat er iets stuk gaat. De gatekeeper wordt een meedenker.

Self-service for scale

We bouwen geen databases meer, we zetten deployment-scripts klaar, inclusief configuratie, best practices en zelfs health-check-parameters zodat elke software-engineer een database-instance van iedere smaak (MySQLPostgreSQLMongoDB) kan opspinnen. Een platform waar gebruik kan worden gemaakt van verschillende datastores, met desnoods een lifecycle van dagen of zelfs uren. Van release naar deployment.

Databases are no special snowflakes

Ook al dachten wij als traditionele DBA’s dat. Zoals de metafoor het verschil tussen huisdieren en vee. Er waren vroeger DBA’s die hun servers een naam gaven. En in nachtelijke uurtjes ze zelfs toespraken en vertroetelden. In moderne datadriven cloud platformen zijn databases als vee, een nummer, die als ze ziek zijn worden geisoleerd en zelfs vervangen.

Eleminate the barriers between software and operations

Niets is meer het probleem van een ander. We doen het met elkaar. Moderne DBA’s zijn engineers, geen beheerders, we bouwen dingen en creëren dingen. We nemen net zo makkelijk weer afscheid van gebouwde onderdelen, het doel is het uiteindelijke resultaat. Leer code, omarm de gekozen tooling, kom niet met zelfbedachte en -ontwikkelde tooltjes, zoals veel zelfstandige DBA’s, dat werkt opnieuw verzuiling in de hand.

Een blog biedt te weinig ruimte om een breed en compleet omvattend beeld te geven van Database Reliability Engineering. Om een begin te maken lichten we in deze blog ‘Elimitation of toil’ eruit, als opvolging op onze vorige blog over nuttige overtolligheid.

Waar kwamen we vandaan?

Oldskool DBA - GatekeeperDe traditionele DBA werkte het best in een silo, een zuil. Zo paste de DBA naadloos in de OTAP-straat en bij de watervalmethode die toen nog standaard gehanteerd werd bij software-ontwikkeling. Dit greep prachtig in elkaar en zo kon de DBA vooral functioneren als gatekeeper en bewaker van data en de stabiliteit van de database. Het was zijn domein en eiland en de meeste DBA’s wisten haarfijn iedereen op grote afstand te houden. We kennen allemaal de grapjes. Maar hoe kun je die databasesilo nu neerhalen en stigma’s doorbreken? Hoe de databases meer integreren in de developmentprocessen waar bijvoorbeeld handmatige databasechanges ook deployments worden?

Waar te beginnen met DBRE?

DBA - de ideale DevOpsNuttige overtolligheid creëren of ‘elimination of toil’ – het uitbannen van zwaar, saai en foutgevoelig werk – begint met:

  1. Standaardiseren
  2. Automatiseren
  3. Timemanagement

Dit zijn al drie mooie eerste stappen richting Database Reliability Engineering.

 

1. Standaardiseren

Wij doen voor een groot aantal verschillende klanten Managed Services, met 24/7 support. We hameren op standaardisering en dichtgetimmerde documentatie. Uit ervaring. Wat je niet wil is om 2 uur ‘s nachts onnodig lang zoeken naar die ene logfile of config.sys. Het gebeurt nog te vaak, en ook wij worden er nog weleens mee geconfronteerd bij nieuwe of niet-Managed Services-klanten: het eerste uur na de call besteden aan zoeken. Zoeken naar de juiste config-files, naar welke server precies actief is en welke applicatie verbindt of communiceert met welke databaseserver. Laat staan inloggen. En de documentatie? Oh ja, dat zou die vertrekkende DBA doen voordat hij wegging…

Zoveel mensen zoveel standaarden. Wat voor de een logisch is, is voor de ander misschien abracadabra. Door standaarden te hanteren is het eenvoudig en snel te doorgronden hoe de setup is ingericht en wat er al is gedaan. Zo kun je snel zien wat de afwijkingen zijn en de issue oplossen. Hetzelfde voor de toolkeuze. Kies niet per se voor de meest nieuwe en coole tool, maar kies samen een tool die de beste is voor deze taak. Ook in documenteren hebben we allemaal ons eigen dialect. Laat daarom je documentatie reviewen en updaten door een andere collega of teamlid. Laat je documentatie testen door een niet betrokken collega eens te laten inloggen en te zoeken naar X.

Wat tools betreft nog een aandachtspunt: gebruik zoveel mogelijk wat de klant en zijn developers gebruiken. Omarm deze taal, deze code of deze tool. Daarmee sla je een brug. Dat is de eerste stap naar integratie. Door zelfmeegebrachte of zelfs zelfgemaakte toolsets in te brengen (zelfstandige databaseprofessionals hebben daar nog weleens een handje van) versterk je de verzuiling en trek je een silo op. Stop daar zo snel mogelijk mee!

Dit alleen al gaat je enorm veel tijdwinst geven. Geen verloren zoek tijd meer, bijna direct op de spot waar je moet zijn. Inlezen kun je overslaan.

2. Automatiseren

Er zijn veel taken die je kunt automatiseren. Zo kun je met bijvoorbeeld Terraform of Ansible deployment scripts samenstellen die een complete HA-geclusterde DBMS-instance uitrollen, inclusief best practices, health-check-triggers en volledige back-up- en recovery-setup. En dat in enkele minuten, waar je voorheen een halve dag zat te zwoegen, met een hoge foutgevoeligheid en de angst om het morgen weer te moeten doen omdat het stuk ging. Maar denk ook aan:

  • High Availability (met automatische failover)
  • Server Discovery (weten waar je servers zijn en welke server ‘in charge’ is)
  • Observability (of monitoring, wat gebeurt er)
  • Disaster recovery (back-up- en recovery-strategie of -plan)

Door te automatiseren en dit regelmatig ook te testen, breng je repeterend werk naar de achtergrond en kun je erop vertrouwen dat bepaalde processen geautomatiseerd doorlopen, waardoor je ook hier veel tijd gaat winnen. Maar ook de drie R’s: Rust, Reinheid en Regelmaat. Hoeveel meer rust en vertrouwen creeër je als je team weet dat de backup altijd werkt? Probeer maar eens: zet je server uit en zet je back-up terug. Spannend? Maar wel erg lekker als het gewoon werkt zoals je had bedacht.

3. Timemanagement

kanban als hulpmiddel bij timemanagement en splitsing Change en IncidentmanagementWe kunnen best een beetje multitasken. Maar hier zit wel een limiet aan. Gemiddeld kun je wel zeggen dat je naast één primaire taak, twee neventaken tegelijk kunt managen. Maar dan houdt het wel op. Je gaat focus verliezen, terwijl focus key is als DBRE. Detailgerichtheid is één van de sterkste eigenschappen en toegevoegde waarde van de databaseprofessional. Dat kan verloren gaan tijdens te veel multitasken. Hoe te prioriteren, de waan van de dag beheersen en kunnen laten zien wat je aan het doen bent? Een tool als Kanban kan hier uitstekend bij helpen. Operations is niet of moeilijk planbaar. Agile en incidentmanagement is niet per se de beste match. De kunst is om Agile en ITIL in elkaar te laten schuiven. Bijvoorbeeld 16 uur reserveren voor changes. Deze zijn beschikbaar voor het kanban-bord. De overige 24 uur is voor incidentmanagement, optreden als trusted advisor en uitbreiden, het optimaliseren van automatiseringscripts, het trainen van developers op nieuwe database-engines en helpen en adviseren bij query-optimalisatie, applicatieconnectie en datamodellering.

Samenvattend

De basistaak van de DBRE is zorgen dat het platform draait en tegen een stootje kan. Maar je moet ook zeker weten dat failover werkt, dat back-ups doen wat ze moeten doen, en als er iets stuk gaat, het platform zelf een nieuwe master aanwijst en nieuwe slave opspint. Dat geeft ruimte om aan te sluiten bij andere DevOps-teams, mee te denken in query-optimalisatie, hoe de applicatie het best kan communiceren met het platform en welke database-engine het best past bij het datamodel of de applicatie. Luisteren en expertise inbrengen, vooraf. Achteraf managen is tijdrovend en werkt vertragend.

Wil je ook Database Reliability Engineering toepassen?

Zie je de voordelen en wil je ook deze manier van werken eigen maken? Wil je in je organisatie bruggen slaan en silo’s afbreken? Kom eens met ons praten, wij kunnen je adviseren en zelfs inhoudelijk helpen met de eerste stappen of zelfs je database beheer overnemen. Neem gerust vrijblijvend contact met ons op.