Bude vaše databázová nemovitost připravena, pokud se rychlost vývoje zvýší o řád?

Nástroje s podporou umělé inteligence zvýšily rychlost a snížily náklady na produkci kódu. Přesto se lídři podniků ptají, proč tato efektivita nepřekládá do lepší inovace a rychlejšího času na trh. Místo urychlení celé dodací lhůty tato vlna rychlosti pouze odhalila křehkost stávajících procesů změny databáze.

Za posledních deset let byla odpověď na otázku “jak se můžeme pohybovat rychleji?” postavena na lepší pipeline, investice do CI/CD a posunutí doleva při testování. Tyto investice se vyplatily – kód aplikace se pohybuje pozoruhodnou rychlostí v zavedených inženýrských organizacích. Nicméně tyto zisky nebyly cítit rovnoměrně napříč technologickým zásobníkem. Databáze byla často považována za zvláštní případ; chráněný aktivum vyžadující jiný standard péče, pomalejší procesy a manuální dohled. Existovaly dobré důvody pro rozvoj tohoto vzoru, protože databáze obsahují data, na kterých běží podnik, a chyby mohou být katastrofální. Zatímco opatrnost dříve připadala rozumná, náklad této opatrnosti se změnil. Zvyšováním tlaku na DBA a operační týmy, aby provedly změny v databázi stejnou rychlostí, jakou mohou nyní vývojáři psát kód, se rozdíly ve zásobníku staly zátěží. Tyto týmy nemohou držet krok a změny v databázi nyní likvidují rychlostní výhodu poskytnutou nástroji s podporou umělé inteligence. Řešení jedné omezení – času potřebného pro psaní kódu – pouze zdůraznilo další úzké místo v procesu. Jedná se o systémové myšlení přivedené k životu a výsledná tření se stává stále bolestivější pro podnik.

Rychlost a kontrola nejsou protiklady. Ale způsob, jakým většina organizací řídí změny v databázi, je jako by ano.

Tradiční model řízení databáze byl navržen pro svět čtvrtletních vydání. Žádosti o změnu, schvalovací výbory, manuální cykly kontrol, plány rollbacku psané před nasazením, které se konaly čtyřikrát do roka. Žádné z toho není samo o sobě špatné. Jednalo se o řízení rizik, které vyrostlo, aby se vešlo do času dostupného v čase mezi nasazením. Problém je, že kadence nasazení se změnila a u většiny organizací přístup k řízení se nezlepšil. Týmy se očekává, že budou dodávat kontinuálně, ale stále směrují změny v databázi prostřednictvím procesů postavených pro jinou éru. Výsledkem není bezpečnost. Výsledkem je tření, obcházení a rostoucí třída “malých” změn v databázi, které obcházejí řízení úplně, protože formální proces je příliš pomalý na to, aby byl praktický.

To je místo, kde真正ný riziko žije.

Když je řízení příliš pomalé, aby se používalo, lidé přestanou ho používat. Změny schématu se aplikují přímo ve výrobě. Horké opravy se vydávají bez kontroly verzí a s dobrým úmyslem je procházet řádně s dalším formálním vydáním, ale to se nestane, protože lidé jsou zaneprázdněni. Manuální kroky, které měly být bezpečnostní sítí, se stávají věcí, kolem které lidé obcházejí, když jsou pod tlakem. A tlak, ve softwarovém doručování, je výchozí stav.

Odpověď není zpomalit pipeline. Je to přesunout řízení do něj.

Organizace, které vyřešily tento problém, tak neučinily uvolněním svých standardů. Vykonaly tvrdší práci na tom, aby řízení bylo dostatečně rychlé, aby bylo cestou nejmenšího odporu. Změny schématu s kontrolou verzí, automatická detekce odchylek, deterministické kontroly zásad vložené do pipeline CI/CD místo aplikovaných jako brána na konci. Zatímco nástroje poháněné umělou inteligencí jsou pravděpodobnostní – nabízející návrhy na základě vzorců – řízení musí zůstat deterministické, aby bylo efektivní. Používáním předvídatelných a opakujících se kontrol zajišťujete, aby každá změna byla auditovatelná a splňovala bezpečnostní standardy, než vůbec dosáhne výroby. Schvalování stále probíhá. Auditní stopa stále existuje. Ale probíhá ve stejném toku jako vše ostatní, spíše než jako samostatný, pomalejší proces, který sedí mimo něj.

To má význam z důvodu, který jde za hranice produktivity vývojářů. Požadavky na dodržování předpisů nejsou lehčí. Kombinace GDPR, DORA (EU Digitální operační odolnost) a rostoucího počtu sektorových předpisů znamená, že řízení databáze je stále více právní a regulační otázkou, nikoli pouze operační. Organizace, které nemohou prokázat stopovatelnou, auditovatelnou historii změn v databázi, jsou vystaveny způsoby, které se stávají materiálními. Argument pro vložení řízení do pipeline není pouze to, že urychluje dodání. Je to to, co činí dodržování předpisů stopovatelným v měřítku.

Umělá inteligence zvyšuje naléhavost.

Současná vlna nástrojů s podporou umělé inteligence činí tento problém akutnější, ne méně. Když mohou vývojáři generovat a iterovat na aplikaci kód o řád rychleji než dříve, stává se databáze zjevnějším úzkým místem ve srovnání se vším kolem ní. Ale existuje druhý řádový efekt, který je méně široce diskutován. Nástroje s podporou umělé inteligence jsou velmi dobré v generování logiky aplikace. Jsou méně dobré v pochopení dlouhodobých důsledků změn schématu v komplexní, živé produkční databázi. Kombinace rychlejšího tempa vývoje aplikace a návrhů schémat generovaných umělou inteligencí bez zralého řízení je přesně ten tlak, který vytváří incidenty. Rychlost bez strukturálních zábran vytváří podmínky pro chyby, aby se staly rychlejšími.

Organizace, které budou tuto situaci zvládat dobře, jsou ty, které pohlížejí na řízení databáze jako na první třídou inženýrskou záležitost, nikoli jako na dodatečnou záležitost dodržování předpisů. To znamená, že kontrola verzí schématu databáze je nevyhnutelnou výchozí hodnotou a automatické testování zpracovává rutinní kontroly, aby manuální dohled mohl soustředit na vysoké riziko, vysoké soudní změny, spíše než stát se pozdním úzkým místem. Nakonec to znamená detekci odchylek, která identifikuje rozdíly, než způsobí incident.

Většina podnikových nemovitostí dělá to obtížnějším, než by mělo být.

Existuje realita, která sedí vedle většiny těchto pozorování. Většina podnikových databázových nemovitostí není zelená louka. Představují desetiletí nahromaděných změn schématu, běžících na více platformách DBMS, některé na místě a některé v cloudu, s různými stupni dokumentace a kmenových znalostí rozložených napříč týmy, které se mnohokrát otočily. Konverzace o modernizaci často předpokládá čistý výchozí bod, kterého většina organizací nemá. To je místo, kde je výzva skutečně nejvíce akutní a často brání pokroku. Bez ohledu na to, zda je cílem podporovat inovace, očistit a migrovat data pro umělou inteligenci nebo zlepšit provozní odolnost; vrátí se to k stejné věci. Otázka není, jak postavit dokonalou praxi DevOps pro databázi na novém systému. Otázka je, jak zavést smysluplné řízení na komplexní, dědictví nemovitosti bez zastavení podniku, zatímco to děláte.

Postupné, pipeline-vložené řízení je jediná praktická odpověď na tuto otázku. Nemusíte re-platformovat celou nemovitost, než můžete zlepšit své postupy pro řízení změn. Moderní nástroje, jako je Redgate Flyway, existují, aby ulehčily databázi jako úzkému místu a začaly s změnami, které se dnes provádějí, v pipeline, které již existují, a stavěly z nich.

Organizace, které budou vyhrávat na růstu v příštích pěti letech, nebudou ty, které mají nejčistější nemovitosti. Budou to ty, které vyřešily, jak udělat změnu důvěryhodnou, v tempu, které podnik vyžaduje, napříč nemovitostí, kterou skutečně mají.

To je problém, který stojí za řešení. A je řešitelný.