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 drugiej w ramach 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óre nie zostały przeniesione; 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 operacja 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, opracowywaniu strategii przełączenia oraz przywracaniu poprzedniego stanu. 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.”

Dane inżynieryjne: „Czy sprawdziliśmy, w jakim stopniu źródło jest zanieczyszczone?”

SRE: „Jaka będzie metoda przełączenia: metoda „big bang” czy metoda podwójnego zapisu?”

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

Premier: „Kiedy wycofamy stary system?”

To pytanie 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 on 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 wdrażanie?
• Jak długo oba systemy będą funkcjonować równolegle? Czy wyznaczono termin wycofania jednego z nich?
• Kto zajmuje się uzgadnianiem wierszy, których migracja nie przebiega prawidłowo, i na jakim poziomie?
• Jakie są procedury przywrócenia poprzedniego stanu, jeśli nowy system otrzyma błędne dane po przejściu na nowy system?
• Czy istnieją odbiorcy końcowi (raporty, integracje), których migracja musi przebiegać w sposób zsynchronizowany?

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 po prostu dwa zadania udające jedno. Należy je rozdzielić: transformacja to jedno zgłoszenie, a uzgodnienie i plan przejścia to kolejne.

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

Proszę zapoznać się z sekcją dotyczącą szacowania migracji bazy danych w wariancie zmiany schematu w jednym systemie oraz z innymi przykładami praktycznych szacunków. Po nakreśleniu strategii przejścia proszę zorganizować bezpłatną sesję „planning poker”.