Migracja danych - niebezpieczna czy niezbędna?

Dział rozwoju oprogramowania mojej firmy boryka się z problemem, że migracje danych są uważane za potencjalnie niebezpieczne, szczególnie dla moich menedżerów.

Tło jest takie, że nasi klienci używają dużej ilości danych o niskiej jakości . Przyczyny tego są tylko częściowo związane z jakością naszego oprogramowania , ale raczej z historią danych: większość z nich została zmigrowana z poprzednich systemów , niektóre błędy spowodowały (głównie biznesowe) niespójności w rekordach danych lub wypadki przez przypadek na strona klienta (co nasze oprogramowanie dopuszcza przez błąd).

Najważniejsze kontrargumenty moich menedżerów są takie, że błędne dane mogą przerodzić się w jeszcze gorsze dane , problemy z danymi mogą obudzić niektórych menedżerów u klienta, a niektóre procesy po stronie klienta mogą już nie działać, ponieważ ich procesy są w pewnym stopniu dostosowane do naszego systemu.

Osobiście uważam migracje danych za integralną część rozwoju oprogramowania, a migracja danych jest widoczna dla danych, czym jest refaktoryzacja do kodu. Myślę, że migracja danych jest niezbędna do tworzenia ewoluującego oprogramowania . Bez tego musielibyśmy stworzyć bolesne oprogramowanie, które nieco działa na złą strukturę danych.

Pytam cię:

• Jakie są Twoje przemyślenia na temat migracji danych, szczególnie w rzeczywistych przypadkach, a nie tylko z perspektywy dewelopera?
• Czy masz jakieś argumenty przeciwko opiniom moich menedżerów?
• Jak Twoja firma radzi sobie z migracjami danych i powodowanymi przez nie trudnościami?
• Jakieś inne ciekawe myśli należące do tego tematu?

Migracje danych to mój chleb powszedni, a czyszczenie danych jest rzeczywiście niezwykle ważną sprawą. Jedną ze stosowanych przez nas strategii migracji 100% danych naszych klientów są asymptotyczne narzędzia do czyszczenia danych przed migracją.

1. Oznacza to opracowanie dziesiątek kontroli bezpieczeństwa danych (głównie zapytań SQL).

2. Wymiana narzędzi czyszczących z klientem (ponieważ to jego dane, projektujemy narzędzia do łatania, on je weryfikuje i wykonuje).

3. Ulepszanie narzędzia ponad iteracjami i osiągnięcie jak najszybciej mierzalnej jakości wspieranej przez KPI.

4. Sprawdzanie spójności danych po migracji. Pomaga to podjąć decyzję GO / NOGO w D-Day.

W końcu migracja danych jest niezwykle korzystnym ćwiczeniem, które musi nastąpić po 3–5 latach.

1. Pozwala zwiększyć zdolność platformy do wspierania biznesu.

2. Pozwala to usprawnić bazę danych.

3. Przygotowuje platformę IT dla narzędzi biznesowych nowej generacji (ESB / EAI, portale, platformy samoobsługowe, raportowanie i eksploracja danych, jak to nazywacie).

4. Reorganizuje przepływy danych DIY między platformami, które gromadziły się przez lata, w szybki i brudny „tymczasowy” sposób, aby spełnić „pilne wymagania”.

5. Przede wszystkim wspiera zespół produkcyjny IT, który lepiej poznaje swoją platformę i promuje postawy „potrafią”. Tego rodzaju korzyści są trudne do zmierzenia, ale gdy poznasz wielu klientów, ta uwaga staje się oczywista. Firmy unikające migracji pozostają na kolejnym poziomie, śmiałe przewodzą.

To trochę tak, jakby piwnica twojego domu była zagracona drewnem. Pewnego ranka musisz wyjąć wszystko i odłożyć tylko to, czego potrzebujesz, a resztę wyrzucić. Następnie możesz ponownie użyć piwnicy ;-)

Inną podstawową kwestią jest to, że w dzisiejszych czasach oczekiwania klientów są zawsze w ruchu, ponieważ „klienci są zawsze bardziej wymagający”. Dzięki temu zawsze będzie znaczna część konkurentów danej firmy poszukujących nowych trendów z oczywistym zamiarem zwiększenia swojego udziału w rynku. W ten sposób dostosowują swoją ofertę do trendu, a nawet kierują trendami, a to pociąga za sobą ciągłe przeprojektowywanie biznesu. Jeśli twoja platforma IT jest zbyt sztywna, utrudnisz sobie nawiązywanie małżonków lub wyprzedzenie trendów rynkowych po swojej stronie, a ostatecznie utrzymanie własnego udziału w rynku. Innymi słowy, na rynku ruchomym bezwładność jest receptą na brak znaczenia.

Natomiast migracja danych do nowszego systemu pozwoli wprowadzić bardziej nowoczesne i wszechstronne narzędzie zwiększające produktywność, dzięki czemu najlepsze nowsze technologie będą bardziej atrakcyjne dla pracowników, a to z kolei przyczyni się do wsparcia, a nawet poprowadzenia wewnętrznego procesu innowacji firmy , tym samym zabezpieczając lub zwiększając swój względny udział w rynku.

Powyższe rozważania w rzeczywistości odpowiadają tylko połowie pytania zadanego w tytule „Migracja danych - niebezpieczna lub niezbędna”. Tak Migracje danych są niezbędne, ale czy są również niebezpieczne? Z tego powodu wiele rzeczy w IT jest wówczas niebezpiecznych. Z definicji wszystko, co jest wysokie, jest niebezpieczne; zwłaszcza jeśli nie traktujesz tej sprawy poważnie. Ale to właściwie najczęstszy wzorzec w IT. Niestosowanie poważnie centrów danych, wysokiej dostępności lub tolerancji na katastrofy jest niebezpieczne.
Czy to oznacza, że ​​dzisiejsze firmy powinny zrezygnować z tych filarów współczesnego krajobrazu technologii informatycznych? Na pewno nie !

Aby żartować, możesz argumentować, że „Latanie jest niebezpieczne, jeśli nie korzystasz z samolotu stworzonego przez profesjonalistów”. To samo dotyczy migracji danych. Wykonany i przeprowadzony przez profesjonalistów, nie jest bardziej niebezpieczny niż latanie w dobrze zaprojektowanym i dobrze obsługiwanym samolocie. Zwrot z inwestycji jest taki sam, jak w przypadku naziemnych środków transportu.
Po powierzeniu profesjonalistom większość migracji jest dobrze kontrolowanymi sukcesami, a odsetek niepowodzeń i porzucania jest wyjątkowo niski.

Twoi menedżerowie powinni zadać sobie pytanie: „Podczas gdy większość firm z powodzeniem przechodzi projekty migracji danych, co sprawiłoby, że nasza firma byłaby tak inna, że ​​zamiast tego miałaby awarię?

Alain udzielił doskonałej odpowiedzi na temat znaczenia czyszczenia danych dla udanego projektu migracji danych i uzasadnienia przeprowadzenia migracji danych w ogóle. Chciałbym skierować uwagę tylko na konkretne obawy twojego kierownika.

Moim zdaniem nie chodzi o to, czy przeprowadzić migrację danych, ale o to, kiedy to zrobić. Twój menedżer ma absolutną rację twierdząc, że twoje dane nie są już tylko twoje, a klienci końcowi już opracowali wokół nich swoje procedury. Jednak ten stan nie zmieni się w przyszłości . Wcześniej czy później niska jakość danych stanie się nieuniknionym czynnikiem spowalniającym działalność firmy i będziesz zmuszony przeprowadzić migrację. Robienie tego pod presją i przy krótkich terminach może prowadzić do nieoptymalnych decyzji. Poza tym pomyśl o specjalistycznej wiedzy, którą posiadasz teraz i za 2-3 lata. Co się stanie, jeśli osoby, które rozumieją Twoje dane, opuszczą firmę? Czy jesteś pewien, że posiadana dokumentacja jest odpowiednia?

Być może przeprowadzanie migracji teraz nie jest konieczne, ale Twój menedżer musi mieć przynajmniej wizję tego, kiedy dokładnie zostanie przeprowadzona migracja.

Pracowałem dla firmy ubezpieczeniowej i zajmowałem się migracją danych dla systemu podstawowego. Cóż, w sumie było 4 razy. Oto moje komentarze:

W moim przypadku migracja danych jest koniecznością, ponieważ zgodnie z przepisami musimy przechowywać dane przez co najmniej 10 lat i nie możemy sobie pozwolić na wspieranie podwójnego systemu w perspektywie długoterminowej. Innym powodem jest to, że użytkownicy oczekują, że będą mogli kontynuować pracę z nową aplikacją. Jeśli nie mogą znaleźć elementu, nad którym pracują, aplikacja jest zła, a nawet gorzej, gdy dane są nieprawidłowe.

Cóż, migracja danych jest okropną bestią i jest prawdziwa, więc spójrz prawdzie w oczy. Jest to ryzykowne, ale można je zminimalizować, zajmując się nim wcześniej i ostrożnie. Wytyczne obejmują cztery duże procesy, które należy wziąć pod uwagę przy migracji danych:

1. Mapowanie danych. Mapy mistrza (i ich kombinacji) do nowego systemu
2. Czyszczenie danych. Mapy wyjątków w danych, to znaczy danych, których kombinacja jest uważana za nieważną w nowym systemie. Jeśli to możliwe, należy poradzić sobie z biznesem, aby wykluczyć dane, których nie można zmapować i potencjalnie uszkodzić nowy system, i przygotować obejście
3. Rzeczywista migracja danych. Istnieje wiele strategii migracji danych. Na przykład: Wielki Wybuch, przyrostowy
4. Raport konsolidacji. Jeśli oba systemy działają równolegle, jak wygenerować poprawny i spójny raport

Wydarzenie ze starannym planem, gówno się dzieje! Specjalna grupa zadaniowa powinna być gotowa do rozwiązywania problemów związanych z migracją.

1) Jakie są Twoje przemyślenia na temat migracji danych, szczególnie w rzeczywistych przypadkach, a nie tylko z perspektywy dewelopera ?:

Migracja jest niezbędną częścią rozwoju systemów. Jeśli częściowo lub całkowicie zastąpisz stare systemy, migracja jest faktem, niezależnie od tego, czy kierownictwo tego chce, czy nie. Jeśli istniejące dane są złe, źle wpłyną na twój nowy system. Dlatego tak ważna jest dobra strategia migracyjna.

2) Czy masz jakieś argumenty przeciwko opiniom moich menedżerów?

Tak, migracja jest ryzykowna, ale jest też faktem, więc sobie z tym poradzić. I załatw to jak najwcześniej.

3) Jak Twoja firma radzi sobie z migracjami danych i powodowanymi przez nie trudnościami?

Moja firma - wraz ze wzrostem sukcesu aktywnie angażowała klientów w proces migracji. Sprawdzamy istniejące dane najlepiej, jak potrafimy na początkowych etapach projektu, i zachęcamy klienta do poprawy jakości danych przed rozpoczęciem migracji. Czasami faktycznie tego wymagamy.

4: Wszelkie inne interesujące myśli należące do tego tematu

Radzę podzielić proces migracji na dwa etapy: konwersję i czyszczenie danych. Konwersja jest dość prosta - kwestia mapowania starych obiektów systemowych na nowy nowy system. Z drugiej strony czyszczenie danych może być bardzo trudne (jak wspomniano powyżej). Zaangażuj klienta w jak największym stopniu i rozpocznij proces jak najwcześniej. Pamiętaj, że złe dane będą źle odbijały się na twoim nowym systemie - czasem całkowicie bez powodu. Gdy nowy system nie działa, klient rzadko obwinia dane, które w starym systemie wydawały się działać dobrze.

Jeśli dane, które chcesz migrować, są obecnie złe, musisz to naprawić, niezależnie od tego, czy wykonujesz migrację, czy nie. Złe dane = bezużyteczne dane.

Migracje są ryzykowne, to prawda. Ale tak samo jest z każdym większym projektem informatycznym. Istnieją sposoby na ograniczenie ryzyka i na pewno należy je zaplanować z wyprzedzeniem podczas migracji.

Po pierwsze, zawsze powinieneś mieć możliwość powrotu do systemu w obecnej postaci. Drugiej migracji należy dokonać na serwerach testowych skonfigurowanych tylko do migracji. Głupotą jest przeprowadzanie migracji bez możliwości jej przetestowania w pierwszej kolejności. Po trzecie, cały kod do migracji powinien być pod kontrolą źródła.

Po czwarte, przed rozpoczęciem migracji potrzebujesz wymagań i planów testowania. Musisz wiedzieć, że jeśli miałeś 1 293 687 rekordów w starym systemie, to masz to samo w nowym lub wiesz, gdzie poszły (być może do tabeli wyjątków). Jeśli normalizujesz schemat zdenormalizowany, musisz obliczyć, ile rekordów powinieneś skończyć przed rozpoczęciem, a następnie to sprawdzić. Potrzebujesz dokumentacji, która określa, jakie są mapowania z jednego systemu do drugiego. Pomoże to pracownikom kontroli jakości sprawdzić, czy dane trafiły we właściwe miejsce.

Musisz określić sposób obsługi bieżących złych danych. Co można wyczyścić, co może wymagać wartości w wymaganym polu z napisem „Nieznany”, co należy wyrzucić do tabeli wyjątków, co wymaga ręcznej interwencji grupy użytkowników (decydując, czy te dwie osoby są naprawdę duplikatami czy czy w tej praktyce są na przykład dwaj lekarze o tej samej nazwie i czy jest to duplikat, które dane wybrać, gdy oba rekordy się różnią, itp.).

Kluczem do udanej migracji jest planowanie. Przekonałem się, że planowanie (które obejmuje pisanie przypadków testowych i testów jednostkowych) zwykle zajmuje więcej czasu niż sam rozwój.

Kolejnym kluczem do udanej migracji danych jest kontrola jakości. To nie jest projekt do rzucenia w zespole ds. Kontroli jakości na dzień przed premierą. To nie jest projekt do uruchomienia, gdy QA stwierdzi, że jest problem.

Kolejnym kluczem do udanej migracji jest wdrożenie większości danych i przetestowanie ich podczas działania systemu pierwotnego. Jeśli przenosisz wiele rekordów, może to być czasochłonne i nastąpią nowe zmiany. Dlatego proces musi być w stanie wyciągnąć zmiany danych również po rozpoczęciu migracji. Na przykład SQL Server ma coś o nazwie Change Data Capture, które może w tym pomóc. Możesz zrobić kopię zapasową systemu oryginalnego i jednocześnie włączyć rejestrowanie zmian danych. Następnie możesz ponownie utworzyć kopię zapasową na serwerze migracji, przetestować migrację, pobrać większość danych, a następnie wystarczy załadować tylko zmienione rekordy. Podczas migracji ostatecznych rekordów wyłącz system źródłowy, aż migracja zostanie zakończona. Jest to jeden z powodów, aby migrować większość rekordów z wyprzedzeniem, więc aplikacja przestała działać przez jak najmniej czasu. Dobrze wybierz czas migracji, nie zamykaj systemu płac w dniu, w którym powinni przetworzyć listę płac lub wysłać W2. I rób to w niskich godzinach użytkowania. Jeśli masz wielu klientów, możesz rozważyć migrację jednego z nich i upewnienie się, że wszystko jest w porządku, zanim zrobisz inne. O wiele łatwiej jest przywrócić dane jednego klienta niż 10000, jeśli występuje problem. Ale jeśli to zrobisz, zaplanuj to dokładnie. s danych niż 10000, jeśli występuje problem. Ale jeśli to zrobisz, zaplanuj to dokładnie. s danych niż 10000, jeśli występuje problem. Ale jeśli to zrobisz, zaplanuj to dokładnie.

Jeśli migracja obejmuje nowy interfejs użytkownika, poproś rzeczywistych użytkowników, aby z niego korzystali w ramach testów migracji. Następnie przeszkol innych użytkowników, zanim zaczniesz korzystać z usługi na żywo (ale na mniej niż tydzień przed uruchomieniem usługi, inaczej zapomną). Poproś użytkowników zaangażowanych w testowanie o pomoc w zaprojektowaniu szkolenia, wiedzą, jakie pytania mieli i co ludzie powinni wiedzieć w jakiej kolejności. Uzyskaj ich dane wejściowe, dzięki czemu pole będzie wymagane, ponieważ uważasz, że nie powinno to pomóc, jeśli użytkownicy zwykle nie mają tych danych podczas wprowadzania rekordów. Po prostu włożą śmieci do nowo wymaganego pola, ponieważ w przeciwnym razie nie mogą uzyskać danych.

Spójrz, co jest nie tak z bieżącymi danymi, czy możesz dodać klucze obce, ograniczenia, wyzwalacze, reguły biznesowe w aplikacji, wartości domyślne itp., Aby uniknąć tego w przyszłości? Kiedy czyścisz złe dane, musisz również stworzyć sposób na uniknięcie przedostawania się tak samo złych danych w przyszłości. Przeanalizuj przyczyny złych danych i napraw dziury w projekcie.

Migracja danych jest koniecznością. Bez migracji danych często nie można iść naprzód. Wiele systemów, z którymi pracowałem, wymagało historii dostępnej tylko z wcześniejszych systemów. Migracja jest jedyną praktyczną metodą osiągnięcia tego celu. Jakość danych jest często problemem. Zasadniczo należy to rozwiązać w poprzednim systemie. Może to wymagać zmian danych w celu odzyskania jakości.

Inne systemy, z którymi pracowałem, zależały od danych z innych systemów. To inny, ale znaczący problem. W niektórych przypadkach dane można całkowicie zastąpić. Inne przypadki można lepiej rozwiązać, łącząc zmiany zawarte w nowych danych z istniejącym zestawem. Tego rodzaju migracje powinny obejmować sprawdzanie poprawności przychodzącego pliku danych.

Możliwość sprawdzania poprawności i czyszczenia istniejących danych może być ważną cechą systemu. Jest to niezależne od migracji. Często istnieją mechanizmy modyfikujące dane, które są poza kontrolą systemu. Może to spowodować, że dane staną się nieprawidłowe. Inne problemy z danymi wynikają z błędów w aplikacji. Okresowe uruchamianie procedur sprawdzania poprawności może pomóc w zidentyfikowaniu problemu i umożliwić wyczyszczenie danych, zanim nadejdzie czas migracji. Jak wspomniano wcześniejsze wyczyszczenie danych może ułatwić migrację.

Niektóre walidacje są zależne od czasu i nie powinny być stosowane do danych, które nie zostały zmodyfikowane. Jest to typowe dla wartości zakodowanych, w których kody zostały wycofane. Powinna istnieć możliwość zmiany innych pól w rekordzie bez wywoływania błędów sprawdzania poprawności. Może to sprawić, że sprawdzanie poprawności aktualizacji będzie bardziej skomplikowane, ponieważ musi określić, które pola zmieniły się przed sprawdzaniem poprawności. Walidacja między polami może być również bardziej złożona. Możliwość traktowania niektórych rekordów jako tylko do odczytu może w tym przypadku pomóc, ponieważ można uniknąć sprawdzania poprawności.

W jednym systemie, nad którym pracowałem, nowy system został częściowo odrzucony przez klienta. Odmówili zgody na użycie nowych modułów wprowadzania danych. Chcieli jednak przetwarzania wsadowego z nowego systemu. Rozwiązaniem była migracja danych co noc przed uruchomieniem wsadowym.

To zło konieczne. Byłem po obu stronach i to tylko niektóre z innych problemów, które jeszcze go spotęgowały.

1. Zwłaszcza w przedsiębiorstwie, kiedy firmy przechodzą na nowy system, chcą, aby robił wszystko, co zrobił stary system. Nie sprawdzają swoich procedur. Są tak przytłoczeni, że po prostu chcą robić wszystko tak samo. Jest to dla nich bezpieczne.
2. Nie poświęcają czasu na naukę nowego systemu lub zatrudniają ludzi z doświadczeniem.
3. Chcą dostosować nowy system tak, aby był zgodny z numerem 1 lub obsługiwał nowy aspekt swojej działalności. Nowe dostosowania systemu X X Przekształcone dane = Skomplikowane komplikacje
4. Na testowanie poświęcono zbyt mało czasu.
5. Klienci nie znoszą biegania równolegle / robienia rzeczy dwa razy. Nie można winić użytkowników, ponieważ nie mają czasu, aby to zrobić, ponieważ wszystkie inne obowiązki są wykonywane w pełni.

Jeśli Twoi menedżerowie mogą usprawiedliwić utratę sprzedaży, nie konwertując danych, zwiększ do nich siłę. Mówienie klientom, że wszystkie konwersje danych nie powiodą się, nie zadziała, ponieważ ktoś inny zawsze im to powie (zazwyczaj konkurencja).

Jakie są Twoje przemyślenia na temat migracji danych, szczególnie w rzeczywistych przypadkach, a nie tylko z perspektywy dewelopera?

oprogramowanie musi być regularnie aktualizowane. aby upewnić się, że migracja została zapisana, potrzebujesz kopii zapasowej i testowania.

Czy masz jakieś argumenty przeciwko opiniom moich menedżerów?

ma rację, że jest to ryzykowne. ale możesz dostosować techniki, aby było mniej ryzykowne.

Jak Twoja firma radzi sobie z migracjami danych i powodowanymi przez nie trudnościami?

mamy codzienną kopię zapasową, przyrostową kopię zapasową, kopię zapasową przed każdym wdrożeniem do produkcji. które przynajmniej pozwalają cofnąć się, jeśli wydarzy się coś złego.

mamy środowisko testowe, automatyczne testy i serwer do codziennej kompilacji. również procedura testu dymu, aby upewnić się, że główne operacje i funkcje działają poprawnie. Angażujemy programistów, kontrolę jakości i użytkowników w testowanie kompilacji (która migrowała dane).

używamy ruby ​​na szynach, który zapewnia wersjonowanie migracji danych, aktualizacji i wycofywania. co ułatwia nasze życie.

używamy capistrano do aktualizacji kodu i migracji danych. automatyzacja i prosta migracja jest kluczową sprawą, aby system produkcyjny działał.

Jakieś inne ciekawe myśli należące do tego tematu?

Innym problemem związanym z migracją danych jest spójność aktualizacji kodu i migracji danych. w moim przypadku ponownie używamy zautomatyzowanych sposobów radzenia sobie z tym. i zawsze gotowy do wycofania.

ręczne migrowanie danych może zmienić bazę danych w nieznany stan. i trudno jest porównać wersję migracji danych między różnymi środowiskami serwerowymi.

mam nadzieję, że to pomoże.

Nie marnujemy czasu na migrację danych ze starszych systemów, ponieważ czas, inwestycje i ryzyko są zbyt wysokie. Po prostu idziemy do przodu z nowszymi systemami i integrujemy w razie potrzeby.

Każda firma ma jakąś starszą wersję systemu, który musi obsługiwać, a to tylko normalny koszt prowadzenia działalności.

Nagroda, którą menedżerowie mają nadzieję zrealizować, powinna być wyjątkowo wysoka, biorąc pod uwagę koszty migracji.