Przejdź do głównej zawartości
Developer Toolkit Developer Toolkit Developer Toolkit

Optymalizacja wydajności produkcyjnej

W zeszłym tygodniu Twoja usługa checkout odpowiadała w 200 ms. Dziś w nocy, w godzinach szczytu, p99 utrzymuje się na poziomie 3 sekund, konwersja spada, a kanał dyżuru jest zalany czerwonymi alertami. Masz otwarte trzy dashboardy i nie wiesz, który sygnał jest przyczyną, a który objawem. To moment, w którym asystent AI podpięty do Twojego klastra i backendu obserwowalności zarabia na siebie: w jednym przebiegu zestawi metryki podów, ślady i wolne zapytania, zamiast zmuszać Cię do przeskakiwania między narzędziami.

Ten przewodnik pokazuje inżynierom DevOps i SRE, jak prowadzić takie dochodzenie w Cursorze, Claude Code i Codeksie — każdy podpięty do tych samych serwerów MCP Kubernetes i obserwowalności — oraz jak przekuć ustalenia w zmianę, którą można bezpiecznie wdrożyć.

Co z tego wyniesiesz

Dział zatytułowany „Co z tego wyniesiesz”
  • Działającą konfigurację MCP łączącą Cursor, Claude Code i Codex z Kubernetes, Twoim backendem obserwowalności i Postgresem
  • Gotowy do wklejenia prompt do diagnozy regresji opóźnienia p99 w wielu usługach
  • Gotowy do wklejenia prompt do naprawy wyczerpania puli połączeń pod obciążeniem szczytowym
  • Gotowy do wklejenia prompt do dostrojenia zachowania Horizontal Pod Autoscalera (HPA), żeby przestał oscylować
  • Listę kontrolną „gdy to się posypie” dla trybów awarii, które psują dostrajanie wspomagane AI (przeterminowane metryki, zmyślone liczby, optymalizacje, które regresują pod rzeczywistym ruchem)

Niezbędne serwery MCP do pracy nad wydajnością

Dział zatytułowany „Niezbędne serwery MCP do pracy nad wydajnością”

Te serwery są takie same we wszystkich trzech narzędziach — konfiguracja MCP jest identyczna niezależnie od tego, czy używasz Cursora, Claude Code, czy Codeksa. Skonfiguruj je raz. Uchwyty poniżej (@kubernetes, @dynatrace, @last9, @postgres) pojawiają się w promptach w całym przewodniku.

Kubernetes — metryki klastra i stan podów

Dział zatytułowany „Kubernetes — metryki klastra i stan podów”

Zainstaluj raz, a potem wskaż serwerowi swój kubeconfig:

Okno terminala
npm install -g kubectl-mcp-server
{
  "mcpServers": {
    "kubernetes": {
      "command": "npx",
      "args": ["-y", "kubectl-mcp-server"],
      "env": {
        "KUBECONFIG": "/path/to/kubeconfig"
      }
    }
  }
}

Postgres — analiza wolnych zapytań i plany EXPLAIN

Dział zatytułowany „Postgres — analiza wolnych zapytań i plany EXPLAIN”

Użyj utrzymywanego serwera postgres-mcp (crystaldba), który działa przez uvx i odczytuje connection string ze zmiennej DATABASE_URI. Do debugowania na produkcji startuj w trybie ograniczonym (tylko do odczytu):

{
  "mcpServers": {
    "postgres": {
      "command": "uvx",
      "args": ["postgres-mcp", "--access-mode=restricted"],
      "env": {
        "DATABASE_URI": "postgresql://user:password@localhost:5432/dbname"
      }
    }
  }
}

Backend obserwowalności — ślady i APM

Dział zatytułowany „Backend obserwowalności — ślady i APM”

Wybierz ten, którego już używasz. Oba to prawdziwe, utrzymywane pakiety. Uwierzytelnianie to część, którą ludzie psują najczęściej, więc dokładna konfiguracja jest poniżej — i oba domyślnie idą ścieżką wymagającą minimum poświadczeń.

{
  "mcpServers": {
    "dynatrace": {
      "command": "npx",
      "args": ["-y", "@dynatrace-oss/dynatrace-mcp-server@latest"],
      "env": {
        "DT_ENVIRONMENT": "https://<env-id>.apps.dynatrace.com"
      }
    }
  }
}

Gdy ustawisz tylko DT_ENVIRONMENT, uwierzytelnianie przy pierwszym użyciu odbywa się przez przepływ OAuth Authorization Code w przeglądarce — to udokumentowana ścieżka domyślna, więc zwykle ta jedna zmienna wystarcza. Nieinteraktywny DT_PLATFORM_TOKEN jest wspierany jako opcjonalna alternatywa dla konfiguracji headless lub CI.

Diagnozowanie regresji opóźnienia p99

Dział zatytułowany „Diagnozowanie regresji opóźnienia p99”

To chleb powszedni: coś zwolniło i musisz znaleźć przyczynę przed kolejnym skokiem ruchu. Pomysł na prompt jest w każdym narzędziu ten sam, ale sposób wywołania się różni — Cursor używa uchwytów @ w panelu agenta, a Claude Code i Codex przyjmują żądanie w wierszu poleceń.

W panelu agenta wskaż serwery MCP po uchwycie, żeby Cursor pobrał dane na żywo zamiast zgadywać:

@kubernetes @last9 Our checkout-service p99 jumped from 200ms to 3s
during peak hours (18:00–21:00 UTC). Correlate the regression:


1. Pull checkout-service pod CPU/memory for the last 24h and flag
   the time the p99 climbed.
2. From traces, identify which downstream span grew the most.
3. Check the Redis cache hit rate over the same window.
4. Tell me which signal is the cause and which are symptoms.


Do not propose fixes yet — I want the diagnosis and the evidence first.

Sens ramy „najpierw diagnoza, żadnych poprawek” polega na tym, żeby powstrzymać model przed przeskoczeniem do wiarygodnie brzmiącego lekarstwa, zanim przeczyta dane. Chcesz, żeby zacytował poda, span i okno metryki — liczby, które sam potwierdzisz na dashboardzie.

Naprawa wyczerpania puli połączeń

Dział zatytułowany „Naprawa wyczerpania puli połączeń”

Klasyczna awaria godzin szczytu: usługi rzucają błędami too many clients, opóźnienie zapytań skacze z 50 ms do sekund, a wąskim gardłem jest baza danych — nie dlatego, że jest wolna, ale dlatego, że połączenia są na głodzie. AI dobrze się tu sprawdza, bo matematyka (rozmiar puli × liczba replik vs max_connections) jest mechaniczna, a model może odczytać Twoje aktualne ustawienia z klastra.

  1. Pobierz aktualną konfigurację puli i limit Postgresa.

    @kubernetes @postgres Eight services share one Postgres instance.
    Each runs pool min=5/max=25. During peak we get connection timeouts
    and "too many clients" errors. Read the current replica counts from
    the cluster and the database max_connections, then tell me how many
    connections we actually demand at peak vs what the DB allows.

  2. Poproś o konkretną konfigurację, a nie o wykład. Gdy model ma już liczby, każ mu zaproponować konkretne rozmiary puli i konfigurację PgBouncera — z uzasadnieniem powiązanym z Twoją liczbą replik.

  3. Wdróż i obserwuj. Wprowadź zmianę najpierw w jednej usłudze, obserwuj metryki liczby połączeń i wskaźnika błędów przez najbliższy szczyt, a potem poszerzaj.

Dostrajanie autoskalowania, które oscyluje

Dział zatytułowany „Dostrajanie autoskalowania, które oscyluje”

Gdy HPA skaluje w górę agresywnie, ale w dół powoli — albo szarpie się co kilka minut — przepalasz pieniądze i wciąż nie nadążasz za skokami. Naprawa zwykle tkwi w oknach stabilizacji i metryce, na której skaluje się HPA, a AI może odczytać Twoje aktualne obiekty HorizontalPodAutoscaler i rozumować o zachowaniu, które opisujesz.

@kubernetes Our HPAs flap: payment-service scales up at CPU 70%
(min=3/max=10) but CPU spikes to 95% before scaling triggers, and
scale-down happens every 2-3 minutes. Read the current HPA specs,
explain why it's reactive, and propose new behavior.scaleUp /
behavior.scaleDown stabilizationWindowSeconds plus a target metric
that anticipates load better than raw CPU.

Dobra odpowiedź daje Ci tutaj realny blok behavior — na przykład krótkie okno scaleUp (około 60 s) i dłuższe okno scaleDown (300 s+), żeby klaster przestał skakać w górę i w dół — plus sugestię skalowania na podstawie wskaźnika żądań lub metryki niestandardowej zamiast samego CPU, bo CPU opóźnia się za faktycznym obciążeniem.

Gdy to się posypie

Dział zatytułowany „Gdy to się posypie”

Praca nad wydajnością wspomagana AI zawodzi w konkretny, rozpoznawalny sposób. Poznaj te przypadki, zanim zaufasz rekomendacji na produkcji.

  • Serwer MCP nie może dosięgnąć klastra lub backendu. Jeśli asystent zwraca mgliste, zaokrąglone metryki („około 95% CPU”) zamiast wartości ze znacznikami czasu, niemal na pewno odpowiada z danych treningowych, a nie z Twoich. Potwierdź połączenie: claude mcp list pokazuje skonfigurowane serwery w Claude Code, a panel ustawień MCP w Cursorze pokazuje status zielony/czerwony dla każdego serwera. Uruchom prompt ponownie dopiero, gdy dane faktycznie płyną.
  • Zmyślone metryki. Nawet przy żywym połączeniu model może wymyślić liczbę, by zapełnić lukę w wyniku zapytania. Traktuj każdą wartość jak twierdzenie do zweryfikowania na źródłowym dashboardzie, zanim na jej podstawie zadziałasz. Instrukcja „cytuj dokładne wartości i znaczniki czasu” z powyższych promptów istnieje właśnie po to, żebyś mógł to sprawdzić.
  • Optymalizacja zregresowała pod rzeczywistym obciążeniem. Zmiana, która świetnie wygląda na stagingu, może się rozsypać przy produkcyjnej współbieżności — mniejsza pula połączeń, która jest w porządku przy 1 tys. żądań/s, głoduje przy 5 tys. Wprowadzaj zmiany najpierw w jednej usłudze lub jednej replice, obserwuj przez prawdziwy szczyt i trzymaj poprzednią konfigurację o jedno kubectl rollout undo od siebie.
  • Model zoptymalizował niewłaściwą rzecz. Jeśli pominiesz krok „najpierw diagnoza”, asystent z radością dostroi objaw. Gdy poprawka nie rusza kluczowej metryki, wróć do promptu diagnostycznego i każ mu ponownie uszeregować przyczynę vs objaw na świeżych danych.

Co dalej

Dział zatytułowany „Co dalej”

Zobacz co nowego na platformie.

Polityka prywatności Regulamin