Vil din database-estate være klar, hvis udviklingshastigheden øges med en størrelsesorden?

Al-assisterede værktøjer har øget hastigheden og reduceret omkostningerne ved at producere kode. Alligevel stiller erhvervsledere spørgsmål om, hvorfor denne effektivitet ikke oversætter sig til overlegen innovation og hurtigere markedsføring. I stedet for at accelerere hele leveringscyklussen har denne hastighedsstigning blot afsløret sårbarheden i eksisterende databaseændringsprocesser.

I det sidste årti har svaret på “hvordan flytter vi os hurtigere?” været at bygge bedre pipelines, investere i CI/CD og flytte venstre på testing. Disse investeringer har givet pote – applikationskoden flytter sig med en imponerende hast i modne tekniske organisationer. Imidlertid har disse fremskridt ikke været følt ens på tværs af teknologistakken. Databasen er ofte blevet behandlet som en særlig sag; en beskyttet aktiv, der kræver en anden standard for pleje, langsommere processer og manuel tilsyn. Der var gode grunde til, at denne mønster udviklede sig, da databaser indeholder de data, som virksomheden kører på, og fejl kan være katastrofale. Mens forsigtighed engang føltes rimelig, har omkostningerne ved denne forsigtighed ændret sig. Ved at øge presset på DBA’er og operationshold for at foretage ændringer i databasen i samme hast, som udviklere nu kan skrive kode, er forskellen i stakken blevet en byrde. Disse hold kan ikke følge med, og databaseændringer er nu ved at dræbe hastighedsfordelen, som Al-assisterede værktøjer giver. At løse ét problem – den tid, det tager at skrive kode – har blot fremhævet den næste flaskehals i processen. Dette er systemtænkning bragt til live, og den resulterende friktion bliver mere og mere smertefuld for virksomheden.

Hastighed og kontrol er ikke modsætninger. Men den måde, hvorpå de fleste organisationer regulerer databaseændringer, behandler dem, som om de var.

Den traditionelle model for database-regulering var designed til en verden med kvartalsvise udgivelser. Ændringsanmodninger, godkendelsesudvalg, manuelle gennemgangscykler, rollback-planer skrevet før udgivelser, der skete fire gange om året. Ingen af dette er i sig selv forkert. Det var en risikostyring, der voksede til at passe til den tid, der var til rådighed mellem udgivelserne. Problemet er, at udgivelseshastigheden er ændret, og for de fleste organisationer er reguleringstilgangen ikke fulgt med. Hold forventes at levere kontinuerligt, men de sender stadig databaseændringer gennem processer, der er bygget til en anden æra. Resultatet er ikke sikkerhed. Resultatet er friktion, workaround’er og en voksende klasse af “små” databaseændringer, der omgår regulering helt, fordi den formelle proces er for langsom til at være praktisk.

Det er, hvor den virkelige risiko bor.

Når regulering er for langsom til at blive brugt, stopper folk med at bruge den. Skemaændringer anvendes direkte i produktion. Hotfix’er kommer ud uden versionsstyring, og med den gode hensigt at sende dem gennem med den næste formelle udgivelse, men det sker ikke, fordi folk er beskæftiget. De manuelle trin, der skulle være sikkerhedsnettet, bliver det, som folk omgår, når de er under pres. Og pres, i software-levering, er standardtilstanden.

Svaret er ikke at slowe pipelinen ned. Det er at flytte regulering ind i den.

De organisationer, der har løst dette problem, har ikke gjort det ved at afslække deres standarder. De har gjort det hårdere arbejde med at gøre regulering hurtig nok til at være den letteste vej. Versionsstyrede skemaændringer, automatiseret driftsdetektion, deterministiske politikkontroller indbygget i CI/CD-pipelinen i stedet for anvendt som en port før udgivelsen. Mens Al-drevne værktøjer er probabilistiske – og giver forslag baseret på mønstre – skal regulering forblive deterministisk for at være effektiv. Ved at bruge forudsigelige og gentagne kontroller sikrer du, at hver ændring er auditerbar og opfylder sikkerhedsstandarder, før den nogensinde når produktion. Godkendelsen sker stadig. Audit-sporingen findes stadig. Men det sker i samme flow som alt andet, i stedet for som en separat, langsommere proces, der sidder udenfor.

Dette er vigtigt af en grund, der går ud over udviklerproduktivitet. Overholdelseskravene bliver ikke lettere. Kombinationen af GDPR, DORA (EU’s digitale operationelle résiliensakt) og en voksende række sektorspecifikke reguleringer betyder, at database-regulering er en juridisk og regulatorisk spørgsmål, ikke kun en operativ. Organisationer, der ikke kan demonstrere en sporbar, auditerbar historie af databaseændringer, er udsat på måder, der bliver materiel. Argumentet for at indbygge regulering i pipelinen er ikke kun, at det gør leveringen hurtigere. Det er, hvad der gør overholdelse sporbar i stor målestok.

AI er med til at øge presset.

Den nuværende bølge af Al-assisteret udvikling gør dette problem mere akut, ikke mindre. Når udviklere kan generere og iterere på applikationskode en størrelsesorden hurtigere end før, bliver databasen en mere åbenlys flaskehals i forhold til alt andet. Men der er en andenordens effekt, der er mindre diskuteret. Al-værktøjer er meget gode til at generere applikationslogik. De er mindre gode til at forstå de langsigtede konsekvenser af skemaændringer i en kompleks, live-produktionsdatabase. Kombinationen af hurtigere applikationsudviklingshastighed og Al-genererede skema-forslag uden moden regulering er præcis den type pres, der skaber uheld. Hastighed uden strukturering skaber betingelserne for fejl til at ske hurtigere.

De organisationer, der vil navigere dette godt, er dem, der behandler database-regulering som en førsteklasses ingeniørspørgsmål i stedet for en overholdelseseftertanke. Det betyder, at versionsstyring af database-skema er en ikke-forhandlingsbar standard, og automatiseret testning håndterer rutinekontroller, så manuel tilsyn kan fokusere på højrisikable, højdomsætningsændringer i stedet for at blive en senere flaskehals. Endelig betyder det, at driftsdetektion, der identificerer afvigelse, før det skaber et uheld.

De fleste virksomheds-estater gør dette sværere, end det burde være.

Der er en sammenfaldende realitet, der sidder sammen med de fleste af disse observationer. De fleste virksomhedsdatabase-estater er ikke grønne. De repræsenterer årtiers akkumulerede skemaændringer, der kører på multiple DBMS-platforme, nogle on-premises og nogle i skyen, med varierende grader af dokumentation og stamme-kendskab, der er spredt over hold, der har skiftet mange gange. Moderniseringskonversationen antager ofte en ren start, som de fleste organisationer ikke har. Det er her, udfordringen faktisk er mest akut og ofte forhindrer fremgang. Uanset om målet er at støtte innovation, rense og migrere data til Al eller forbedre operationel résiliens; det kommer tilbage til de samme ting. Spørgsmålet er ikke, hvordan man bygger en perfekt database DevOps-praksis på et nyt system. Spørgsmålet er, hvordan man indfører meningsfuld regulering på en kompleks, arv-estate uden at stoppe forretningen, mens man gør det.

Incrementel, pipeline-indbygget regulering er det eneste praktiske svar på dette spørgsmål. Du behøver ikke at gen-platforme hele estate, før du kan forbedre dine ændringspraksis. Moderne værktøjer som Redgate Flyway findes for at lette databasen som flaskehalsen og starte med de ændringer, der sker i dag, i de pipelines, der allerede findes, og bygge fra der.

De organisationer, der vil vinde på vækst i de næste fem år, vil ikke være dem, der har de reneste estater. De vil være dem, der har fundet ud af, hvordan man kan gøre ændring til at være troværdig, i den hastighed, forretningen kræver, på tværs af estate, de faktisk har.

Det er problemet, der er værd at løse. Og det er løseligt.