Oszacowanie zakresu migracji danych

Sama migracja to najłatwiejsza część. To właśnie w etapie uzgadniania, o którym pan zapomniał, kryją się najtrudniejsze kwestie.

Migracja danych — przenoszenie danych z jednego systemu do drugiego lub z jednej struktury do innej w obrębie tego samego systemu — przypomina transformację. Odczyt z źródła, transformacja, zapis w miejscu docelowym, przełączenie ruchu. Zespół głosuje nad transformacją. Transformacja jest zazwyczaj najmniejszym elementem pracy w ramach danego zadania. Trudności tkwią w elementach, których transformacja nie uwzględnia: rekordach, które wyglądają poprawnie, ale odwołują się do danych, których nie udało się przenieść; rekordach, które wydają się uszkodzone, ale w rzeczywistości są poprawne w sposób, którego specyfikacja nie uwzględniła; oraz przypadkach skrajnych, które przetrwały jedynie dlatego, że stary system je tolerował, a nowy już nie.

Jest to problem inny niż migracja bazy danych. Migracja schematu zmienia strukturę jednego magazynu danych, w którym dane już się znajdują. Migracja danych polega na przenoszeniu danych między systemami, a pytanie nie brzmi: „czy polecenie ALTER zakończy się na czas?” — lecz „co zrobić z wierszami, które nie pasują do żadnej ze stron?”. Większość pracy polega na uzgadnianiu danych, opracowaniu strategii przełączenia oraz przywracaniu stanu poprzedniego. Kod transformujący jest częścią, którą pisze się najszybciej, a kończy jako ostatnią.

O czym się mówi w tym pomieszczeniu

Backend: „To skrypt. Odczyt, mapowanie, zapis. Maksymalnie dwa dni.”

Data eng: „Czy sprawdziliśmy, w jakim stanie jest źródło?”

SRE: „Jakie będzie przejście — metodą »big bang« czy metodą podwójnego zapisu?”

Wstęp: „Kto zajmuje się uzgadnianiem wierszy, których migracja nie przebiega bezbłędnie?”

Premier: „Kiedy zamierzamy wycofać stary system?”

To właśnie pytanie postawione przez premiera powinno stanowić punkt wyjścia dla oszacowania. Jeśli stary system zostanie wycofany za miesiąc, potrzebna jest strategia zapewniająca 100% poprawności; jeśli natomiast będzie funkcjonował równolegle z nowym przez dwa kwartały, można sobie pozwolić na odłożenie kwestii „długiego ogona” na później. Szacunek nie dotyczy samej transformacji — dotyczy strategii.

Pytania, które warto zadać przed oddaniem głosu

Jaka jest jakość danych źródłowych — czyste, zanieczyszczone czy nieznana?
Strategia przejścia: metoda „big bang”, podwójny zapis, odczyt z kopii zapasowej, stopniowe przejście?
Jak długo oba systemy będą funkcjonować równolegle? Czy wyznaczono termin wycofania jednego z nich?
Kto dokonuje uzgodnienia wierszy, których migracja nie przebiega bezbłędnie, i na podstawie jakiego progu?
Jakie są procedury przywrócenia poprzedniego stanu, jeśli nowy system otrzyma błędne dane po przejściu na nowy system?
Czy istnieją konsumenci danych na dalszych etapach procesu (raporty, integracje), których migracja musi przebiegać synchronicznie?

Jeśli zespół oceni zadanie na 5, a ktoś zapyta: „Chwileczkę, a co z zapisami w dzienniku audytowym?”, to nie mieli Państwo problemu z oszacowaniem; mieli Państwo do czynienia z dwoma historiami udającymi jedną. Proszę to podzielić: transformacja to jeden zgłoszenie, a uzgodnienie i plan przejścia to kolejne.

Proszę głosować nad strategią, a nie nad zmianami. Zmiany potrwają dwa dni. Strategia obejmuje cały kwartał.

Więcej informacji na temat wariantu zmiany schematu w ramach jednego systemu można znaleźć w artykule Szacowanie kosztów migracji bazy danych, a także w innych przykładach praktycznych szacunków. Po nakreśleniu strategii przejścia proszę zorganizować bezpłatną sesję planowania pokerowego.