Liderzy opinii
Czy Twoja baza danych bÄdzie gotowa, jeÅli prÄdkoÅÄ rozwoju zwiÄkszy siÄ o rzÄ d wielkoÅci?

NarzÄdzia wspomagane przez sztucznÄ inteligencjÄ zwiÄkszyÅy prÄdkoÅÄ i zmniejszyÅy koszt tworzenia kodu. Jednak liderzy biznesu zadajÄ sobie pytanie, dlaczego ta wydajnoÅÄ nie przekÅada siÄ na lepszÄ innowacyjnoÅÄ i szybszy czas wprowadzania na rynek. Zamiast przyspieszaÄ caÅego cyklu dostarczania, ten wzrost prÄdkoÅci tylko ujawniÅ sÅaboÅÄ istniejÄ cych procesÃģw zmiany bazy danych.
Przez ostatniÄ dekadÄ odpowiedÅš na pytanie âjak moÅžemy ruszyÄ szybciej?â byÅa budowaniem lepszych potokÃģw, inwestowaniem w CI/CD i przesuniÄciem testowania w lewo. Inwestycje te przyniosÅy efekty â kod aplikacji porusza siÄ w imponujÄ cym tempie w dojrzaÅych organizacjach inÅžynierskich. Niemniej, te zyski nie byÅy odczuwalne rÃģwnomiernie w caÅej stosie technologicznej. Baza danych byÅa czÄsto traktowana jako wyjÄ tek; chroniony aktyw wymagajÄ cy innego standardu opieki, wolniejszych procesÃģw i rÄcznej kontroli. ByÅy dobre powody, dla ktÃģrych ten wzorzec siÄ rozwinÄ Å, poniewaÅž bazy danych zawierajÄ dane, na ktÃģrych opiera siÄ dziaÅalnoÅÄ biznesowa, a bÅÄdy mogÄ byÄ katastrofalne. ChociaÅž ostroÅžnoÅÄ kiedyÅ wydawaÅa siÄ uzasadniona, koszt tej ostroÅžnoÅci ulegÅ zmianie. Poprzez zwiÄkszanie presji na administratorÃģw baz danych i zespoÅy operacyjne, aby wprowadzali zmiany w bazie danych w tym samym tempie, w jakim deweloperzy mogÄ teraz pisaÄ kod, dysproporcja w stosie staÅa siÄ zaporÄ . Te zespoÅy nie mogÄ nadÄ ÅžyÄ, a zmiany w bazie danych zabijajÄ teraz przewagÄ szybkoÅci zapewnianÄ przez narzÄdzia wspomagane przez sztucznÄ inteligencjÄ. RozwiÄ zanie jednego ograniczenia â czasu potrzebnego do napisania kodu â tylko podkreÅliÅo nastÄpne gardÅo Åadowania w procesie. To jest myÅlenie systemowe w praktyce, a wynikajÄ ce z tego tarcie staje siÄ coraz bardziej bolesne dla przedsiÄbiorstwa.
PrÄdkoÅÄ i kontrola nie sÄ przeciwieÅstwami. Ale sposÃģb, w jaki wiÄkszoÅÄ organizacji zarzÄ dza zmianÄ bazy danych, traktuje je tak, jakby byÅy.
Tradycyjny model zarzÄ dzania bazÄ danych zostaÅ zaprojektowany dla Åwiata wydaÅ kwartalnych. ÅŧÄ dania zmian, komitety zatwierdzajÄ ce, cykle przeglÄ du rÄcznego, plany wycofania napisane z wyprzedzeniem przed wdroÅženiami, ktÃģre miaÅy miejsce cztery razy w roku. Nic z tego nie jest z natury zÅe. ByÅo to zarzÄ dzanie ryzykiem, ktÃģre rosÅo wraz z czasem dostÄpnym miÄdzy wdroÅženiami. Problem polega na tym, Åže czÄstotliwoÅÄ wdroÅžeÅ ulegÅa zmianie, a dla wiÄkszoÅci organizacji podejÅcie do zarzÄ dzania nie nadÄ ÅžyÅo. ZespoÅy sÄ zobowiÄ zane do ciÄ gÅego dostarczania, ale nadal kierujÄ zmiany w bazie danych przez procesy opracowane dla innej ery. Wynikiem nie jest bezpieczeÅstwo. Wynikiem sÄ tarcie, obejÅcia i rosnÄ ca klasa âmaÅychâ zmian w bazie danych, ktÃģre omijajÄ zarzÄ dzanie caÅkowicie, poniewaÅž formalny proces jest zbyt wolny, aby byÅ praktyczny.
To jest miejsce, w ktÃģrym mieszka prawdziwe ryzyko.
Gdy zarzÄ dzanie jest zbyt wolne, aby byÅo uÅžywane, ludzie przestajÄ z niego korzystaÄ. Zmiany schematu sÄ stosowane bezpoÅrednio w produkcji. Poprawki sÄ wypuszczane bez kontroli wersji, a z dobrymi intencjami, aby je poprawnie wdroÅžyÄ z nastÄpnym formalnym wydaniem, ale to nie nastÄpuje, poniewaÅž ludzie sÄ zajÄci. RÄczne kroki, ktÃģre miaÅy byÄ siatkÄ bezpieczeÅstwa, stajÄ siÄ tym, czego ludzie szukajÄ , gdy sÄ pod presjÄ . A presja, w dostawie oprogramowania, jest stanem domyÅlnym.
OdpowiedÅš nie polega na spowolnieniu potoku. Polega na przeniesieniu zarzÄ dzania do jego wnÄtrza.
Organizacje, ktÃģre rozwiÄ zaÅy ten problem, nie zrobiÅy tego, relaksujÄ c swoje standardy. WykonaÅy trudniejszÄ pracÄ, czyniÄ c zarzÄ dzanie wystarczajÄ co szybkim, aby byÅo najkrÃģtszÄ drogÄ . Zmiany schematu z kontrolÄ wersji, automatyczne wykrywanie dryfu, deterministyczne kontrole polityki wbudowane w potok CI/CD zamiast stosowane jako brama na koÅcu. Podczas gdy narzÄdzia napÄdzane przez sztucznÄ inteligencjÄ sÄ probabilistyczne â oferujÄ sugestie na podstawie wzorcÃģw â zarzÄ dzanie musi pozostaÄ deterministyczne, aby byÄ skuteczne. Poprzez korzystanie z przewidywalnych i powtarzalnych kontroli, zapewniasz, Åže kaÅžda zmiana jest audytowalna i speÅnia standardy bezpieczeÅstwa przed tym, jak kiedykolwiek osiÄ gnie produkcjÄ. Zatwierdzenie nadal wystÄpuje. Ålad audytowy nadal istnieje. Ale wystÄpuje w tym samym przepÅywie, co wszystko inne, a nie jako oddzielny, wolniejszy proces, ktÃģry znajduje siÄ poza nim.
To ma znaczenie z powodu, ktÃģry wykracza poza produktywnoÅÄ deweloperÃģw. Wymagania dotyczÄ ce zgodnoÅci nie stajÄ siÄ lÅžejsze. PoÅÄ czenie GDPR, DORA (Unijnej ustawy o operacyjnej odpornoÅci cyfrowej) i rosnÄ cego zakresu przepisÃģw sektorowych oznacza, Åže zarzÄ dzanie bazÄ danych staje siÄ coraz bardziej kwestiÄ prawnÄ i regulacyjnÄ , a nie tylko operacyjnÄ . Organizacje, ktÃģre nie mogÄ wykazaÄ Åladu audytowego, historycznego zmiany bazy danych, sÄ naraÅžone na sposoby, ktÃģre stajÄ siÄ materialne. Argumentem za wbudowaniem zarzÄ dzania w potok jest nie tylko to, Åže przyspiesza dostawÄ. To to, co sprawia, Åže zgodnoÅÄ jest Åladowalna w skali.
Sztuczna inteligencja zwiÄksza pilnoÅÄ.
Obecna fala rozwoju wspomaganego przez sztucznÄ inteligencjÄ sprawia, Åže ten problem staje siÄ bardziej palÄ cy, a nie mniej. Gdy deweloperzy mogÄ generowaÄ i iterowaÄ kod aplikacji o rzÄ d wielkoÅci szybciej niÅž wczeÅniej, baza danych staje siÄ bardziej oczywistÄ wÄ skim gardÅem w stosunku do wszystkiego, co jÄ otacza. Ale jest efekt drugiego rzÄdu, ktÃģry jest mniej szeroko dyskutowany. NarzÄdzia wspomagane przez sztucznÄ inteligencjÄ sÄ bardzo dobre w generowaniu logiki aplikacji. SÄ mniej dobre w zrozumieniu dÅugoterminowych konsekwencji zmian schematu w zÅoÅžonej, produkcyjnej bazie danych. PoÅÄ czenie szybkoÅci rozwoju aplikacji i sugestii schematu generowanych przez sztucznÄ inteligencjÄ bez dojrzaÅego zarzÄ dzania jest wÅaÅnie rodzajem presji, ktÃģry powoduje incydenty. PrÄdkoÅÄ bez strukturalnych barier tworzy warunki, w ktÃģrych bÅÄdy mogÄ wystÄ piÄ szybciej.
Organizacje, ktÃģre bÄdÄ radziÄ sobie z tym dobrze, sÄ tymi, ktÃģre traktujÄ zarzÄ dzanie bazÄ danych jako pierwszorzÄdne zagadnienie inÅžynierskie, a nie myÅlÄ o tym jako o pomyÅle zgodnoÅci. To oznacza, Åže kontrola wersji schematu bazy danych jest niepodwaÅžalnÄ domyÅlnÄ wartoÅciÄ , a automatyczne testowanie zajmuje siÄ rutynowymi sprawdzaniem, tak aby rÄczna kontrola mogÅa siÄ skupiÄ na zmianach o wysokim ryzyku i wysokiej ocenie, a nie stawaÄ siÄ pÃģÅšnym gardÅem. W koÅcu oznacza to wykrywanie dryfu, ktÃģre identyfikuje rozbieÅžnoÅÄ przed wystÄ pieniem incydentu.
WiÄkszoÅÄ przedsiÄbiorstw utrudnia to bardziej, niÅž powinna.
Istnieje rzeczywistoÅÄ, ktÃģra wspÃģÅwystÄpuje z wiÄkszoÅciÄ tych obserwacji. WiÄkszoÅÄ przedsiÄbiorstw baz danych nie jest nowo utworzona. ReprezentujÄ one dziesiÄciolecia nagromadzonych zmian schematu, dziaÅajÄ cych na wielu platformach systemu zarzÄ dzania bazÄ danych, niektÃģre z nich sÄ lokalne, a niektÃģre w chmurze, z rÃģÅžnymi stopniami dokumentacji i wiedzy plemiennej rozproszonej w zespoÅach, ktÃģre wielokrotnie siÄ zmieniaÅy. Dyskusja na temat modernizacji czÄsto zakÅada czysty punkt wyjÅcia, ktÃģrego wiÄkszoÅÄ organizacji nie posiada. To jest miejsce, w ktÃģrym wyzwanie jest naprawdÄ najbardziej ostre i czÄsto utrudnia postÄp. NiezaleÅžnie od tego, czy celem jest wspieranie innowacji, oczyszczanie i migracja danych do sztucznej inteligencji czy poprawa operacyjnej wytrzymaÅoÅci; wszystko sprowadza siÄ do tych samych rzeczy. Pytanie nie brzmi, jak zbudowaÄ idealnÄ praktykÄ DevOps dla bazy danych na nowym systemie. Pytanie brzmi, jak wprowadziÄ znaczÄ ce zarzÄ dzanie na zÅoÅžonej, dziedziczonej bazie danych bez zatrzymywania dziaÅalnoÅci biznesowej podczas tego procesu.
Stopniowe, wbudowane w potok zarzÄ dzanie jest jedynÄ praktycznÄ odpowiedziÄ na to pytanie. Nie musisz ponownie platformowaÄ caÅej bazy danych, zanim bÄdziesz mÃģgÅ poprawiÄ swoje praktyki zarzÄ dzania zmianÄ . Nowoczesne narzÄdzia, takie jak Redgate Flyway, istniejÄ , aby zÅagodziÄ bariery zwiÄ zane z bazÄ danych i zaczÄ Ä od zmian, ktÃģre sÄ wprowadzane dzisiaj, w potokach, ktÃģre juÅž istniejÄ , i budowaÄ od tego.
Organizacje, ktÃģre wygrajÄ w wzroÅcie w ciÄ gu najbliÅžszych piÄciu lat, nie bÄdÄ tymi, ktÃģre majÄ najczystsze bazy danych. BÄdÄ to te, ktÃģre rozwiÄ zaÅy problem, jak uczyniÄ zmianÄ godnÄ zaufania, w tempie, jakiego wymaga biznes, w bazie danych, ktÃģrÄ naprawdÄ posiadajÄ .
To jest problem, ktÃģrego rozwiÄ zanie jest warte. I jest on rozwiÄ zywalny.












