Lideri de opinie

Va Fi Gata Baza De Date Dvs. Dacă Viteza Dezvoltării Crește Cu O Ordine De Mărime?

mm
Adaugă Unite.AI la sursele tale preferate pe Google

Uneltele asistate de inteligență artificială au crescut viteza și au redus costul producerii codului. Cu toate acestea, liderii de afaceri se întreabă de ce această eficiență nu se traduce în inovații superioare și într-un timp de livrare mai rapid. În loc să accelereze întregul ciclu de livrare, această creștere a vitezei a expus doar fragilitatea proceselor actuale de modificare a bazei de date.

În ultimul deceniu, răspunsul la “cum să mergem mai repede?” a fost să construim conducte mai bune, să investim în CI/CD și să deplasăm testarea către stânga. Aceste investiții au dat roade – codul de aplicație se deplasează cu o viteză remarcabilă în organizațiile de inginerie mature. Cu toate acestea, aceste câștiguri nu s-au resimțit uniform în întreaga stivă tehnologică. Baza de date a fost adesea tratată ca un caz special; un activ protejat care necesită un standard diferit de îngrijire, procese mai lente și supraveghere manuală. Existau motive bune pentru ca acest model să se dezvolte, deoarece bazele de date conțin datele pe care se bazează afacerile și greșelile pot fi catastrofale. În timp ce prudența a părut odată rezonabilă, costul acestei prudențe s-a schimbat. Prin creșterea presiunii asupra administratorilor de baze de date și asupra echipelor de operațiuni pentru a face modificări la baza de date la aceeași viteză cu care dezvoltatorii pot scrie cod acum, disparitatea în stivă a devenit o vulnerabilitate. Aceste echipe nu pot ține pasul, iar modificările bazei de date sunt acum ucigătoare pentru avantajul de viteză oferit de instrumentele asistate de inteligență artificială. Rezolvarea unei constrângeri – timpul necesar pentru a scrie cod – a evidențiat doar următoarea blocaj în proces. Acesta este un sistem de gândire adus la viață, iar frecarea rezultată devine din ce în ce mai dureroasă pentru întreprindere.

Viteza și controlul nu sunt opuse. Dar modul în care majoritatea organizațiilor guvernează modificarea bazei de date îi tratează ca și cum ar fi.

Modelul tradițional de guvernare a bazei de date a fost proiectat pentru o lume de lansări trimestriale. Cereri de modificare, comitete de aprobare, cicluri de revizuire manuală, planuri de rollback scrise înainte de implementări care aveau loc de patru ori pe an. Niciuna dintre acestea nu este în mod inerent greșită. A fost un management al riscului care a crescut pentru a se potrivi cu timpul disponibil între implementări. Problema este că cadența de implementare s-a schimbat, iar pentru majoritatea organizațiilor, abordarea guvernării nu a ținut pasul. Echipele sunt așteptate să livreze continuu, dar încă direcționează modificările bazei de date prin procese create pentru o altă epocă. Rezultatul nu este siguranță. Rezultatul este frecare, soluții alternative și o clasă tot mai mare de “mici” modificări ale bazei de date care ocolesc guvernarea complet, deoarece procesul formal este prea lent pentru a fi practic.

Acolo este unde trăiește riscul real.

Când guvernarea este prea lentă pentru a fi utilizată, oamenii încetează să o utilizeze. Modificările schemei sunt aplicate direct în producție. Corecțiile sunt lansate fără controlul versiunilor, iar cu intenția de a le trece corect cu lansarea formală următoare, dar acest lucru nu se întâmplă, deoarece oamenii sunt ocupați. Pașii manuali care ar fi trebuit să fie rețeaua de siguranță devin lucrul pe care oamenii îl ocolesc atunci când sunt sub presiune. Și presiunea, în livrarea de software, este starea implicită.

Răspunsul nu este să încetiniți conducta. Este să mutați guvernarea în interiorul ei.

Organizațiile care au rezolvat această problemă nu au făcut-o relaxând standardele. Au făcut munca mai grea de a face guvernarea suficient de rapidă pentru a fi calea cu rezistență minimă. Modificări ale schemei controlate de versiune, detectare automată a derapajului, verificări de politică deterministice încorporate în conducta CI/CD, în loc să fie aplicate ca o poartă la sfârșit. În timp ce instrumentele conduse de inteligență artificială sunt probabilistice – oferind sugestii bazate pe modele – guvernarea trebuie să rămână deterministă pentru a fi eficientă. Prin utilizarea unor verificări previzibile și reproductibile, vă asigurați că fiecare modificare este auditabilă și îndeplinește standardele de siguranță înainte de a ajunge vreodată în producție. Aprobarea încă are loc. Urma auditului încă există. Dar are loc în același flux cu totul, în loc de a fi un proces separat, mai lent, care stă în afara lui.

Acest lucru contează dintr-un motiv dincolo de productivitatea dezvoltatorului. Cerințele de conformitate nu devin mai ușoare. Combinarea GDPR, DORA (Legea operațională de reziliență digitală a UE) și a unei game tot mai largi de reglementări specifice sectoarelor înseamnă că guvernarea bazei de date este din ce în ce mai mult o chestiune legală și de reglementare, nu doar una operațională. Organizațiile care nu pot demonstra o istorie tracabilă și auditabilă a modificărilor bazei de date sunt expuse în moduri care devin materiale. Argumentul pentru încorporarea guvernării în conductă nu este doar că face livrarea mai rapidă. Este ceea ce face conformitatea tracabilă la scară.

Inteligența artificială este o urgență care se agravează.

Valul actual de dezvoltare asistată de inteligență artificială face această problemă mai acută, nu mai puțin gravă. Când dezvoltatorii pot genera și itera codul de aplicație cu o ordine de mărime mai rapid decât înainte, baza de date devine un blocaj mai evident în raport cu tot ceea ce o înconjoară. Dar există un efect de ordinul doi care este mai puțin discutat. Instrumentele cu inteligență artificială sunt foarte bune la generarea logicii aplicației. Sunt mai puțin bune la înțelegerea consecințelor pe termen lung ale modificărilor schemei într-o bază de date de producție complexă și live. Combinația dintre viteză de dezvoltare a aplicației și sugestii de modificare a schemei generate de inteligență artificială, fără o guvernare matură, este exact tipul de presiune care produce incidente. Viteza fără garduri structurale creează condițiile pentru ca greșelile să se întâmple mai repede.

Organizațiile care vor naviga bine prin aceasta sunt cele care tratează guvernarea bazei de date ca o preocupare de inginerie de primă clasă, nu ca o grijă de conformitate ulterioară. Acest lucru înseamnă că controlul versiunii pentru schema bazei de date este o opțiune implicită negociabilă, iar testarea automată gestionează verificările rutiniere, astfel încât supravegherea manuală să se poată concentra asupra modificărilor cu risc ridicat și cu judecată ridicată, în loc să devină un blocaj într-o etapă târzie. În cele din urmă, înseamnă detectarea derapajului care identifică divergența înainte de a provoca un incident.

Majoritatea întreprinderilor fac ca acest lucru să fie mai greu decât ar trebui.

Există o realitate care se combină alături de majoritatea acestor observații. Majoritatea întreprinderilor de baze de date nu sunt noi. Ele reprezintă decenii de modificări ale schemei acumulate, care rulează pe multiple platforme de sistem de gestionare a bazei de date, unele în local și altele în cloud, cu diferite grade de documentație și cunoașterea tribală răspândită în echipe care s-au schimbat de multe ori. Conversația de modernizare presupune adesea un punct de plecare curat pe care majoritatea organizațiilor nu îl au. Acolo este unde provocarea este de fapt cea mai acută și adesea împiedică progresul. Indiferent dacă scopul este de a sprijini inovația, de a curăța și de a migra date pentru inteligență artificială sau de a îmbunătăți reziliența operațională; se întoarce la aceleași lucruri. Întrebarea nu este cum să construim o practică perfectă de DevOps pentru baze de date pe un sistem nou. Întrebarea este cum să introducem o guvernare semnificativă pe o moștenire complexă, fără a opri afacerea în timp ce o facem.

Guvernarea încorporată în conductă, treptată, este singurul răspuns practic la această întrebare. Nu trebuie să replasați întreaga moștenire înainte de a putea îmbunătăți practicile dvs. de gestionare a modificărilor. Unelte moderne, cum ar fi Redgate Flyway, există pentru a allevia baza de date ca blocaj și pentru a începe cu modificările care se fac astăzi, în conductele care există deja, și pentru a construi de acolo.

Organizațiile care vor câștiga pe creștere în următorii cinci ani nu vor fi cele care au cele mai curate moșteniri. Vor fi cele care au descoperit cum să facă schimbarea de încredere, la viteza pe care o cere afacerea, pe moștenirea pe care o au de fapt.

Acesta este problema care merită rezolvată. Și este rezolvabilă.

Graham este Directorul Tehnic al companiei Redgate Software, unde conduce echipele din spatele unor instrumente de Database DevOps de top din industrie. Înainte de a lucra la Redgate, experiența lui Graham include mai multe decenii de proiecte complexe și supraveghere a conducerii la numeroase companii, printre care Elsevier, IBM, Sun, BEA și Oracle. Graham este, de asemenea, un yachtsman care a navigat în jurul lumii, participând la cursele de yachting Clipper Round the World în 2007-08 și 2013.