Oszacowanie zakresu migracji danych

Sama migracja to najłatwiejsza część. Trudności kryją się właśnie w etapie uzgadniania, o którym Pan zapomniał.

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 do miejsca docelowego, 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: rekordy, które wyglądają poprawnie, ale odwołują się do danych, które nie zostały przeniesione; rekordy, które wydają się uszkodzone, ale w rzeczywistości są poprawne w sposób, którego specyfikacja nie uwzględniła; oraz przypadki skrajne, które przetrwały tylko 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, opracowaniu strategii przełączenia oraz cofaniu zmian. 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. Najwyżej dwa dni.”

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

SRE: „Jaka jest metoda przejścia na nowy system: metoda »big bang« czy metoda 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 szacunków. Jeśli stary system zostanie wycofany za miesiąc, potrzebna jest strategia zapewniająca 100-procentową poprawność; 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 głosowaniem

• 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?
• 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 bezbłędnie, i na jakim poziomie?
• Jakie są procedury przywrócenia stanu poprzedniego, 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ą. Należy je rozdzielić: transformacja stanowi jeden zgłoszenie, a uzgodnienie i plan przejścia – kolejne.

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

W przypadku wariantu zmiany schematu w ramach jednego systemu prosimy zapoznać się z artykułem szacowanie migracji bazy danych, a także z innymi przykładami szacunków z praktyki. Po nakreśleniu strategii przejścia prosimy rozpocząć bezpłatną sesję planowania pokerowego.