Dobre procesy do debugowania środowiska produkcyjnego? Kopiowanie danych do Dev?

Question

Myślałem o tym trochę. Chodzi o to, że w PROD coś poszło nie tak. Przechwycone dane powodują, że aplikacja internetowa zachowuje się inaczej niż w innych środowiskach. Tak więc dane w innych środowiskach nie są zsynchronizowane z prod (zgodnie z oczekiwaniami). Jednak pojawia się błąd i z jakiegoś powodu dzieje się tak tylko w PROD, prawdopodobnie z powodu różnic w danych.

Zastanawiam się, co jest dobrą praktyką, aby zaradzić tego rodzaju problemom? Z pewnością więcej testów. Ale poza tym? Można stworzyć nowe dane w dev, ale chodzi o to, że niektóre dane wskazują, lub niektóre kombinacje działań powodują, że punkt danych jest błędny. Być może podczas korzystania z jakiegoś innego źródła danych, aby dotrzeć do "faktycznego" punktu danych, który jest inny niż "oczekiwany" punkt danych. Przeprasza, że ​​nie jest to świetny opis i stara się być zarówno przykładem, jak i definicją ogólnego błędu produkcyjnego.

Wiem, że to nie jest bardzo precyzyjne pytanie. Mamy nadzieję, że istnieją referencje, które zawierają dobre sugestie.

Answer 1

To bardzo interesujące pytanie. Jedną z metod, które stosowałem wcześniej, jest celowe przeprowadzanie testów końcowych w produkcji (TIP).

Przed szpikulec moją podobiznę z wieloma igłami spiczastych, wysłuchaj mnie przez chwilę, a ja mówić o ciągłym rozmieszczenia :-)

Chodzi o to, aby wdrożyć nowy build do produkcji, a następnie użyć niestandardowego routingu do kierowania ruch między starymi i nowymi wersjami produkcyjnymi. Zasadniczo jest to bardzo proste: zacznij od przekierowania starej wersji do obecnych klientów, a nowej do swojego zespołu inżynierów. Twoi klienci nie widzą żadnych zmian. Ale Twój zespół może rozpocząć testowanie nowej wersji, w tym niechlujstwa, takie jak odtwarzanie po awarii i testy warunków skrajnych. Miejmy nadzieję, że odkryjesz rodzaj błędów, o których mówisz w swoim pytaniu.

Jeśli wystąpi problem, po prostu wycofaj nową kompilację. Jeśli twoje testy nie napotkają problemu, wypuszczasz na rynek 5% swojej bazy klientów. Następnie 10% i 20% i tak dalej.

Chociaż z zasady są proste, są pewne kwestie, które trzeba zaplanować od samego początku. Pierwszym z nich są schematy danych i danych, które muszą działać poprawnie zarówno w starych, jak i nowych kompilacjach. Tak długo, jak usługi używane przez twoją aplikację internetową są zaprojektowane do obsługi przynajmniej jednego wycofania po wdrożeniu nowej wersji, a twoja nowa kompilacja rozumie zarówno stare, jak i nowe dane, powinieneś być w porządku.

Drugi problem to zmiany interfejsu API/interfejsu. Zamiast edytować lub usuwać metody lub parametry, musisz utworzyć nowy interfejs API/interfejs, który przeważnie przekierowuje do starego interfejsu API/interfejsu, z wyjątkiem nowego/zmienionego kodu.

Inne problemy, w tym niezgodne zmiany w konfiguracji i ustawieniach między kompilacjami. Zagadnienia te nie są krytyczne, ale musisz wcześniej przeprowadzić pewne planowanie i testy. Wielką nagrodą jest to, że możesz bezpiecznie testować swój kod w produkcji bez wpływu na klientów.

Niektóre linki na testach w produkcji:

• There's no place like production
• The future of software testing
• Production is a mixed blessing
• TIP - malpractice?
• TIP really happens
• Why TIP isn't as stupid as it sounds