Onko tietokantasi valmis, jos kehityksen nopeus kasvaa kymmenkertaiseksi?

Tekoälyavusteiset työkalut ovat lisänneet koodin tuottamisen nopeutta ja vähentäneet sen kustannuksia. Liiketoimintajohtajat kuitenkin kyselevät, miksi tämä tehokkuus ei johtaa parempaan innovaatioon ja nopeampaan markkinoille saapumiseen. Sen sijaan, että koko toimitusketjun nopeuttaisi, tämä nopeuden lisäys on paljastanut olemassa olevien tietokantamuutosten prosessien haavoittuvuuden.

Viimeisen kymmenen vuoden ajan vastaus kysymykseen “miten liikumme nopeammin?” on ollut rakentaa parempia putkia, investoida CI/CD:hen ja siirtää testausta vasemmalle. Nämä investoinnit ovat tuottaneet tuloksia – sovelluskoodi liikkuu hämmästyttävän nopeasti kokeneissa insinööriorganisaatioissa. Näiden edistysten vaikutus ei kuitenkaan ole tasoittunut koko teknologiapinon yli. Tietokantaa on usein kohdeltu erityistapauksena; suojattuna omaisuutena, joka vaatii erityistä huolenpitoa, hitaampia prosesseja ja manuaalista valvontaa. Tähän kehitykseen oli hyviä syitä, koska tietokannat sisältävät liiketoiminnan pyörittämiseen tarvittavia tietoja ja virheet voivat olla katastrofaalisia. Vaikka varovaisuus tuntui aiemmin kohtuulliselta, varovaisuuden kustannukset ovat muuttuneet. Kun DBA:t ja operatiiviset tiimit joutuvat tekemään tietokantamuutoksia samalla nopeudella kuin kehittäjät voivat nyt kirjoittaa koodia, pinon epätasapaino on muuttunut vastuulliseksi. Nämä tiimit eivät voi pitää tahtia, ja tietokantamuutokset tappavat nyt Al-avusteisen työkalun antaman nopeuden edun. Yhden rajoituksen – koodin kirjoittamiseen kuluvan ajan – ratkaiseminen on vain korostanut seuraavaa pullonkaulaa prosessissa. Tämä on järjestelmällinen ajattelu käytännössä, ja tuloksena oleva kitka on yhä tuskaisempi suuryrityksille.

Nopeus ja hallinta eivät ole vastakohtia. Mutta tapa, jolla useimmat organisaatiot hallinnoivat tietokantamuutoksia, kohdella niitä kuin ne olisivat.

Perinteinen tietokantahallinnan malli suunniteltiin maailmaa varten, jossa julkaistaan neljännesvuosittain. Muutospyyntöjä, hyväksyntäkomiteoita, manuaalisia tarkastuskiertoja, peruutussuunnitelmia, jotka laaditaan ennen kuin neljä kertaa vuodessa tapahtuvia julkaisuja. Mitään näistä ei ole itsessään väärin. Se oli riskienhallintaa, joka kasvoi ajan mukaan, joka oli saatavilla julkaisujen välillä. Ongelma on, että julkaisutahti on muuttunut, ja useimmissa organisaatioissa hallintolähestymistapa ei ole pysynyt mukana. Tiimit odotetaan toimittavan jatkuvasti, mutta heidän on silti ohjattava tietokantamuutokset prosesseja, jotka on suunniteltu toiselle ajalle. Tuloksena ei ole turvallisuus. Tuloksena on kitka, kierrotiet ja kasvava luokka “pieniä” tietokantamuutoksia, jotka ohittavat hallinnan kokonaan, koska virallinen prosessi on liian hidas ollakseen käytännöllinen.

Siihen on todellinen riski.

Kun hallinta on liian hidas ollakseen käytettävissä, ihmiset lopettavat sen käytön. Skeemamuutokset sovelletaan suoraan tuotantoon. Hotfixit lähetetään ilman versionhallintaa, ja aikomuksena on ohjata ne virallisen julkaisun kautta seuraavassa virallisessa julkaisussa, mutta sitä ei tapahdu, koska ihmiset ovat kiireisiä. Manuaaliset vaiheet, jotka olivat tarkoitettu turvallisuuden verkkona, muuttuvat asioiksi, joita ihmiset kiertävät, kun he ovat painostettuja. Ja painostus, ohjelmistotoimituksessa, on oletusarvo.

Vastaus ei ole hidastaa putkea. Se on siirtää hallinta sen sisään.

Organisaatiot, jotka ovat ratkaisseet tämän ongelman, eivät ole tehneet sitä rentouttamalla standardejaan. He ovat tehneet vaikeampaa työtä saadakseen hallinnan tarpeeksi nopeaksi ollakseen vastuullisimman reitin. Versiohallinnassa olevat skeemamuutokset, automaattinen drift-havainnointi, deterministiset policy-tarkastukset upotettuna CI/CD-putkeen sen sijaan, että ne olisivat portti putken lopussa. Vaikka Al-ohjatut työkalut ovat todennäköisyyksiä – tarjoavat ehdotuksia perustuen malleihin – hallinta on pysyttävä deterministisenä ollakseen tehokas. Käyttämällä ennustettavia ja toistettavia tarkastuksia, varmistat, että jokainen muutos on auditoitavissa ja täyttää turvallisuusvaatimukset ennen kuin se edes saapuu tuotantoon. Hyväksyntä tapahtuu edelleen. Audit-reitti on edelleen olemassa. Mutta se tapahtuu samassa virrassa kuin kaikki muu, sen sijaan, että se olisi erillinen, hitaampi prosessi, joka sijaitsee sen ulkopuolella.

Tämä on tärkeää syystä, joka on laajempi kuin kehittäjien tuottavuus. Noudattamisvaatimukset eivät ole kevenemässä. Yhdistelmä GDPR:stä, DORA:sta (EU:n digitaalinen toiminnallinen palautumiskyky) ja kasvavasta joukosta toimialakohtaisia sääntelyjä tarkoittaa, että tietokantahallinta on yhä enemmän oikeudellinen ja sääntelykysymys, eikä ainoastaan operatiivinen. Organisaatiot, jotka eivät voi osoittaa jäljitettävää, auditoitavissa olevaa historiaa tietokantamuutoksista, ovat alttiina tapahtumille, jotka ovat muuttuneet aineellisiksi. Argumentti hallinnan upottamiseksi putkeen ei ole vain se, että se tekee toimituksen nopeammaksi. Se on se, mikä tekee noudattamisen jäljitettäväksi suurten mittakaavojen mukaan.

Teckoäly on lisäämässä kiirettä.

Nykyinen Al-avusteinen kehitysaalto tekee tästä ongelmaa vielä äkkiämpää, eikä vähemmän. Kun kehittäjät voivat luoda ja iteroida sovelluslogiikkaa kymmenkertaisella nopeudella kuin ennen, tietokanta muuttuu selvemmäksi pullonkaulaksi suhteessa muihin. Mutta on toissijainen vaikutus, josta ei yleisesti keskustella. Al-työkalut ovat erittäin hyviä sovelluslogiikan luomisessa. Ne eivät ole yhtä hyviä ymmärtämään skeemamuutosten pitkän aikavälin seurauksia monimutkaisessa, live-tuotantotietokannassa. Al-avusteisen kehityksen nopeuden ja Al-luotujen skeemaehdotusten yhdistelmä kypsentää virheitä. Nopeus ilman rakenteellisia suojia luo virheiden edellytykset.

Organisaatiot, jotka selviävät tästä hyvin, ovat niitä, jotka kohdeltavat tietokantahallintaa ensisijaisena insinöörintekona eikä noudattamisen jälkeen. Se tarkoittaa, että tietokantaskeeman versionhallinta on ehdoton oletusarvo, ja automaattinen testaus hoitaa routinemäiset tarkastukset, jotta manuaalinen valvonta voi keskittyä korkean riskin, korkean tuomion muutoksiin sen sijaan, että se muuttuu myöhäisemmäksi pullonkaulaksi. Lopulta se tarkoittaa drift-havainnointia, joka tunnistaa poikkeamat ennen kuin ne aiheuttavat ongelman.

Useimmat suuryritysten kiinteistöt tekevät tästä vaikeampaa kuin tarvitsee.

On yhdistetty todellisuus, joka on rinnakkain useimpien näiden havaintojen kanssa. Useimmat suuryritysten tietokantakiinteistöt eivät ole vihreitä kenttiä. Ne edustavat vuosikymmenten kuluessa kertyneitä skeemamuutoksia, jotka suoritetaan useilla DBMS-alustoilla, osa paikallisesti ja osa pilvessä, vaihtelevilla dokumentaatiotasolla ja heimoperinteellä, jota on jaettu useiden kertojen vaihtuneiden tiimien kesken. Modernisointikeskustelu olettaa usein puhdas lähtökohta, jota useimmat organisaatiot eivät ole. Tässä haaste on todella äkkiämpää ja usein estää edistymistä. Olipa kyse innovaatiosta, tietojen puhdistamisesta ja siirtämisestä Al:lle tai toiminnallisen palautumiskyvyn parantamisesta; se palaa samaan asiaan. Kysymys ei ole siinä, miten rakentaa täydellinen tietokantakehityksen käytäntö uudelle järjestelmälle. Kysymys on, miten esittää mielekästä hallintaa monimutkaiselle, perinteiselle kiinteistölle ilman liiketoiminnan pysäyttämistä.

Askelpien, putken sisään upotettu hallinta on ainoa käytännöllinen vastaus tähän kysymykseen. Et tarvitse uudelleenplatformata koko kiinteistöä, ennen kuin voit parantaa muutoksenhallintatapoja. Nykyaikaiset työkalut, kuten Redgate Flyway, ovat olemassa helpottamaan tietokannan pullonkaulaa ja aloittamaan muutoksilla, jotka tehdään tänään, putkissa, jotka jo ovat olemassa, ja rakentamaan siitä eteenpäin.

Organisaatiot, jotka voittavat kasvussa seuraavien viiden vuoden aikana, eivät ole niitä, joilla on siistein kiinteistöt. Ne ovat niitä, jotka ovat keksineet, miten tehdä muutoksesta luotettavaa, liiketoiminnan vaatimalla tahdilla, kiinteistöllä, jota he todella omistavat.

Se on ongelma, jonka arvoista on ratkaista. Ja se on ratkaistavissa.