Workflow łowienia bugów - Cursor

Scenariusz

Produkcja nie działa. Użytkownicy zgłaszają, że checkout sporadycznie kończy się niepowodzeniem z niejasnym błędem “Transakcja nie powiodła się”. Działa dobrze w developmencie, występuje tylko pod obciążeniem i zaczęło się po wdrożeniu z zeszłego tygodnia. Wskaźnik błędów wynosi 15% i rośnie. Twój CEO pyta o aktualizacje co 30 minut.

Cele nauczania

Po ukończeniu tej lekcji opanujesz:

• Systematyczną metodologię debugowania z AI
• Techniki analizy przyczyn głównych
• Strategie debugowania produkcyjnego
• Profilowanie wydajności z pomocą AI
• Tworzenie reprodukowalnych przypadków testowych
• Implementację trwałych poprawek z monitorowaniem

Wymagania wstępne

• Podstawowe doświadczenie w debugowaniu
• Zrozumienie systemów rozproszonych
• Znajomość logowania i monitorowania
• Dostęp do logów produkcyjnych (symulowanych)

Wyzwanie

Debuguj złożony problem produkcyjny obejmujący:

• Sporadyczne awarie (Heisenbugi)
• Race conditions
• Degradację wydajności
• Interakcje wielu serwisów
• Niekompletne komunikaty błędów
• Presję czasową

Uwaga

Debugowanie produkcyjne wymaga starannej analizy. Pośpieszne poprawki często pogarszają sytuację. Użyj AI do systematycznego badania przed implementacją rozwiązań.

Przewodnik implementacji

Faza 1: Wstępne śledztwo

1. Zbieranie objawów

Zacznij z trybem Ask, aby przeanalizować dostępne informacje:

"Pomóż mi stworzyć systematyczny plan debugowania dla:
- Błąd: 'Transakcja nie powiodła się' podczas checkout
- Częstotliwość: 15% transakcji
- Rozpoczęcie: Po wdrożeniu dnia [data]
- Wzorzec: Tylko pod obciążeniem, działa w dev
Jakie informacje powinienem zebrać najpierw?"

2. Analiza logów błędów

@logs/production-errors.log
"Przeanalizuj te logi błędów:
- Znajdź wzorce w nieudanych transakcjach
- Zidentyfikuj wspólne charakterystyki
- Szukaj wzorców czasowych
- Sprawdź skorelowane błędy
- Wyciągnij unikalne sygnatury błędów"

3. Przegląd ostatnich zmian

@git log --since="1 week ago" --oneline
"Przejrzyj ostatnie commity które mogły spowodować:
- Race conditions
- Problemy wydajności
- Deadlocki bazy danych
- Zmiany w przetwarzaniu płatności
Skoncentruj się na przepływach checkout i płatności"

Faza 2: Formułowanie hipotez

1. Generowanie hipotez

Przełącz na tryb Agent:

@logs/errors.log @src/checkout @src/payment
"Na podstawie objawów i kodu, wygeneruj hipotezy dla:
- Dlaczego awarie występują tylko pod obciążeniem
- Dlaczego komunikat błędu jest ogólny
- Możliwe race conditions
- Problemy z połączeniami do bazy danych
Uszereguj według prawdopodobieństwa"

2. Tworzenie planu śledztwa

"Utwórz szczegółowy plan śledztwa dla top 3 hipotez:
1. Co szukać w logach
2. Zapytania do uruchomienia w bazie danych
3. Metryki do sprawdzenia
4. Ścieżki kodu do prześledzenia
5. Testy do napisania"

3. Śledzenie przepływu transakcji

@src/checkout/service.js @src/payment/processor.js
"Prześledź kompletną transakcję checkout:
- Utwórz diagram sekwencyjny
- Zidentyfikuj wszystkie zewnętrzne wywołania
- Oznacz operacje asynchroniczne
- Znajdź potencjalne race conditions
- Zanotuj luki w obsłudze błędów"

Faza 3: Reprodukcja

1. Tworzenie testu obciążeniowego

"Utwórz test obciążeniowy do reprodukcji problemu:
- Symuluj wzorce ruchu produkcyjnego
- Uwzględnij równoczesne checkouty
- Różnicuj kwoty i metody płatności
- Dodaj opóźnienie sieciowe
- Monitoruj dokładny błąd"

Przykład testu obciążeniowego:

load-test.js

import { check } from 'k6';
import http from 'k6/http';

export const options = {
  stages: [
    { duration: '30s', target: 100 },
    { duration: '1m', target: 200 },
    { duration: '30s', target: 0 },
  ],
  thresholds: {
    http_req_failed: ['rate < 0.1'], // Mniej niż 10% błędów
    http_req_duration: ['p(95) < 500'], // 95% poniżej 500ms
  },
};

export default function() {
  const payload = JSON.stringify({
    items: [{ id: 1, quantity: 2 }],
    payment: {
      method: 'credit_card',
      amount: Math.random() * 1000,
    },
  });

  const response = http.post(
    'http://localhost:3000/api/checkout',
    payload,
    { headers: { 'Content-Type': 'application/json' } }
  );

  check(response, {
    'status is 200': (r) => r.status === 200,
    'no transaction error': (r) => !r.body.includes('Transakcja nie powiodła się'),
  });
}

2. Dodawanie szczegółowego logowania

@src/checkout/service.js
"Dodaj kompleksowe logowanie debug:
- Czasy rozpoczęcia/zakończenia transakcji
- Czas trwania zapytań do bazy danych
- Czasy wywołań zewnętrznych API
- Nabycie/zwolnienie blokad
- Statystyki puli połączeń
Użyj strukturalnego logowania z ID korelacji"

3. Tworzenie minimalnej reprodukcji

"Utwórz minimalny kod do reprodukcji problemu:
- Usuń niepotrzebną złożoność
- Skoncentruj się na ścieżce awarii
- Uczyń deterministycznym jeśli możliwe
- Dodaj kontrole czasowe
- Udokumentuj kroki reprodukcji"

Faza 4: Analiza przyczyny głównej

1. Analiza problemów czasowych

@logs/debug-trace.log
"Przeanalizuj czasy transakcji:
- Znajdź operacje trwające zbyt długo
- Zidentyfikuj równoczesne operacje
- Szukaj rywalizacji o blokady
- Sprawdź konfiguracje timeoutów
- Skoreluj z awariami"

2. Śledztwo bazodanowe

-- AI generuje zapytania diagnostyczne
"Wygeneruj zapytania SQL do zbadania:
- Deadlocków w tabeli płatności
- Długotrwałych transakcji
- Wyczerpania puli połączeń
- Timeoutów oczekiwania na blokady
- Statystyk użycia indeksów"

3. Identyfikacja przyczyny głównej

Na podstawie śledztwa, AI pomaga zidentyfikować:

// Przyczyna główna znaleziona: Wyczerpanie puli połączeń bazy danych
// Stary kod:
async function processPayment(paymentData) {
  const conn = await db.getConnection();
  try {
    await conn.beginTransaction();

    // Bug: Połączenie nie zwolnione przy wcześniejszym returnie
    if (!validatePayment(paymentData)) {
      return { error: 'Transakcja nie powiodła się' }; // Wyciek połączenia!
    }

    const result = await conn.query('INSERT INTO payments...');
    await conn.commit();
    return result;
  } catch (error) {
    await conn.rollback();
    throw error;
  } finally {
    conn.release(); // Nie osiągnięte przy błędzie walidacji
  }
}

Faza 5: Implementacja poprawki

1. Implementacja poprawki

@src/payment/processor.js
"Napraw problem wycieku połączeń:
- Zapewnij zawsze zwolnienie połączeń
- Dodaj monitorowanie puli połączeń
- Ulepsz komunikaty błędów
- Dodaj wzorzec circuit breaker
- Uwzględnij ID korelacji"

Naprawiony kod:

async function processPayment(paymentData) {
  const conn = await db.getConnection();
  try {
    // Waliduj przed transakcją
    if (!validatePayment(paymentData)) {
      return {
        error: 'Walidacja płatności nie powiodła się',
        details: getValidationErrors(paymentData),
        correlationId: generateCorrelationId()
      };
    }

    await conn.beginTransaction();

    const result = await conn.query('INSERT INTO payments...', paymentData);
    await conn.commit();

    logger.info('Płatność przetworzona pomyślnie', {
      paymentId: result.insertId,
      correlationId: paymentData.correlationId
    });

    return { success: true, paymentId: result.insertId };
  } catch (error) {
    await conn.rollback();
    logger.error('Przetwarzanie płatności nie powiodło się', {
      error: error.message,
      stack: error.stack,
      paymentData,
      correlationId: paymentData.correlationId
    });
    throw new PaymentError('Transakcja nie powiodła się', error);
  } finally {
    // Zawsze zwolnij połączenie
    conn.release();
  }
}

2. Dodawanie monitorowania

"Dodaj kompleksowe monitorowanie:
- Metryki puli połączeń
- Histogram czasu trwania transakcji
- Wskaźnik błędów według typu
- Monitorowanie głębokości kolejki
- Progi alertów"

3. Tworzenie testów

@src/payment/processor.test.js
"Utwórz testy dla błędu:
- Testuj scenariusz wycieku połączeń
- Testuj pod równoczesnym obciążeniem
- Testuj obsługę błędów
- Testuj metryki monitorowania
- Testuj circuit breaker"

Kluczowe zademonstrowane techniki

Technika 1: Systematyczny proces debugowania

Postępuj zgodnie z tym sprawdzonym wzorcem:

graph TD A[Zbierz objawy] --> B[Sformułuj hipotezy] B --> C[Utwórz reprodukcję] C --> D[Analiza przyczyny głównej] D --> E[Implementuj poprawkę] E --> F[Weryfikuj i monitoruj] F --> G[Udokumentuj naukę]

Technika 2: Debugowanie wyszukiwania binarnego

Zawęź problem:

// Zacznij szeroko
"Proces checkout zawodzi"

// Zawęź do podsystemu
"Przetwarzanie płatności zawodzi"

// Zawęź do określonej operacji
"Połączenia do bazy danych wyciekają podczas walidacji"

// Znajdź dokładną linię
"Linia 47: wcześniejszy return bez zwolnienia połączenia"

Technika 3: Debugowanie podróży w czasie

Użyj git bisect z AI:

# AI pomaga stworzyć skrypt testowy
@src/checkout
"Utwórz skrypt który zwraca 0 jeśli checkout działa, 1 jeśli nie"

# Użyj git bisect
git bisect start
git bisect bad HEAD
git bisect good abc123
git bisect run ./test-checkout.sh

Częste scenariusze debugowania

Race conditions

"Przeanalizuj ten kod pod kątem race conditions:
- Zidentyfikuj wspólne zasoby
- Znajdź brakującą synchronizację
- Szukaj wzorców check-then-act
- Zasugeruj poprawki z odpowiednią blokadą"

Wycieki pamięci

"Pomóż mi znaleźć wycieki pamięci:
- Przeanalizuj zrzuty sterty
- Znajdź referencje cykliczne
- Zidentyfikuj niezamknięte zasoby
- Zasugeruj wzorce czyszczenia"

Problemy wydajności

"Sprofiluj tę wolną operację:
- Dodaj pomiary czasowe
- Znajdź zapytania N+1
- Zidentyfikuj wąskie gardła CPU
- Zasugeruj optymalizacje"

Rozszerzone wyzwanie

Podnieś swoje umiejętności debugowania:

1. Rozproszone śledzenie

   • Implementuj OpenTelemetry
   • Śledź przez mikrousługi
   • Koreluj logi i metryki
   • Wizualizuj przepływ żądań

2. Chaos engineering

   • Wstrzykuj kontrolowane awarie
   • Testuj wzorce odporności
   • Automatyzuj odzyskiwanie po awariach
   • Dokumentuj tryby awarii

3. Monitorowanie napędzane przez AI

   • Wykrywanie anomalii
   • Predykcyjne alerty
   • Auto-remediacja
   • Sugestie przyczyn głównych

Metryki debugowania

Śledź swoją efektywność debugowania:

• ⏱️ Średni czas do wykrycia (MTTD): < 5 minut
• 🔍 Średni czas do identyfikacji (MTTI): < 30 minut
• 🔧 Średni czas do rozwiązania (MTTR): < 2 godziny
• 🎯 Wskaźnik sukcesu pierwszej poprawki: > 90%
• 📊 Wskaźnik powtórzeń: < 5%

Historie wojenne ze świata rzeczywistego

Deadlock bazy danych o 2:00 w nocy

“Użyłem Cursor do analizy 50K linii logów w minuty, znalazłem zależność cykliczną która występowała tylko gdy zamówienia przekraczały 9.999,99 zł”

Fantomowy wyciek pamięci

“AI zidentyfikował listener zdarzenia WebSocket który nie był czyszczony przy ponownym połączeniu, powodując wzrost pamięci o 10MB/godzinę”

Poniedziałkowy poranny wzrost

“Odkryłem wzorzec cache stampede gdy wszystkie sesje użytkowników wygasały jednocześnie na początku tygodnia”

Zestaw narzędzi debugowania

Niezbędne narzędzia zintegrowane z Cursor:

.cursor/debug-toolkit.md

## Szybkie polecenia

### Analizuj logi
@logs/production.log "Znajdź anomalie w ostatniej godzinie"

### Sprawdź wydajność
@src/slow-endpoint.js "Sprofiluj i znajdź wąskie gardła"

### Śledź wykonanie
@src "Prześledź ścieżkę wykonania dla użytkownika ID 12345"

### Znajdź podobne problemy
@git log --grep="Transakcja nie powiodła się" "Pokaż jak naprawiono podobne problemy"

Kluczowe wnioski

1. Bądź systematyczny: Losowe zmiany utrudniają debugowanie
2. Najpierw reprodukuj: Nie możesz naprawić tego czego nie możesz reprodukować
3. Mierz wszystko: Dane pokonują domysły
4. Naprawiaj przyczyny główne: Nie łataj tylko objawów
5. Dokumentuj odkrycia: Dzisiejszy bug to jutrzejsza wiedza

Następne kroki

Opanowałeś systematyczne debugowanie. Gotowy na więcej?

Buduj narzędzia debug

Twórz niestandardowe narzędzia debugowania dla swojego stosu

Ucz innych

Przeprowadź warsztat debugowania dla swojego zespołu

Wnosij wkład

Dziel się swoimi wzorcami debugowania ze społecznością

Kontynuuj do Integracja API →

Wskazówka

Rozpocznij dziennik debugowania. Udokumentuj każdy interesujący bug: objawy, proces śledztwa, przyczynę główną i poprawkę. To staje się nieocenionym materiałem referencyjnym i może trenować AI na twoich specyficznych wzorcach.