Jak testować i optymalizować, kiedy nie można odtworzyć środowiska?

W przeszłości pracowałem w różnych środowiskach. Aplikacje komputerowe, gry, osadzone rzeczy, usługi sieciowe, zadania wiersza poleceń, strony internetowe, raportowanie baz danych i tak dalej. Wszystkie te środowiska miały tę samą cechę: bez względu na ich złożoność, bez względu na ich rozmiar, zawsze mogłem przetestować podzbiór lub fragment aplikacji na moim komputerze lub w środowisku programistycznym.

Dzisiaj nie. Dzisiaj znajduję się w środowisku, którego głównym celem jest skalowalność. Reprodukcja środowiska jest wyjątkowo kosztowna. Biorąc kawałek środowiska, chociaż jest to wykonalne (niektóre elementy musiałyby zostać zasymulowane lub użyte w trybie pojedynczej instancji, do którego nie zostały stworzone), w pewnym sensie pokonuje cel, ponieważ przesłania współbieżność i ładuje to napotyka prawdziwy system. Nawet mały system „testowy” ma swoje wady. Będzie inaczej w przypadku 2 węzłów i 64 węzłów.

Moje zwykłe podejście do optymalizacji (mierzenie, próbowanie czegoś, weryfikowanie poprawności, mierzenie różnic, powtarzanie) tak naprawdę nie działa tutaj, ponieważ nie mogę skutecznie wykonać kroków 2 i 3 dla części problemu, które mają znaczenie (odporność na współbieżność i wydajność w ramach Załaduj). Ten scenariusz nie wydaje się jednak wyjątkowy. Jakie jest typowe podejście do wykonywania tego rodzaju zadań w tego rodzaju środowisku?

Istnieje kilka powiązanych pytań:

• to pytanie dotyczy niedostępności sprzętu (takiego jak analizatory widma), który można (względnie) łatwo emulować.
• to pytanie dotyczy śledzenia błędów, które istnieją tylko w środowiskach produkcyjnych, co jest pomocne - ale innego rodzaju działania.

Właściwie to trudne, ale jestem pewien, że w wielu porównywalnych sytuacjach jest to przede wszystkim problem organizacyjny. Jedynym realnym podejściem jest prawdopodobnie połączenie połączonych środków, a nie tylko „jednej srebrnej kuli”. Niektóre rzeczy, których możesz spróbować:

• rejestrowanie: jak już pisałem w komentarzu, nadmierne rejestrowanie czasu i zasobów (co jest rodzajem profilowania) może pomóc w zidentyfikowaniu prawdziwych wąskich gardeł w produkcji. To może nie powiedzieć, czy alternatywna implementacja będzie działać lepiej, ale z pewnością pomoże ci uniknąć optymalizacji całkowicie niewłaściwej części twojej aplikacji.

• przetestuj to, co możesz przetestować wcześniej - dokładnie, z dużym planowaniem z góry. Jasne, rzeczy będą się zachowywać inaczej w produkcji, ale nie wszystkie rzeczy. Prawidłowość innej implementacji często można wcześniej sprawdzić - jeśli implementacja dobrze się skaluje, to inna kwestia. Ale planowanie może bardzo pomóc. Zastanów się, jakie problemy Twoje środowisko testowe może dla Ciebie rozwiązać, a które nie. Prawie zawsze są rzeczy, w których na pierwszy rzut oka uważasz, że „nie można tego wcześniej przetestować”, ale jeśli pomyślisz dwa razy, często jest to możliwe.

• Pracuj jako zespół. Wypróbowując nowe podejście lub pomysł, przedyskutuj je z co najmniej jedną inną osobą z zespołu. Kiedy wdrażasz inne algo, nalegaj na kontrole kodu i kontrolę jakości. Im więcej błędów i problemów możesz wcześniej uniknąć, tym mniej poważne problemy będziesz musiał rozwiązać podczas produkcji.

• Ponieważ nie można wszystkiego wcześniej przetestować, należy spodziewać się problemów z produkcją. Dlatego staraj się przygotować naprawdę dobrą strategię awaryjną przy wprowadzaniu nowego kodu do produkcji. Jeśli istnieje ryzyko, że Twój nowy kod działa wolniej niż stare rozwiązanie lub istnieje ryzyko awarii, upewnij się, że możesz przejść do poprzedniej wersji JAK NAJSZYBCIEJ. Jeśli istnieje ryzyko zniszczenia danych produkcyjnych, upewnij się, że masz dobre kopie zapasowe / odzyskiwanie. I upewnij się, że wykryłeś takie awarie, dodając mechanizm sprawdzania poprawności do swojego systemu.

• prowadzić dziennik projektu lub dziennik rozwiązań - poważnie. Każdego dnia dowiadujesz się czegoś nowego na temat środowiska, spisujesz - historie sukcesu, a także porażki. Nie popełniaj dwukrotnie tego samego niepowodzenia.

Więc sedno jest takie - gdy nie możesz przejść do prób i błędów, najlepszą opcją jest konserwatywne, klasyczne planowanie z góry i techniki zapewniania jakości.

Jeśli nie możesz odtworzyć środowiska na żywo, niewygodną rzeczywistością jest to, że cokolwiek robisz, nie zostanie wystarczająco przetestowane.

Więc co możesz zrobić?

Cóż, bez względu na skalę, czy to proces, klaster serwerów czy wolumin bazy danych powinien być testowany z uwzględnieniem zasady zero, jeden, nieskończoności , aby wyeliminować potencjalne wąskie gardła / ograniczenia, takie jak IO, procesory, obciążenie procesora, inter -proces komunikacji itp.

Gdy to zrobisz, powinieneś sprawdzić, na jaki rodzaj testów ma to wpływ. Jeśli chodzi o testy jednostkowe, to tradycyjnie spoczywa na deweloperze, jeśli jest to testowanie integracji / systemu, mogą istnieć punkty kontaktowe z innymi zespołami, które mogą być w stanie pomóc z dodatkową wiedzą specjalistyczną lub jeszcze lepiej narzędziami.

Mówiąc o narzędziach, nie jest tak naprawdę zadaniem programisty ładowanie testu systemu poza to, co jest możliwe w jego środowisku programistycznym. Powinno to zostać przekazane do działu testowego lub innej strony trzeciej.

Słoń w pokoju oczywiście polega na tym, że systemy nie zawsze skalują się w przewidywalny sposób!

W poprzednim życiu byłem DBA dla bankowych baz danych z miliardami wierszy i uzbrojony w plany wykonania mogliśmy ogólnie przewidzieć, jak długo zapytania przyjmą bezczynną bazę danych, biorąc pod uwagę wolumeny wejściowe. Jednak gdy woluminy te osiągną pewien rozmiar, plan wykonania zmieni się, a wydajność gwałtownie spadnie, chyba że zostanie dostrojone zapytanie / baza danych.

Sugerowałbym eksperymenty.

Rejestrowanie znajdzie wąskie gardła. Następnie możesz wypróbować alternatywną implementację na niektórych komputerach, a nawet na wszystkich komputerach z pewnym prawdopodobieństwem lub przez ograniczony czas. Następnie ponownie porównaj dzienniki, aby sprawdzić ulepszenia.

Jest to ten sam cykl teoretyczno-eksperymentalno-pomiarowy, do którego przywykłeś, ale jego konfiguracja jest droższa - ponieważ hipotezy muszą zostać uruchomione w produkcji - i w zależności od wielkości otrzymywanie znaczących danych z produkcji może być również powolne.