ANEGIS Storage Trim: jak wygląda proces redukcji bazy od analizy do automatyzacji

W poprzednich artykułach tego cyklu rozłożyliśmy problem na części: pokazaliśmy, dlaczego bazy Dynamics 365 Finance & Operations rosną same z siebie, ile kosztuje przekroczenie limitu Database Storage Capacity, gdzie kryje się ciężar (w indeksach, sandboxach, logach i danych historycznych) oraz jakie mechanizmy pozwalają go zdjąć. Ten artykuł składa części z powrotem w całość: opisuje, jak wygląda ANEGIS Storage Trim, usługa, w której te mechanizmy tworzą jeden uporządkowany proces, od diagnozy po automatyzację utrzymującą efekt.

‍

Cel: wykres logarytmiczny zamiast wykładniczego

Zacznijmy od definicji sukcesu, bo wyznacza ona wszystko, co dalej. Celem Storage Trim nie jest jednorazowe odchudzenie bazy. Jednorazowy uzysk eroduje, bo kategorie balastu przyrastają nieprzerwanie. Celem jest zmiana charakteru krzywej wzrostu: doprowadzenie konsumpcji do wskazanego progu i utrzymanie jej na trajektorii logarytmicznej, spłaszczającej się poniżej progu, do którego dążymy, zamiast wykładniczej, która co roku wystawia wyższy rachunek.

Ograniczyć koszty i ryzyko, zwiększyć wydajność, a nie sprzątać dla samego sprzątania

To nie jest projekt o sprzątaniu dla samego sprzątania. Miary sukcesu są trzy i wszystkie biznesowe: ograniczenie kosztów (konsumpcja poniżej progu należnej pojemności oznacza zero wydatków na add-on Database Capacity); ograniczenie ryzyka (zgodność licencyjna osiągnięta, zanim zaostrzą się zasady jej egzekwowania, i to procedurami przetestowanymi, a nie akcją pod presją); zwiększenie wydajności (mniejsza baza to krótsze backupy, sprawniejsze zadania batch i raporty wracające na ekran bez czekania, czyli pośrednia korzyść, którą odczuwa każdy użytkownik systemu).

‍

Cztery elementy usługi: dlaczego dobierane, a nie narzucane

Storage Trim składa się z czterech elementów. Celowo nie nazywamy ich etapami: każdy jest dopasowywany do potrzeb konkretnego klienta i nie każdy musi wystąpić, bo o doborze decyduje analiza, nie cennik. Wspólny dla wszystkich wariantów jest tylko punkt startu: analiza tabela po tabeli na wiernej kopii środowiska produkcyjnego, która wskazuje, gdzie leży ciężar i które elementy w ogóle mają sens.

Cleanup jobs: analiza, wskazanie, wykonanie

Element pierwszy porządkuje czyszczenie danych: audyt istniejących zadań (standardowych, partnerskich i z rozwiązań ISV), wskazanie konkretnych elementów do czyszczenia i ich właściwe wykonanie. Tam, gdzie wolumen przerasta standard, wchodzą dedykowane skrypty oraz cykliczne, rekurencyjne zadania w postaci SQL-owej, zaprojektowane tak, by maksymalizować skuteczność przy minimalnym wpływie na operacje biznesowe, bo nie każdą tabelę można czyścić bez konsekwencji dla pracujących procesów.

Zarządzanie indeksami: statystyki, koszykowanie, bezpieczne wyłączanie

Element drugi adresuje największą pojedynczą rezerwę: indeksy, które w skali aplikacji odpowiadają bardzo często za 70 do 80% konsumowanej przestrzeni, przy czym około 20% z nich jest w ogóle nieużywane. Proces: gromadzenie statystyk użycia przez okres obejmujący pełny cykl biznesowy (łącznie z zamknięciem miesiąca i roku, w razie potrzeby z dołączeniem statystyk z testowego zamknięcia na środowisku nieprodukcyjnym), następnie koszykowanie indeksów i skrypt wyłączeń wykonywany najpierw na teście, potem na produkcji. Operacja jest mało zasobożerna i w pełni odwracalna, więc ryzyko dla produkcji pozostaje minimalne.

Redukcja lub eliminacja sandboxów

Element trzeci rozlicza środowiska nieprodukcyjne, które dokładają do puli należnej po około 10 GB, a konsumują pełne kopie produkcji. W zależności od roli środowiska stosujemy jeden z trzech poziomów: wycięcie danych sprzed daty granicznej, z automatyzacją pipeline'em w Azure DevOps uruchamianym po każdym odświeżeniu bazy; hard cleanup, czyli truncate tabel transakcyjnych z zachowaniem danych podstawowych i konfiguracji; albo dealokację środowiska bądź przeniesienie go na inną warstwę, w tym Cloud Hosted, z rachunkiem kosztów policzonym per środowisko, bo przeniesienie nie zawsze wychodzi taniej.

Archiwizacja: Data Archive lub substytut SQL-owy

Element czwarty, adresowany przede wszystkim do środowisk działających produkcyjnie ponad dwa lata, przenosi dane historyczne poza tabele operacyjne. Tam, gdzie to możliwe, wykorzystujemy standardowy mechanizm Microsoft Data Archive, wspierając klienta we właściwej implementacji i w określeniu wpływu na procesy biznesowe, bo włączyć scenariusz łatwo, oszacować skutki trudniej. Tam, gdzie standard się zatrzymuje (na tabelach powyżej progów stu czy dwustu milionów rekordów albo w obszarach bez gotowego scenariusza), wdrażamy nasz substytut: małe, iteracyjne zadania SQL-owe wycinające kolejne partie rekordów bez progów blokujących i bez obciążania serwerów AOS.

‍

Jak wygląda start: minimalne zaangażowanie klienta

Świadomie zaprojektowaliśmy wejście w proces tak, aby wymagało od klienta minimum pracy, bo decyzja o projekcie powinna zapadać na podstawie liczb, a nie obietnic.

Zrzuty z Power Platform Admin Center + jeden skrypt SQL

Zadania klienta na starcie sprowadzają się do dwóch czynności. Pierwsza: zrzuty widoku pojemności z Power Platform Admin Center, czyli zestawienie należnej i konsumowanej pojemności z rozbiciem na środowiska; wymaga uprawnień licencyjnych albo krótkiego requestu do administratora tenanta. Druga: uruchomienie skryptu SQL badającego rozmiary tabel na środowisku testowym, w tym na wiernej kopii produkcji. Do obu czynności wysyłamy prostą instrukcję i pomagamy w jej przejściu, jeśli będzie taka potrzeba.

Estymacja uzysków przed decyzją

Na podstawie tych dwóch materiałów przygotowujemy estymację uzysków: ile przestrzeni realnie odda każdy z czterech elementów w konkretnym środowisku i jak przekłada się to na rachunek licencyjny. Dopiero z tą estymacją w ręku klient podejmuje decyzję o projekcie, wiedząc, co kupuje i co dostanie.

‍

Fixed price w skończonym czasie: dlaczego tak wyceniamy

Ofertę składamy w modelu fixed price na rozwiązanie, które jesteśmy w stanie zrealizować w skończonym czasie. Wybór modelu nie jest przypadkowy. Rozliczenie godzinowe przy projekcie redukcyjnym tworzy konflikt interesów (im dłużej trwa, tym więcej kosztuje), podczas gdy fixed price przenosi ryzyko wyceny na nas i zrównuje nasz interes z interesem klienta: zrealizować uzysk sprawnie i domknąć projekt. Estymacja z poprzedniego kroku czyni tę wycenę możliwą: znamy ciężar środowiska, zanim złożymy ofertę, więc cena nie zawiera marginesu na niewiedzę.

‍

Czego NIE robimy: operacje, które klient wykona własnym sumptem

Równie ważne jak zakres usługi jest to, co świadomie zostawiamy po stronie klienta. Nie każdy krok musi być wykonany przez ANEGIS czy współpracowników ANEGIS: audyt i uruchomienie standardowych cleanupów, cykliczne monitorowanie rozmiarów i decyzje retencyjne z księgowością to prace, które organizacja jest w stanie wykonać własnym sumptem, i nie zamierzamy ich fakturować.

Model współpracy: cel klienta ponad billing partnera

Nasza rola jako organizacji polega na tym, aby pomóc klientowi zrealizować konkretny cel (ograniczyć koszty, ograniczyć ryzyko, zwiększyć wydajność), a nie wykonywać za klienta czynności powtarzalne, które nie wymagają naszej wiedzy. Wiedza ekspercka jest potrzebna tam, gdzie rośnie złożoność i ryzyko: w analizie i interpretacji ciężaru, w projektowaniu dedykowanych skryptów, w zarządzaniu indeksami na produkcji, w archiwizacji tabel, których standard nie obejmie. Tam wchodzimy i tam kończy się rachunek.

‍

Efekty: koszty, wydajność, powtarzalna procedura roczna

Rezultaty domykają się w czterech pozycjach. Minimalizacja czasu poświęconego na archiwizację i zaaplikowanie reguł retencji, bo proces prowadzi sprawdzona procedura, nie improwizacja. Redukcja ryzyka, czy dany proces się powiedzie, bo każdy krok jest testowany przed produkcją i odwracalny tam, gdzie to możliwe. Pośredni zysk wydajnościowy: mniejsze tabele to szybsze środowisko dla wszystkich użytkowników. I wreszcie element, który odróżnia projekt od akcji: procedury roczne, czyli powtarzalne kroki, które w kolejnych latach można zaaplikować dokładnie w ten sam sposób, krok po kroku, minimalizując angaż partnerów i własnych zasobów. Baza dostaje nie tylko porządek, ale i mechanizm, który ten porządek utrzymuje.

Chcesz zobaczyć estymację dla swojego środowiska? Skontaktuj się z nami, a wyślemy prostą instrukcję self-checku i pomożemy w jej przejściu. Zrzuty z Power Platform Admin Center plus wynik jednego skryptu SQL wystarczą, abyśmy przygotowali estymację uzysków i ofertę fixed price na ich realizację w skończonym czasie.

‍