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.