"Działa na mojej maszynie" - jak naprawić nie powtarzalne błędy?

Obszerne logowanie zwykle pomaga.

Najprostszym sposobem jest zawsze zobaczyć Klienta w działaniu (zakładając, że jest on łatwo odtwarzalny przez Klienta). Często pojawiają się problemy z powodu problemów ze środowiskiem komputerowym klienta, konfliktów z innymi programami itp. - są to szczegóły, których nie będziesz w stanie złapać na swoim dev rig. Tak więc wizyta w witrynie może być przydatna; ale jeśli nie jest to wygodne, narzędzia takie jak RealVNC mogą również pomóc w pozwalaniu klientowi "robić swoje".

(oglądanie klient w akcji pozwala również na złapanie ich w dowolnych momentach WTF , które mogą mieć)

Teraz, jeśli problem jest przerywany, wtedy sprawy stają się nieco bardziej skomplikowane. Najlepszym sposobem na obejście tego problemu byłoby zalogowanie przydatnych informacji w miejscach, w których domyślasz się, że mogą wystąpić problemy i być może użycie narzędzia takiego jak Splunk do indeksowania plików dziennika podczas analizy. Konfiguracja diagnostyczna (tj. z dodatkowym logowaniem) może być przydatna w tym przypadku.

Jestem właśnie w trakcie wdrażania automatycznego systemu raportowania błędów, który wysyła do mnie informacje (obecnie za pośrednictwem poczty elektronicznej, chociaż można użyć webservice) z każdego wyjątku napotkanego przez aplikację.

W ten sposób otrzymuję (prawie) wszystkie informacje, które zrobiłbym, gdybym siedział przed VS2008 i to naprawdę pomaga mi zrozumieć, na czym polega problem.

Klienci są również zazwyczaj (jakby) pod wrażeniem, że wiem o ich problemie, jak tylko napotkają to!

Również, jeśli używasz aplikacji.Threadexception Error handler możesz również wysłać informacje o nieoczekiwanych wyjątkach!

Używamy wszystkich metod, które wymieniasz stopniowo, zaczynając od najprostszych i przechodząc do trudniejszych.

Jednak zapominasz, że czasami sprzęt jest winny. Na przykład pamięć może działać nieprawidłowo, a niektóre wymagające obliczeń kody będą zachowywać się dziwnie, rzucając wyjątki z dziwną diagnostyką. Oczywiście działa na twoim komputerze, ponieważ nie masz wadliwego sprzętu.

Doświadczenie jest potrzebne, aby zidentyfikować takie błędy i nalegać, aby klient próbował zainstalować program na innym komputerze lub sprawdza sprzęt. Jedną z rzeczy, która bardzo pomaga, jest dobra obsługa błędów - gdy kod rzuca wyjątek, powinien podać szczegóły, a nie tylko wskazywać, że coś jest złe. Przy dobrym wskaźniku błędów łatwiej jest zidentyfikować takie podejrzane problemy związane z wadliwym sprzętem.

Myślę, że jedną z najważniejszych rzeczy jest umiejętność zadawania sensownych pytań wokół tego, co zgłosił klient... Częściej niż nie wspominają o czymś, co nie widzą jako istotne, ale jest w rzeczywistości kluczowe.

Telepatia też by się przydała...

Odnieśliśmy sukces używając EurekaLog , wysyłając go bezpośrednio do FogBugz. To daje nam raport o błędzie zawierający stos połączeń, wraz z powiązanymi informacjami systemowymi (inne uruchomione procesy, pamięć, szczegóły sieci itp.) i zrzut ekranu. Czasami klienci wprowadzają również dodatkowe informacje, co jest pomocne. To z pewnością, w większości przypadków, znacznie ułatwiło i przyspieszyło naprawianie błędów.

Jedną z technik, które uznałem za przydatne, jest budowanie aplikacji ze zintegrowanym trybem "diagnostycznym" (włączonym przez przełącznik linii poleceń po uruchomieniu aplikacji). To z pewnością pozwala uniknąć konieczności tworzenia niestandardowych kompilacji z dodatkowym logowaniem.

W Przeciwnym Razie, to brzmi, jakby to, co robisz, było równie dobrym podejściem, jak każde inne.

Drugi pilot (zakładając, że klient jest gdzieś zimny i deszczowy:)

Zwyczajową procedurą jest oczekiwanie, że coś takiego się wydarzy i doda mnóstwo informacji o logowaniu. Oczywiście nie włączasz go od początku, ale tylko wtedy, gdy tak się stanie.

Zazwyczaj klienci nie lubią instalować nowej wersji lub niektórych narzędzi diagnostycznych. Debugowanie nie jest ich zadaniem. A odwiedzanie klienta w takich przypadkach rzadko jest opcją. Musisz zaangażować klienta w jak najmniejszym stopniu. Zmiana przełącznika i przesłanie pliku dziennika jest OK-cokolwiek więcej niż to jest zbyt wiele.

Lubię alternatywę myślenia o problemie w wannie. Zacznę od odkrycia różnic między moją maszyną a konfiguracją klienta.

Jako inżynier oprogramowania wykonujący webstuff (systemy rezerwacyjne/sklepowe/członkowskie itp.) najważniejszą rzeczą dla nas jest uzyskanie jak największej ilości informacji od klienta.

Going from

Jest zepsuty!

Do

Jest zepsuty! oto screeny z każdą opcję wybrałem podczas generowanie tego konkretnego raportu

Zmniejsza ilość czasu, jaki zajmuje nam odtworzenie i naprawienie problemu bez końca.

To może być oczywiste, ale czasami trzeba sporo gonić, aby uzyskać tego rodzaju informacje od naszych klientów! Ale warto to zrobić tylko w tych momentach, kiedy okazuje się, że nie robią tego, co mówią.

Też miałem takie problemy. Moim rozwiązaniem było dodanie wielu logowań i dostarczenie klientowi kompilacji debugowania ze wszystkimi możliwymi informacjami debugowania. Następnie upewnij się, że dr Watson (był w Windows NT) stworzył zrzut pamięci z wystarczającą ilością informacji. Po załadowaniu zrzutu pamięci do debuggera mogłem się dowiedzieć gdzie i dlaczego się rozbił.

EDIT: Och, to oczywiście działa tylko wtedy, gdy aplikacja zakończy się gwałtownie...

Myślę, że podążanie śladem działań podejmowanych przez użytkownika może doprowadzić nas do przyczyn awarii lub wybiórczych awarii. Ale większość użytkowników nie jest w stanie dokładnie opisać interakcji z aplikacjami, automatyczne zrzuty ekranu (jeśli jest to aplikacja komputerowa. w przypadku aplikacji. Net możesz sprawdzić, czy jest to UnhandledExceptionHandler). Zapisanie wszystkich ważnych akcji, które zmieniają stan obiektów, może również pomóc nam w jego zrozumieniu.

Nie mam tego problemu zbyt często, ale gdybym miał, użyłbym aplikacji do udostępniania ekranu lub nagrywania, aby oglądać użytkownika w akcji bez konieczności chodzenia tam (chyba, że, jak powiedziałeś, jest ciepło i słonecznie, a firma płaci za podróż).

Sam ostatnio badałem taki problem. W trakcie pracy z moim operatorem nauczyłem się, że chociaż systemy komputerowe mogą być skomplikowane, są przewidywalne, więc miej wiarę, że możesz znaleźć problem. Moje podejście do tego typu zagadnień dwukrotnie:

1) Zbierz jak najwięcej szczegółowych informacji od Klienta o ich awarii i skrupulatnie przeanalizuj je pod kątem wzorców. Zbierz wiele zestawów danych dla wielu wystąpień awarii, aby uzyskać wyraźniejszy obraz zdjęcie.

2) Spróbuj odtworzyć awarię w domu. Kontynuuj, aby Twój system był coraz bardziej podobny do systemu klientów, dopóki nie będziesz mógł go odtworzyć, system jest identyczny lub staje się niepraktyczne, aby uczynić go bardziej podobnym.

Robiąc to rozważ:

1) Jakie są różnice między tym systemem a innymi działającymi systemami.

2) co ostatnio zmieniło się w Twoim produkcie lub konfiguracji klientów, co spowodowało uruchomienie problemu występuje.

Pozdrawiam

W zależności od problemu można uzyskać zrzuty WinDbg, zwykle dają całkiem dobry obraz tego, co się dzieje. Zdiagnozowaliśmy sporo problemów, które nie zostały rozbite z minidupli.

Dla aplikacji. Net również byliśmy Trace.Writeline wtedy możemy zmusić użytkownika do odpalenia DbgView i wysłania nam wyjścia.

To bardzo skomplikowany problem . Myślałem o napisaniu procedury . Zrobiłem procedurę dla tego nie powtarzalnego błędu . it might be helpful

Gdy robak się pojawi .. Istnieje kilka czynników, które mogą wystąpić.

Jestem pewien, że wszystkie błędy są powtarzalne . Zawsze mam oko na tego typu problemy..

1. Pobierz informacje o systemie
2. jaki inny proces klient zrobił wcześniej.
3. okres czasu występuje . jego rzadkie lub częste
4. jego następna akcja miała miejsce po wydaniu (zawsze ta sama lub inna)
5. Znajdź czynniki dla tego błędu (jako programista)
6. Znajdź dokładną pozycję, w której doszło do tego problemu .
7. Znajdź wszystkie czynniki systemowe w tym czasie
8. sprawdź wszystkie wycieki pamięci lub błąd użytkownika lub zły stan w kodzie
9. Wymień wszystkie fakotry, które mogą powodować ten problem.
10. W jaki sposób każdy z czynników ma wpływ na to i wat są dane, które przechowują te czynniki
11. Sprawdź problemy z memem
12. sprawdź, czy klient ma bieżący kod aktualizacji, taki jak Twój
13. sprawdź wszystkie dzienniki z co najmniej 1 miesiąca i znajdź dowolną normalną operację . keep on note

Krótka anegdota( stąd 'community wiki'): w zeszłym tygodniu pomyślałem, że to sprytny pomysł w aplikacji Django, aby zaimportować Moduł pprint do ładnego drukowania danych Pythona tylko jeśli DEBUG był prawdziwy:

if settings.DEBUG:
    from pprint import pprint

Potem użyłem tu i ówdzie polecenia pprint jako instrukcji debugowania:

pprint(somevar) # show somevar on the console

Po zakończeniu pracy Przetestowałem aplikację z ustawieniem DEBUG=False. Możesz zgadnąć, co się stało: strona zerwała z błędami HTTP500 w całym miejscu, a ja nie wiedziałem, dlaczego, ponieważ tam nie jest traceback, Jeśli DEBUG jest False. Byłem zaskoczony, że błędy zniknęły magicznie, jeśli przełączyłem się z powrotem do trybu debugowania.

Zajęło mi 1-2 godziny umieszczania print wypowiedzi po całym kodzie, aby dowiedzieć się, że kod ulega awarii dokładnie w powyższej linii pprint(). Potem Zajęło mi jeszcze pół godziny, żeby przekonać się, żeby przestać walić głową w stół.

Teraz przychodzi Morał z tej historii:

1. Nie każda rzecz, która na pierwszy rzut oka wygląda na sprytny pomysł, jest w końcu taki bystry.

2. Ważnym punktem do debugowania tych błędów są wszystkie opcje konfiguracji i przełączniki platformy twój kod sam sprawia. Może to być znacznie więcej niż tylko niektóre preferencje użytkownika. Dokument dobry, jeśli przyjmiesz założenie dotyczące platformy użytkownika (np. jeśli testujesz tylko Win/Mac/Linux, czy Twój kod ulegnie awarii na BSD lub Solarisie?)

Jakkolwiek trudny jest nie powtarzalny problem - nadal możemy mieć ustrukturyzowane i strategiczne podejście, aby je rozwiązać - i mogę powiedzieć z doświadczenia, że wymaga to nieszablonowego myślenia w 50% przypadków. Ogólnie rzecz biorąc, można podzielić problemy na różne typy, co pomaga określić, jakie narzędzie należy użyć. Na przykład jeśli masz problem z nieodwracalną awarią aplikacji lub problem z pamięcią, możesz użyć profilerów i zlikwidować problem spowodowany w danym funkcjonalność.

Ponadto, jednym z najważniejszych podejść jest inforamcja bogate logowanie. Używam również wielu enum do opisania stanu procesu w zależności od scenariusza, o którym mowa. na przykład, używałem jak inicjowane, wyzwalane, uruchomione, oczekujące naprawione itp opisywać Stany harmonogramów i zapisywać je do DB na różnych etapach.

Jeszcze nie wspomniano, ale" directed code review " jest dobrym rozwiązaniem, zwłaszcza jeśli nie zrobiłeś WŁAŚCIWEGO przeglądu (co najmniej 1 godzinę na 100 linijek kodu) przed wydaniem.

Widziałem również imponujące dema AppSight Suite, który jest w zasadzie zaawansowanym narzędziem do monitorowania i rejestrowania środowiska. Pozwala to klientowi rejestrować to, co dzieje się na jego maszynie w obszernym, ale dość kompaktowym pliku dziennika, który można następnie odtworzyć.

Jak wielu już wspomniało, obszerne logowanie i proszenie Klienta o pliki dziennika, gdy coś pójdzie nie tak. Ponadto, ponieważ pracowałem Więcej z aplikacjami internetowymi, dostarczę również szczegółową, ale zwięzłą dokumentację wdrażania (np. kroki wdrażania, zasoby środowiskowe, które należy skonfigurować itp.).

Oto typowe problemy, które widziałem, które prowadzą do typów problemów, które opisujesz:

1. nieprawidłowo skonfigurowane środowisko (np. brakujące zmienne środowiskowe, dane źródła itp.).
2. aplikacja nie w pełni wdrożona (np. schemat bazy danych nie wdrożony).
3. różnica w konfiguracji systemu operacyjnego (domyślne kodowanie znaków jest dla mnie najczęstszym winowajcą).

W większości przypadków problemy te można zidentyfikować poprzez zawartość dziennika.

Możesz użyć narzędzi takich jak Microsoft SharedView lub TeamViewer , aby połączyć się ze zdalnym komputerem i sprawdzić problem bezpośrednio na miejscu. Oczywiście będziesz potrzebował współpracy z klientem.