Jedną rzeczą, którą możesz zrobić teraz , jest sprawdzenie, jakie zabezpieczenia są na miejscu. To pokazuje branie odpowiedzialności. Czy Twoja firma ma ostatnie kopie zapasowe na wypadek, gdyby coś poszło nie tak? Czy możesz tworzyć kopie zapasowe ad hoc przed zmianą krytycznych części? Czy pracujesz na systemach testowych i czy masz dobrą procedurę wdrażania zmian w systemach na żywo? Itd.

Jeśli tych zabezpieczeń brakuje, poproś o ich udostępnienie.

Przy okazji jestem zaskoczony, że mówisz, że pracujesz z danymi nieodwracalnymi . Jeśli tak jest w rzeczywistości, jest to czerwona flaga dla całej firmy. Nic (cóż, tak mało jak to możliwe) nie powinno być „nieodwracalne”.

Nigdy, przenigdy nie powinieneś modyfikować niemożliwych do odzyskania danych produkcyjnych.

Naprawdę nie mogę tego wystarczająco podkreślić. Powinieneś być gotów zająć w tej sprawie stanowisko. Gdybym to był ja, wystąpiłbym z dwoma żądaniami.

1. Częste tworzenie kopii zapasowych (najlepiej więcej niż jeden zestaw) wykonywane automatycznie. Częstotliwość zależy od wrażliwości danych, ale powiedziałbym, że przynajmniej raz dziennie. Czy klient będzie skłonny zaakceptować utratę danych z tygodnia, jeśli coś pójdzie nie tak?

2. Że to nie Ty to robisz. To jest właściwie ważniejsze, ale pierwsze powinno tak być. Ty, programista, nie powinieneś bawić się danymi na żywo. Nie znam wielkości Twojej firmy, ale pracuję w pięćdziesięcioosobowej firmie i programiści są informowani, jeśli wchodzą w interakcję z działającym systemem. Jeśli masz dział pomocy technicznej, to ich praca i nawet w przypadku kopii zapasowych powinieneś czuć się nieswojo, dotykając danych na żywo. Prace rozwojowe powinny być zawsze wykonywane tylko w systemie programistycznym. Jeśli trzeba coś zrobić z działającym systemem, każesz im to zrobić, nawet kosztem wydajności. Jeśli potrzebujesz, dostarcz dobrze przetestowany skrypt. Generalnie jednak wszelkie zmiany powinny nastąpić tylko wtedy, gdy wszyscy są świadomi, że system może się zepsuć, więc klienci muszą być świadomi tej możliwości. Jeśli jako programista musisz dotykać danych na żywo, nie rób tego bez kopii zapasowych, nawet czegoś małego.

Te rzeczy są dość podstawowe. Zawsze należy brać pod uwagę potencjalne skutki błędów i robić wszystko, co możliwe, aby zminimalizować to ryzyko. Może się to wydawać zbyt ostrożne, ale jeśli nie podejmiesz środków ostrożności, osobiste konsekwencje będą znacznie większe, jeśli coś pójdzie nie tak.

Przed wykonaniem jakiejkolwiek pracy, która może spowodować utratę danych, upewnij się, że masz plan wycofywania. Zwykle oznacza to wykonanie ręcznej kopii zapasowej bazy danych przed uruchomieniem jakiegokolwiek skryptu sql, który zmienia dane. Jest to część Twojej odpowiedzialności jako osoby wykonującej pracę.

Następnym razem, gdy zostaniesz poproszony o wykonanie takiej pracy, poinformuj swojego przełożonego, że zamierzasz wykonać kopię zapasową bezpośrednio przed wykonaniem zmiana.

Uwaga boczna: Zawsze przydatne jest dołączanie skryptów sql do BEGIN TRANSACTION. ROLLBACK TRANSACTION po raz pierwszy uruchamiasz je na danych produkcyjnych. Spowoduje to wykonanie skryptu i wyświetlenie danych wyjściowych bez faktycznego stosowania zmian. To daje dobre wskazanie, ile rekordów zostanie zmienionych i czy wystąpią jakieś błędy.

Ryzyko organizacyjne i indywidualne badanie due diligence

Co mam zrobić, jeśli omyłkowo usunę jakieś cenne dane? Ręcznie (za pomocą skryptów SQL) przenoszę rzeczy w bazie danych tu i tam.

Kwestia, czy firma postępuje właściwie, wprowadzając zmiany w danych produkcyjnych, które nie mają Kopie zapasowe to tak naprawdę decyzja biznesowa, która wykracza poza twoją płatność. Chociaż z pewnością możesz zalecić, aby tego nie robili ze względu na ryzyko, byłbym bardzo zdziwiony, gdyby nie byli jeszcze świadomi zagrożeń i uznali je za akceptowalne ryzyko dla firmy w porównaniu z kosztami zrobienia czegoś systemowego. .

Ze swojej strony powinieneś wykonać własne pełne lub częściowe kopie zapasowe przed wprowadzeniem zmian. Chociaż tworzenie kopii zapasowej całego systemu może być niepraktyczne, z pewnością możesz zrzucić rekordy, które planujesz zmienić, lub pliki konfiguracyjne, które planujesz zmodyfikować, aby móc je przywrócić w przypadku błędu.

To nie ochroni przed katastrofalnymi awariami (np. upuszczeniem całej bazy danych, na przykład), ale z pewnością zapewni, że jeśli wprowadzisz zmiany do rekordu 12345, możesz przywrócić ten rekord po wprowadzeniu zmian, jeśli okaże się, że zmiany były nieprawidłowe.

Pamiętaj tylko, że chociaż jesteś profesjonalistą odpowiedzialnym za zwrócenie uwagi kierownictwa na ryzyko i łagodzenie go tak dobrze, jak jesteś w stanie we własnym pracy, zespół zarządzający Twojej organizacji faktycznie ponosi 100% ryzyka biznesowego. Jeśli zrobiłeś swoją należytą staranność najlepiej jak potrafiłeś, wszelkie pozostałe ryzyko spoczywa na organizacji, a nie na tobie.

W razie wypadku ...

W przypadku, gdy coś się stanie pójdzie nie tak, Twoim zawodowym obowiązkiem jest natychmiastowe poinformowanie o tym kogoś z władz. Powinieneś poinformować ich, co się stało, jakie dane zostały utracone, co (jeśli w ogóle) jesteś w stanie odzyskać i zaoferować pomoc we wszelkich dodatkowych działaniach, które mogą być potrzebne.

Tego rodzaju błędy nie powinny być zakryte. Jednakże, chociaż powinieneś przyznać się do wszelkich popełnionych błędów lub błędów, pamiętaj, że odpowiedzialność za posiadanie systemu bez odpowiednich zabezpieczeń jest ryzykiem, które należy do organizacji, a nie do Ciebie. Weź odpowiedzialność za swój udział w wypadku, ale nie miej winy za awarię systemu bez odpowiednich zabezpieczeń.

Istnieje duża różnica między przejęciem odpowiedzialności a wzięciem winy. Upewnij się, że akceptujesz tylko to pierwsze, a nie drugie, chyba że naprawdę zrobiłeś coś niedbałego.

W jednym są właściwie dwa pytania:

• kto powinien być odpowiedzialny za zmiany w danych produkcyjnych?
• jak najlepiej wprowadzić te zmiany?

Pozwól, że odniosę się do nich osobno.

Kto powinien być odpowiedzialny za zmiany w danych produkcyjnych?

Żadnej pojedynczej osoby.

Jaki jest sposób przeprowadzania zmiany; zmiana w produkcji (lub jakimkolwiek wrażliwym systemie) powinna zostać sprawdzona przez przynajmniej inną (znającą się na rzeczy) osobę i zatwierdzona przez jakiegoś kierownika.

Jest to praca zespołowa i przestrzeganie łańcucha odpowiedzialności. W tym momencie nie ma znaczenia, czy popełnisz błąd:

1. Zostanie zastosowany tylko wtedy, gdy ktoś inny przejrzał go (i nie zauważył problemu)
2. Zostanie zastosowana tylko wtedy, gdy jakiś menedżer ją zatwierdzi (i wziął na siebie odpowiedzialność)

Jeśli żaden menedżer nie jest skłonny wziąć odpowiedzialności za zmianę, nie wykonuj jej.

Jeśli ludzie spierają się o wrażliwość zmiany na czas, powiedz im, że nigdy nie należy mylić bycia szybkim z pośpiechem . Właściwie opowiadałbym się za dodatkową ostrożnością w nagłych przypadkach (na przykład inny recenzent), szczególnie dlatego, że ciśnienie zwiększa ryzyko błędów. O wiele szybciej jest mieć rację za pierwszym razem niż zepsuć wszystko, posprzątać bałagan i w końcu dokonać zmiany.

Jak najlepiej wprowadzić te zmiany?

Idealnie :

• kopia zapasowa jest dostępna i jest procedura przywracania
• zmiana jest wykonywana za pomocą skryptu, któremu towarzyszy sprawdzony (*) skrypt awaryjny.

Niestety, warunki nie zawsze są idealne.

Kopie zapasowe są dobre, ale w środowisku na żywo, w którym dane zmieniają się co sekundę, po prostu nie jest możliwe zapewnienie ich dokładnej aktualności; Kopie zapasowe mogą być używane tylko w przypadku ogromnego błędu i po zaakceptowaniu, że najnowsze zmiany zostaną utracone. Dlatego nie mogę wystarczająco nalegać na skrypty zmian i sprawdzenie, czy skrypt awaryjny działa zgodnie z przeznaczeniem.

Niektórych zmian nie można cofnąć. Na przykład podczas usuwania kolumny danych w tej kolumnie nie można przywrócić w przypadku problemu. Te zmiany należy wykonać dwuetapowo:

• w pierwszym kroku wyłącz dostęp do fragmentu danych, który zostanie usunięty, bez faktycznego usuwania go; w przypadku kolumny zmień jej nazwę na przykład. Ten krok można cofnąć.
• następnie, gdy zostanie ocenione, że zmiana była ważna (minęło kilka dni lub tygodni bez problemów), wykonaj nienadającą się do upadku zmianę w skrypcie przeznaczonym do jednego celu

(*) Aby zweryfikować skrypt awaryjny, musisz uruchomić go na kopii prawdziwej bazy danych, a następnie zastosować skrypt awaryjny i sprawdzić, czy dane wróciły do ​​normy.

(*) Widziałem sugestię zrobienia zmiany w transakcji; jest to niewystarczające (co jeśli zdasz sobie sprawę z błędu po zatwierdzeniu?), podatne na rywalizację (blokujesz wszystkie zmodyfikowane wiersze do momentu zatwierdzenia) i nie zawsze możliwe (zbyt duży zestaw zmian / ryzyko zakleszczeń). Mimo to, jeśli to możliwe, używaj transakcji w skrypcie, ponieważ połowiczne zmiany są trudniejsze do cofnięcia.

Jeśli utkniesz w tym systemie (i poważnie bym to odrzucił, ponieważ jest to skrajnie ryzykowne i kiepska praktyka), oto co bym zrobił.

Najpierw utwórz kopię zapasową tabeli dla dane, na które masz zamiar mieć wpływ (mamy bazę danych do jednorazowego użytku). W oczekiwaniu na jeden rozmiar danych możesz chcieć utworzyć indeks na ten temat)

Gdy masz już kopię zapasową tabeli, umieść wszystko w transakcji. Następnie, gdy wykonujesz zapytanie, aby wpłynąć na łączenie danych w utworzonej tabeli kopii zapasowej.

Po uruchomieniu uruchamiaj po jednym kroku i zanotuj, ile rekordów znajduje się w tabeli pomostowej, jeśli dane dotyczą w zapytaniu funkcjonalnym nie odpowiada liczbie rekordów w tabeli, będziesz chciał wycofać zmiany, a następnie dowiedzieć się, dlaczego.

Takie podejście zapewnia również największą elastyczność przywracania, jeśli zmiana była zła, ponieważ łatwiej i ogólnie szybciej zaktualizować jedną tabelę do starych wartości niż przywrócić całą bazę danych. A jeśli tylko kilka rekordów zostało błędnie zmienionych, masz możliwość przywrócenia starych wartości tylko w tych rekordach.

Alternatywą dla tego wszystkiego jest posiadanie tabel audytu, które rejestrują wszystkie zmiany. Jednak jest mało prawdopodobne, abyś je miał, jeśli deweloperzy pracują bezpośrednio na produkcji. Osobiście nigdy nie rozważałbym posiadania bazy danych bez przeprowadzania audytu, ponieważ wspaniale jest naprawiać błędy, które pochodzą z interfejsu użytkownika, a także importować dane i skrypty akcji ad hoc, które są uruchamiane w bazie danych, w tym w przypadku złośliwej zmiany danych. ale pracuję w środowisku regulacyjnym, w którym jest to wymagane.

Dodane później Zapomniałem wspomnieć, niech ktoś inny sprawdzi kod, zanim to zrobisz.

Jestem pewien, że wiesz o tym, ale i tak zwrócę uwagę na oczywiste: przetestuj, przetestuj i zrób więcej testów. Jest tak wiele rzeczy, które mogą się nie udać, jeśli nie przeprowadzisz odpowiednich testów, a jednym z wielu jest przypadkowe usunięcie danych. Naśladując środowisko produkcyjne rzeczywistymi danymi, możesz testować w środowisku, które jest realistyczne i ograniczać liczbę błędów i błędów do minimum.

Pamiętaj, że nawet po wielu godzinach intensywnych testów błędy nie i stanie się . Jeśli tak, zgłoś się do swojego przełożonego / kierownika i wyjaśnij. Jeśli w jakikolwiek sposób twój kod zamknie połączenie z bazą danych, miliony rekordów, które powinny zostać wstawione, znikną (ale to tylko przykład). Jeśli zauważysz błąd lub podejrzewasz błąd: poinformuj innych o tym .

Jeśli musisz zrobić WSZYSTKO w systemie produkcyjnym, zrób to w transakcji. (Lub pozwól administratorowi to zrobić, jeśli go masz)

Wiele lat temu widziałem przerażoną minę mojego szefa, który przeprowadzał „prostą” aktualizację produkcyjnej bazy danych, bez WHERE .

Gdyby wykorzystał transakcję, mógłby wydać ROLLBACK i oszczędzić sobie spanikowanej nocy odzyskiwania danych z kopii zapasowej do nadal działającego systemu produkcyjnego. (Cofnięcie zajęłoby dwie sekundy, a nie cztery godziny ...)

(To brzmi jak kreskówka Scotta Adamsa, ale tak, faktycznie to widziałem ...)

Innym prostym sposobem uniknięcia katastrofalnych błędów jest przyzwyczajenie do dodawania instrukcji limitu (np. limit 1; jeśli zmieniasz tylko jeden rekord).

Więc jeśli modyfikujesz coś takiego jak tabela użytkowników, nawet jeśli zapomnisz klauzuli WHERE, jak zrobił to szef @tima, zepsujesz tylko jeden rekord użytkownika, a nie każdy rekord użytkownika.