Studium przypadku

Studium przypadku: infrastruktura testów ścieżek błędów z użyciem Application Verifier

Techniczne studium przypadku: jak dzięki Application Verifier najpierw zbudowano infrastrukturę testów ścieżek błędów i powiązano ją z zapobieganiem nawrotom awarii.

Przegląd przypadku

To studium przypadku, w którym nie poprzestaliśmy na jednorazowej poprawce błędu: za pomocą Application Verifier zbudowaliśmy samą infrastrukturę testów ścieżek błędów. Celem było nie tylko „znalezienie bieżącej awarii”, lecz także z góry zapewnienie stanu, w którym kolejną awarię łatwo będzie prześledzić.

Objawy

  • Same testy ścieżek poprawnego działania rzadko ujawniały problemy na ścieżkach błędów (failure path)
  • Niedobór zasobów i anomalie uchwytów były widoczne zwykle dopiero w warunkach zbliżonych do produkcyjnych
  • Kroki diagnostyczne łatwo zaczynały zależeć od konkretnych osób

Ograniczenia

  • Rzeczywiste wyczerpanie zasobów na prawdziwej maszynie jest kosztowne i ryzykowne
  • Chcieliśmy wcześniej ujawnić, jak zachowuje się system, gdy coś zawodzi na granicy kodu natywnego i w obszarze Win32
  • Rozwiązanie musiało być przygotowane tak, aby można je było wykorzystać przy następnej diagnostyce awarii

Co obserwowaliśmy

  • Ustawienia Verifier, takie jak Handles, Heaps i Low Resource Simulation
  • Ślady ścieżek błędów, w tym !htrace i page heap
  • Zgodność między własnym logiem cyklu życia obiektów a informacjami o zatrzymaniach zgłaszanych przez Verifier

Jak zawęziliśmy przyczynę

Najpierw rozdzieliliśmy to, co można prześledzić samymi zwykłymi logami, od tego, czego nie widać bez zastosowania Verifier. Następnie uruchomiliśmy Verifier na ścieżce wykonania opakowanej w środowisko testowe (harness) i przesunęliśmy podejście w stronę ujawniania z wyprzedzeniem anomalii trudnych do odtworzenia.

Jak poprawiliśmy sytuację

  • Zbudowaliśmy infrastrukturę testów, która celowo przechodzi przez ścieżki błędów
  • Umożliwiliśmy obserwowanie anomalii uchwytów i sterty w krótszych pętlach
  • Uporządkowaliśmy punkty obserwacji tak, aby łatwo było wrócić do nich podczas późniejszych przeglądów projektu i przy działaniach zapobiegających nawrotom

Usługi powiązane z tym przypadkiem

Ten przypadek bezpośrednio łączy się z usługą Diagnostyka błędów i analiza przyczyn źródłowych, która obejmuje odtwarzanie awarii i ustalanie ich przyczyn. Łączy się też z usługą Konsultacje techniczne i przegląd projektu, w ramach której ustalamy, w jakim stopniu testy ścieżek błędów i punkty obserwacji należy uwzględnić już w projekcie.

Zapraszamy do konsultacji

Jeśli mają Państwo problem zbliżony do treści tej strony, prosimy o konsultację z nami, przekazując obecny kontekst oraz rodzaj potrzebnego wsparcia.

Powrót do strony głównej