Występują błędy i czasami dane muszą zostać naprawione podczas produkcji. Jak najbezpieczniej to zrobić z punktu widzenia dużej firmy? Czy istnieją narzędzia, które mogą pomóc? Oto kilka uwag dotyczących tego wymogu ...
- Musimy się zalogować, kto uruchomił zapytanie i co uruchomili
- Idealnie powinniśmy dać tej osobie dostęp do uruchamiania zapytań tylko na podstawie tabel zainteresowań i tylko przez krótki czas
- Cokolwiek jest uruchomione, zapytania muszą mieć pewne sprytne rozwiązania, aby nie pozwalały na długi czas działania i blokowanie SQL bez wyraźnego pozwolenia
- Ten proces musi być niezależny od DB lub przynajmniej rozumieć DB2, Oracle i SQL Server.
Staramy się zmniejszyć ryzyko zapytań o naprawę produktu ad-hoc przed zrobieniem „niewłaściwej rzeczy” i jednocześnie dodać do procesu pewne zabezpieczenia / audyty. Myśli czy pomysły?
Odpowiedzi:
Nigdy nie aktualizuj ręcznie produkcyjnych baz danych.
Pisz skrypty.
Potrójnie je sprawdź i niech zrobi to wiele osób, a nie tylko jedna osoba trzy razy.
Uwzględnij w tych skryptach zapytania sprawdzające poprawność po zmianie.
Ilekroć pozwala na to sytuacja, przetestuj całą zmianę w ramach transakcji, która jest wycofywana na końcu, po uruchomieniu sprawdzania poprawności po zmianie. Gdy będziesz pewny wyników, zmień wycofanie na zatwierdzenie.
Przetestuj te skrypty ad nauseam w testowej bazie danych.
Wykonaj kopię zapasową przed uruchomieniem skryptu dla produkcyjnej bazy danych.
Uruchom skrypty.
Sprawdź, zweryfikuj i potrójnie sprawdź zmienione dane za pomocą skryptów sprawdzających poprawność po zmianie.
Zresztą sprawdź wizualnie.
Jeśli coś wydaje się wyłączone, wycofaj się i przywróć kopię zapasową.
Nie zmieniaj danych jako danych produkcyjnych, dopóki nie masz absolutnej pewności, że wszystko jest w porządku i nie wypisałeś się z zaangażowanych menedżerów (biznesowych).
źródło
WHEREa baza danych pozostanie wyłączona przez resztę dnia. Lub tydzień.Odpowiedź Marjana Venemy jest technicznie ważna i powinna być przestrzegana, jeśli to możliwe. Niestety, Marjan odpowiada z punktu widzenia teoretyka lub purystycznego administratora bazy danych, który lubi robić wszystko czysto. W praktyce czasami ograniczenia biznesowe uniemożliwiają robienie rzeczy w czysty sposób.
Wyobraź sobie następujący przypadek:
W oprogramowaniu występuje błąd, który powoduje, że przestaje on działać, gdy wykryje coś, co uważa za niespójność danych w bazie danych,
Wszyscy programiści, którzy potencjalnie mogą naprawić błąd w aplikacji, są nieosiągalni,
Firma traci obecnie tysiące dolarów na godzinę (powiedzmy 6000 $, co oznacza 100 $ za minutę),
Błąd dotyczy kilku tabel, z których jedna jest ogromna i dotyczy tylko samych danych, a nie schematu,
Aby obejść błąd, powinieneś trochę poeksperymentować z danymi, co obejmuje zarówno usunięcie, jak i zmianę,
Baza danych jest duża i wykonanie lub przywrócenie kopii zapasowej zajęłoby trzy godziny,
Ostatnia pełna kopia zapasowa została zrobiona trzy tygodnie temu; istnieją również codzienne przyrostowe kopie zapasowe, a ostatnia dzienna przyrostowa kopia zapasowa została wykonana 14 godzin temu,
Kopie zapasowe bazy danych są uznawane za wiarygodne; zostały poważnie przetestowane, w tym niedawno,
Utrata 14 godzin danych jest nie do przyjęcia, ale utrata jednej do dwóch godzin danych to:
Środowisko przejściowe zostało ostatnio użyte sześć miesięcy temu; wygląda na to, że nie jest aktualne, a konfiguracja może potrwać kilka godzin,
Baza danych to Microsoft SQL Server 2008 Enterprise.
Czysty sposób na robienie rzeczy to:
Przywróć kopię zapasową w środowisku pomostowym,
Eksperymentuj tam
Sprawdź ostatni skrypt dwa razy,
Uruchom skrypt na serwerze produkcyjnym.
Już pierwszy krok będzie kosztował 18 000 USD dla Twojej firmy. Ryzyko jest dość niskie, jeśli wykonasz trzeci krok bezbłędnie, ale ponieważ pracujesz pod ekstremalną presją, ryzyko byłoby znacznie wyższe. Możesz skończyć ze skryptem, który sprawdził się doskonale w tworzeniu scen, a następnie zepsuć produkcyjną bazę danych.
Zamiast tego mogłeś zrobić tak:
Utwórz migawkę (Microsoft SQL Server to obsługuje, a cofnięcie (i nic nie można utworzyć) migawki bazy danych zajmuje godzinę, a wykonanie kopii zapasowej zajmuje godzinę; wyobrażam sobie, że inne produkty bazy danych również obsługują migawki),
Eksperymentuj bezpośrednio na produkcyjnej bazie danych, przywracając migawkę, jeśli coś pójdzie nie tak.
Podczas gdy purysta naprawiłby bazę danych w czysty sposób i nadal miałby ryzyko popsuć wszystko, biorąc pod uwagę presję czasu i marnując ponad 20 000 USD na swoją firmę, administrator bazy danych, który bierze pod uwagę ograniczenia biznesowe, naprawi bazę danych w pewien sposób co zminimalizuje ryzyko (dzięki migawkom), robiąc to szybko.
Wniosek
Sam jestem purystą i nienawidzę robić rzeczy w nieczysty sposób. Jako programista zmieniam kod, który modyfikuję, komentuję trudne części, których nie można refaktoryzować, testuję jednostkę kodu i przeprowadzam recenzje kodu. Ale biorę również pod uwagę okoliczności, w których albo robisz wszystko czysto i następnego dnia jesteś zwolniony, albo minimalizujesz zarówno ryzyko, jak i wpływ finansowy, wykonując szybki hack, który działa.
Jeśli jakiś informatyk chce robić rzeczy czysto tylko ze względu na czystość, podczas gdy powoduje to tysiące dolarów straty dla firmy, ten informatyk ma głębokie niezrozumienie swojej pracy.
źródło
Jest to zła praktyka i brama zaproszeń na więcej problemów z danymi i problemów. Istnieje nawet fraza, która opisuje to podejście jako „ szybkie i brudne ”.
Kontynuowanie poprawek / aktualizacji bezpośrednio na serwerze produkcyjnym jest bardzo niebezpieczne , ponieważ będzie kosztować Ciebie / Twoją firmę fortunę ( sprawy sądowe, złe / brudne dane, utracone firmy itp. )
Błędy będą jednak dostępne i muszą zostać naprawione. De facto przemysłowym standardem jest stosowanie plastrów / (skrypty wdrażania) na Wystawienie (środowisko pre-produkcja z najnowszej kopii bazy prod) i niech dane analityk / QA zweryfikować poprawkę. Ten sam skrypt należy kontrolować wersję i stosować w środowisku Prod, aby uniknąć problemów.
Istnieje wiele dobrych praktyk wymienionych w tej powiązanej dobrej praktyce bazy danych po przemieszczeniu
Dobry zestaw odnośników do wyglądu to:
źródło
W większości organizacji pracowałem nad aktualizacją danych w środowisku na żywo, zawsze przez małą grupę osób posiadających do tego prawa dostępu, zazwyczaj z tytułem pracy, takim jak DBA. Ponieważ aktualizacje mogą być wykonywane tylko przez niewielką liczbę osób, istnieje co najmniej szansa, że zapoznają się z danymi, a tym samym zmniejszą (ale nie wyeliminują) ryzyko problemów.
Osoba pisząca skrypt aktualizacji zrobiłaby to w teście (zgodnie z innymi odpowiedziami) i otrzymała poważne potwierdzenie od nietechnicznych (tych, którzy znają system, a także kogoś z wyższym autorytetem), że funkcje wydają się „znowu właściwe” w dodatek do własnych testów paranoicznych. Skrypty i dane byłyby niezależnie sprawdzane przez innego technika (często o roli DBA, o której wspomniałem) podczas testów przed uruchomieniem do produkcji. Wyniki byłyby porównywane z przewidywanymi wartościami (unikalne dla każdego scenariusza, ale często rzeczy takie jak liczba wierszy itp.)
W jednej firmie, dla której pracowałem, tworzenie kopii zapasowych nie było realistyczną opcją, ale wszystkie wiersze do aktualizacji zostały spisane do pliku tekstowego w celach informacyjnych PRZED aktualizacją, a następnie PO aktualizacji, jeśli ktokolwiek będzie chciał się do niej odwołać. Skrypty i te dane przechowywane są w odpowiednio zorganizowanym dzienniku zmian danych.
Każda firma jest wyjątkowa, a ryzyko związane z aktualizacją niektórych danych jest wyraźnie większe niż w innych.
Mając proces, który sprawia, że ludzie muszą przeskakiwać przez obręcze, aby wykonać te aktualizacje, mam nadzieję, że promujesz kulturę, która sprawia, że ludzie chcą traktować to jako ostateczność i stworzyć zdrowe podejście do „podwójnej kontroli, potrójnej kontroli” wokół tych rzeczy.
źródło
Są chwile, kiedy musisz naprawić dane w Prod, które nie istnieją na innych serwerach. Nie wynika to wyłącznie z błędów, ale może pochodzić z importu danych z pliku, który klient wysłał niepoprawnie, lub z problemu spowodowanego przez włamanie się do twojego systemu. Lub z powodu problemu spowodowanego złym wprowadzeniem danych. Jeśli Twoja baza danych jest duża lub ma krytyczne znaczenie dla czasu, możesz nie mieć czasu na przywrócenie najnowszej kopii zapasowej i naprawienie oprogramowania.
Pierwszą obroną (i czymś, na co nie stać bazy danych Enterprise!) Są tabele kontroli. Możesz ich użyć do wycofania złych zmian danych. Ponadto możesz pisać skrypty, aby przywrócić dane do poprzedniego stanu i przetestować je na innych serwerach na długo przed cofnięciem kontrolowanych danych. Jedyne ryzyko polega na tym, że zidentyfikowałeś prawidłowe rekordy do przywrócenia.
Następnie wszystkie skrypty zmieniające dane dotyczące produkcji powinny zawierać następujące elementy:
Powinny być w jawnych transakcjach i mieć blok TRY Catch.
Powinny mieć tryb testowy, którego można użyć do wycofania zmian po tym, jak zobaczysz, co by to było. Powinieneś mieć wybraną statystykę przed dokonaniem zmiany i jeden przebieg po zmianie, aby upewnić się, że zmiana była poprawna. Skrypt powinien upewnić się, że wyświetlana jest liczba przetworzonych wierszy. Niektóre z tych ustawień są wstępnie skonfigurowane w szablonie, który zapewnia wykonanie części. Szablony zmian pomagają zaoszczędzić czas na pisaniu poprawki.
Jeśli istnieje duża ilość danych do zmiany lub aktualizacji, zastanów się nad napisaniem skryptu, aby działał partiami z zatwierdzeniami dla każdej partii. Nie chcesz blokować całego systemu podczas naprawy miliona rekordów. Jeśli masz duże ilości danych do naprawienia, upewnij się, że dba lub ktoś, kto jest przyzwyczajony do dostrajania wydajności, sprawdza skrypt przed uruchomieniem i działa w godzinach wolnych od pracy, jeśli to w ogóle możliwe.
Następnie wszystkie skrypty do zmiany czegokolwiek w produkcji są sprawdzane pod kątem kodu i poddawane kontroli źródła. Wszystkie - bez wyjątku.
Wreszcie deweloperzy nie powinni uruchamiać tych skryptów. Powinny być uruchamiane przez dbas lub grupę zarządzania konfiguracją. Jeśli nie masz żadnego z nich, tylko osoby, które są liderami technologicznymi lub wyższymi, powinny mieć prawo do uruchamiania różnych produktów. Im mniej osób uruchamia rzeczy na prod, tym łatwiej jest wyśledzić problem. Skrypty powinny być pisane w taki sposób, aby były po prostu uruchamiane, bez wyróżniania części i uruchamiane krok po kroku. To podkreślanie często sprawia kłopoty ludziom, gdy zapomnieli zwrócić uwagę na klauzulę where.
źródło
Wiele razy aktualizowałem dane w uruchomionych produkcyjnych bazach danych. Zgadzam się z powyższą odpowiedzią, że nigdy nie byłaby to standardowa procedura operacyjna.
Byłoby to również kosztowne (spojrzeliśmy sobie na ramiona i omawialiśmy może 2 lub 3)
I złota zasada: zawsze wykonuj instrukcję select, aby pokazać, co będzie zrobione przed wykonaniem instrukcji update / delete / insert
Złota zasada jest egzekwowana przez pozostałe dwie osoby w zespole!
źródło
re: odpowiedź MainMa ...
źródło