Optymalizacja wydajności produkcyjnej

Dostrajanie wydajności produkcyjnej z agentami AI polega na podłączeniu Claude Code, Codeksa lub Cursora do serwerów MCP Kubernetes, Postgresa i metryk tylko do odczytu, aby agent zestawił zużycie podów, ślady i wolne zapytania w diagnozę opartą na cytowanych metrykach. Agent proponuje poprawkę, a o jej wdrożeniu decydują test obciążeniowy, wdrożenie kanarkowe i porównanie z progami ustalonymi z góry.

Jest piątek, 19:40. Od początku wieczornego szczytu p99 checkoutu wzrosło z około 200 ms do 3 sekund, a kanał dyżurny zalewają alerty. Masz otwarte trzy dashboardy i nie potrafisz powiedzieć, który sygnał jest przyczyną, a które są objawami.

Ten przewodnik jest dla programistów backendu i SRE, którzy pełnią dyżury, oraz dla tech leada, który zatwierdza zmianę wydajnościową, zanim trafi na wszystkie repliki. Zakłada, że masz już metryki i ślady; jeśli nie, zacznij od monitoringu i obserwowalności z AI.

Jak przyspieszyć i potanić samo Claude Code, opisuje artykuł o optymalizacji wydajności Claude Code.

Co wyniesiesz z dostrajania wydajności z pomocą agenta

• Konfigurację MCP tylko do odczytu dla Kubernetes, Postgresa oraz Grafany lub Datadoga, z poleceniem instalacji dla każdego narzędzia
• Cztery gotowe prompty: diagnoza regresji p99, dobór puli połączeń, naprawa oscylującego autoskalera i raport weryfikacyjny przed i po
• Bramkę akceptacyjną, która dowodzi, że zmiana zadziałała, bez czytania rozumowania agenta linijka po linijce
• Typowe awarie dostrajania z agentem i sposób wyjścia z każdej z nich

Jakich serwerów MCP potrzebuje praca nad wydajnością?

Diagnoza wydajności wymaga trzech sygnałów: co robi klaster, co robi baza danych i co widzą użytkownicy. Dla każdego istnieje utrzymywany serwer MCP z przełącznikiem tylko do odczytu. Używaj go: serwer działa z poświadczeniami, które mu dasz, i żadne ustawienie uprawnień po stronie agenta tego nie zawęża.

Sygnał	Serwer	Pakiet	Przełącznik tylko do odczytu
Pody, HPA, zdarzenia, zużycie z pods_top	Kubernetes MCP Server (organizacja containers)	npm kubernetes-mcp-server 0.0.67	read_only = true w konfiguracji TOML
Wolne zapytania, plany EXPLAIN, stan połączeń	Postgres MCP Pro (Crystal DBA)	PyPI postgres-mcp 0.3.0	--access-mode=restricted
Zapytania do Prometheusa i Loki	Grafana MCP (Grafana Labs)	PyPI mcp-grafana 1.6.0	--disable-write
Metryki, ślady, monitory	Datadog MCP (zarządzany, zdalny)	brak: https://mcp.datadoghq.com/v1/mcp	zakres konta Datadog, którym się logujesz

Wersje odczytano z npm i PyPI 26.09.2026. mcp-grafana wydaje nowe wersje co kilka dni, więc przed przypięciem wersji sprawdź aktualną na PyPI (linia 2.x wystartowała 1.10.2026; potwierdź flagę --disable-write w jej README). Alternatywy i inne backendy znajdziesz w artykułach o serwerach MCP dla baz danych i serwerach MCP do obserwowalności.

Skonfiguruj serwer Kubernetes tylko do odczytu

Serwer Kubernetes czyta ustawienia z pliku TOML; w CLI zostały tylko --config, --config-dir i --version. Zapisz poniższy plik jako ~/.config/k8s-mcp.toml i wskaż w kubeconfig plik, którego konto serwisowe ma wyłącznie get, list i watch:

read_only = true
toolsets = ["core"]
kubeconfig = "/home/you/.kube/perf-readonly.config"

# Keep Secrets out of the agent's context even if RBAC allows reading them
[[denied_resources]]
group = ""
version = "v1"
kind = "Secret"

Narzędzie pods_top czyta dane z Kubernetes Metrics Server, więc w klastrze bez niego nic nie zwróci.

Dodaj serwery do agenta

Serwery są te same dla wszystkich trzech narzędzi; różni się tylko sposób rejestracji.

Claude Code

Uruchom w terminalu. -e ustawia zmienną środowiskową serwera stdio, a wszystko po -- to polecenie samego serwera:

claude mcp add kubernetes -- npx -y kubernetes-mcp-server@latest --config ~/.config/k8s-mcp.toml
claude mcp add postgres -e DATABASE_URI="$PERF_DB_URI" \
  -- uvx postgres-mcp --access-mode=restricted
claude mcp add grafana -e GRAFANA_URL=https://grafana.example.com \
  -e GRAFANA_SERVICE_ACCOUNT_TOKEN="$GRAFANA_RO_TOKEN" -- uvx mcp-grafana --disable-write
# Datadog instead of Grafana (US1 site; other sites change the host):
claude mcp add --transport http datadog https://mcp.datadoghq.com/v1/mcp
# then run /mcp inside a Claude Code session to complete Datadog's OAuth sign-in
claude mcp list

Domyślny zakres local zapisuje te wpisy w twojej konfiguracji użytkownika (~/.claude.json), a nie w repozytorium.

Codex

Uruchom w terminalu. Codex używa --env i --url tam, gdzie Claude Code używa -e i --transport http:

codex mcp add kubernetes -- npx -y kubernetes-mcp-server@latest --config ~/.config/k8s-mcp.toml
codex mcp add postgres --env DATABASE_URI="$PERF_DB_URI" \
  -- uvx postgres-mcp --access-mode=restricted
codex mcp add grafana --env GRAFANA_URL=https://grafana.example.com \
  --env GRAFANA_SERVICE_ACCOUNT_TOKEN="$GRAFANA_RO_TOKEN" -- uvx mcp-grafana --disable-write
# Datadog instead of Grafana (OAuth, so log in after adding it):
codex mcp add datadog --url https://mcp.datadoghq.com/v1/mcp
codex mcp login datadog
codex mcp list

Cursor

Dodaj serwery do pliku użytkownika ~/.cursor/mcp.json, który nie leży w repozytorium, a potem sprawdź w ustawieniach MCP Cursora, że każdy jest połączony. Wartości ${env:NAME} Cursor odczytuje ze środowiska przy starcie serwera. Jeśli serwer się nie uruchamia, sprawdź w ustawieniach MCP Cursora, czy zmienna została rozwinięta:

{
  "mcpServers": {
    "kubernetes": {
      "command": "npx",
      "args": ["-y", "kubernetes-mcp-server@latest", "--config", "/home/you/.config/k8s-mcp.toml"]
    },
    "postgres": {
      "command": "uvx",
      "args": ["postgres-mcp", "--access-mode=restricted"],
      "env": { "DATABASE_URI": "${env:PERF_DB_URI}" }
    },
    "grafana": {
      "command": "uvx",
      "args": ["mcp-grafana", "--disable-write"],
      "env": {
        "GRAFANA_URL": "https://grafana.example.com",
        "GRAFANA_SERVICE_ACCOUNT_TOKEN": "${env:GRAFANA_RO_TOKEN}"
      }
    }
  }
}

Jeśli zamiast Grafany używasz Datadoga, dodaj wpis zdalny: "datadog": { "url": "https://mcp.datadoghq.com/v1/mcp" }.

Wszystkie trzy konfiguracje biorą URI bazy i token Grafany ze zmiennych PERF_DB_URI i GRAFANA_RO_TOKEN. Załaduj je do powłoki z magazynu sekretów (np. export PERF_DB_URI="$(vault kv get -field=uri secret/perf-ro-db)") zamiast wpisywać wartości ręcznie. W Cursorze ${env:NAME} jest rozwijane przy starcie serwera. Przy claude mcp add i codex mcp add wartość podstawia twoja powłoka w chwili uruchomienia polecenia, a rozwinięty sekret trafia otwartym tekstem do ~/.claude.json lub ~/.codex/config.toml. Ustaw tym plikom odczyt tylko dla siebie (chmod 600), używaj krótkotrwałych poświadczeń tylko do odczytu i unieważnij je po zakończeniu diagnozy. Host Grafany zastąp własnym. get_top_queries w Postgres MCP Pro wymaga rozszerzenia pg_stat_statements, a analiza hipotetycznych indeksów — hypopg; większość zarządzanych usług Postgresa oferuje oba.

Sandbox agenta nie obejmuje serwerów MCP

--sandbox w Codeksie dotyczy poleceń powłoki uruchamianych przez model (codex exec --help, 0.157.1), a tryby uprawnień Claude Code decydują, które wywołania narzędzi wymagają twojej zgody. Żadne z nich nie ogranicza tego, co serwer MCP zrobi po zatwierdzeniu wywołania. Gwarancję tylko do odczytu daje przełącznik serwera plus rola bazy, konto serwisowe i token API z prawem wyłącznie do odczytu. Jeśli masz replikę Postgresa, podłącz serwer do niej.

Jak zdiagnozować regresję p99, niczego nie zmieniając?

Uruchom sesję w trybie planowania lub tylko do odczytu i poproś wyłącznie o diagnozę. Zasada „jeszcze bez poprawek” powstrzymuje agenta przed sięgnięciem po pierwsze wiarygodnie brzmiące rozwiązanie, zanim przeczyta twoje dane.

Claude Code

Tryb planowania ogranicza Claude Code do analizy i spisanego planu. Ma to znaczenie, bo sesje interaktywne startują domyślnie w trybie auto (od v2.1.283, oba kanały wydań w dniu 2026-10-12):

claude --permission-mode plan

Wklej poniższy prompt w sesji. Claude Code poprosi o zgodę przed każdym wywołaniem MCP, którego twoje ustawienia jeszcze nie dopuszczają.

Codex

Wbudowany profil uprawnień :read-only (beta) nie pozwala poleceniom powłoki modelu niczego zapisywać:

codex -c default_permissions=":read-only"

Wklej poniższy prompt w sesji.

Cursor

Otwórz czat agenta w repozytorium, przełącz go w Plan Mode, sprawdź, że panel ustawień MCP pokazuje wszystkie serwery jako połączone, a potem wklej poniższy prompt. W Plan Mode agent analizuje i pisze plan zamiast edytować pliki.

Gotowy prompt: diagnoza regresji opóźnienia p99

Use the kubernetes, grafana (or datadog) and postgres MCP servers. Do not
change anything and do not propose fixes yet.

checkout-service p99 went from ~200 ms to ~3 s starting around 18:00 UTC
today. Compare 17:00-18:00 UTC (baseline) with 18:00-19:30 UTC (incident):

1. Pod CPU/memory, restarts and replica count for checkout-service.
2. The downstream span or dependency whose latency grew the most.
3. Top queries by total time from pg_stat_statements, and connection
   counts against max_connections.
4. Deploys, config changes or HPA events in the 30 minutes before 18:00.

Rank the candidate causes. For each, cite the exact metric, query or event,
its value, and its timestamp, so I can check it in the dashboard. Label
anything you inferred rather than read as INFERRED.

Zanim cokolwiek zmienisz, otwórz dashboard i sam sprawdź dwie z zacytowanych liczb. Jeśli obie się zgadzają, diagnoza opiera się na danych na żywo; jeśli którakolwiek się nie zgadza, zajrzyj do sekcji gdy dostrajanie z agentem idzie źle.

Jak dobrać pule połączeń do limitów Postgresa?

Typowa awaria w szczycie to komunikat Postgresa sorry, too many clients already przy bezczynnym CPU bazy: baza nie jest wolna, po prostu skończyły się jej sloty połączeń. Arytmetyka jest mechaniczna, więc dobrze nadaje się dla agenta, ale łatwo pomylić się w jednym konkretnym miejscu. Bieżąca liczba replik zaniża zapotrzebowanie; w szczycie osiągasz maxReplicas z HPA.

1. Zmierz zapotrzebowanie przy suficie skalowania. Poproś agenta o Σ(maksimum puli × maxReplicas z HPA) dla wszystkich usług współdzielących instancję i porównanie z max_connections pomniejszonym o superuser_reserved_connections oraz połączenia migracji, zadań cron i narzędzi administracyjnych.

2. Żądaj konkretnej konfiguracji, nie porad. Niech agent zaproponuje rozmiary pul dla każdej usługi, a jeśli suma nadal przekracza limit, warstwę PgBouncer w pool_mode = transaction z jawnymi max_client_conn i default_pool_size.

3. Sprawdź, co psuje tryb transakcyjny PgBouncera. Tryb transakcyjny nie przenosi stanu sesji między transakcjami: SET, sesyjne blokady doradcze (advisory locks) i LISTEN zachowują się inaczej, a prepared statements na poziomie protokołu przestają działać, jeśli w PgBouncerze nie włączono max_prepared_statements (PgBouncer 1.21 i nowszy; sprawdź jego wartość w swojej wersji PgBouncera, bo gdy pojawił się w 1.21, był domyślnie wyłączony). Wiele sterowników i ORM-ów domyślnie przygotowuje zapytania, więc sprawdź ustawienie prepared statements w swoim sterowniku, a o resztę poproś agenta: niech przeszuka kod, zanim przełączysz tryb.

4. Wdróż na jedną usługę i obserwuj prawdziwy szczyt. Zmień ustawienia puli w jednym pull requeście i zapisz poprzednie wartości w jego opisie, żeby wycofanie było pojedynczym revertem albo — jeśli ustawienie żyje poza repozytorium — przywróceniem starych wartości.

Gotowy prompt: dobór pul połączeń do max_connections

Use the kubernetes and postgres MCP servers, read-only. Eight services share
one Postgres instance and we see "too many clients already" at peak.

1. For every Deployment that connects to this database, read the pool
   min/max from its env or ConfigMap, its current replicas, and its HPA
   maxReplicas.
2. Read max_connections, superuser_reserved_connections, and the current
   connections grouped by application_name.
3. Show a table: service, pool max, current replicas, maxReplicas, demand at
   maxReplicas. Sum it and compare with the usable limit.
4. Propose per-service pool sizes that fit with 20% headroom. If they cannot
   fit, propose PgBouncer in transaction mode with max_client_conn and
   default_pool_size, and grep this repository for SET, advisory locks,
   LISTEN and protocol-level prepared statements (check the driver/ORM
   prepared-statement setting) that transaction pooling would break.

Show the arithmetic. Do not apply anything.

Jak powstrzymać oscylowanie autoskalera?

HPA, który skaluje w górę za późno, a potem co dwie–trzy minuty skaluje w dół, kosztuje pieniądze i i tak nie łapie szczytu. Większość przypadków wyjaśniają dwa zachowania Kubernetes; agent powinien sprawdzić oba, zanim zaproponuje liczby:

• Stabilizacja skalowania w dół. behavior.scaleDown.stabilizationWindowSeconds domyślnie wynosi 300 sekund. Skalowanie w dół co kilka minut zwykle oznacza, że ktoś to okno skrócił.
• Wykorzystanie liczone względem requestów. Cel CPU 70% oznacza 70% requestu CPU kontenera. Request ustawiony dużo poniżej realnego zużycia sprawia, że HPA reaguje na szum; ustawiony dużo powyżej — że reaguje za późno.

Gotowy prompt: naprawa oscylującego HPA

Use the kubernetes and grafana (or datadog) MCP servers, read-only.

payment-service HPA targets 70% CPU (min 3, max 10). CPU reaches 95% before
it scales up, and it scales down every 2-3 minutes.

1. Read the HPA spec including any behavior block, and the container CPU
   requests and limits.
2. From the last 7 days of metrics, compare actual CPU usage per pod with the
   request, and plot request rate against replica count at the daily peaks.
3. Explain why scaling is late and why it flaps, citing the fields and values.
4. Output a patched HPA manifest with explicit behavior.scaleUp and
   behavior.scaleDown policies and stabilizationWindowSeconds, and say whether
   a request-rate metric would lead CPU for this service. One line per
   changed field explaining why.

Write the manifest to a file for review. Do not apply it.

Przejrzyj manifest jak każdą inną zmianę infrastruktury: przechodzi przez pull request i twój zwykły proces infrastruktury jako kodu, a nie przez kubectl apply z sesji agenta.

Jak udowodnić, że zmiana wydajnościowa zadziałała?

„Agent mówi, że jest szybciej” to nie dowód. Zapisz kryteria akceptacji przed zmianą i pozwól rozstrzygnąć pomiarom. Nikt nie musi czytać rozumowania agenta, żeby zatwierdzić zmianę, bo liczby albo spełniają kryteria, albo nie.

1. Najpierw zapisz kryteria akceptacji. Jedna metryka, jeden próg, jedno okno: „p99 checkoutu poniżej 400 ms i odsetek błędów poniżej 0,5% w szczycie 18:00–21:00 UTC, połączenia do Postgresa poniżej 80% max_connections”. Umieść je w pull requeście.

2. Przed scaleniem zrób test obciążeniowy na stagingu. Odtwórz obciążenie odwzorowujące ruch produkcyjny narzędziem, którego zespół już używa (zobacz testy obciążeniowe, przeciążeniowe i benchmarki). Zmiana puli lub HPA, która przechodzi tylko test ścieżki optymistycznej (happy path), nic nie mówi o współbieżności w szczycie.

3. Zrób wdrożenie kanarkowe na produkcji. Najpierw jedna usługa albo niewielka część replik. Jeśli stosujesz już progresywne wdrażanie, uzależnij promocję od tej samej metryki co kryteria akceptacji.

4. Porównaj to samo okno. Po następnym prawdziwym szczycie porównaj go z tym samym dniem tygodnia tydzień wcześniej, bo szczyt piątkowy i środowy mają inny kształt ruchu. Poproś agenta o raport weryfikacyjny poniższym promptem, a potem sprawdź dwie jego liczby w dashboardzie.

5. Zatwierdź albo wycofaj. Właściciel usługi zatwierdza zmianę względem kryteriów. Jeśli któreś nie jest spełnione, wycofaj: kubectl rollout undo deployment/checkout-service dla zmiany w Deployment albo revert pull requesta dla konfiguracji HPA i puli.

Gotowy prompt: raport weryfikacyjny przed i po

Use the grafana (or datadog), kubernetes and postgres MCP servers, read-only.

The change in PR #1482 (checkout-service pool size and PgBouncer) reached
100% of replicas at 14:00 UTC on 2026-09-24. Acceptance criteria:
p99 < 400 ms, error rate < 0.5% over 18:00-21:00 UTC, Postgres connections
< 80% of max_connections.

Compare 18:00-21:00 UTC on 2026-09-18 (before) with 18:00-21:00 UTC on
2026-09-25 (after). Also compare request volume, so a quieter day is not
mistaken for an improvement. Both dates are Fridays, so the traffic shape
matches.
Output a table: criterion, before, after, threshold, PASS/FAIL, and the exact
query you used for each row.

Dołącz raport i zapytania do zgłoszenia zmiany (change record). W zespołach, które wdrażają zmiany pisane przez agentów z pakietem dowodowym, ta tabela jest jego częścią dotyczącą wydajności.

Jakiego modelu użyć do diagnozy wydajności?

Zacznij od domyślnego modelu narzędzia: Claude Opus 5.5 w Claude Code (na obu kanałach wydań) i GPT-6.1 Sol w Codeksie. Zanim zmienisz model, podnieś poziom wysiłku (effort), a model zmieniaj dopiero wtedy, gdy twoje własne porównania pokażą zysk. Zestawianie śladów, metryk i planów zapytań to praca na długim kontekście, więc tańsze modele sprawdzają się przy sprawdzeniach jednego sygnału, np. „wypisz dziesięć najcięższych zapytań”. Ceny i pełną ofertę znajdziesz w przeglądzie modeli AI.

Gdy dostrajanie wydajności z agentem idzie źle

• Agent odpowiada bez danych. Okrągłe liczby („około 95% CPU”) bez znaczników czasu oznaczają, że agent nie czyta twoich systemów. Uruchom claude mcp list lub codex mcp list albo zajrzyj do ustawień MCP Cursora; napraw niedziałający serwer i ponów prompt. Nie przyjmuj diagnozy z sesji, w której serwer był niedostępny.
• Zacytowana liczba nie zgadza się z dashboardem. Model wypełnił lukę w wyniku zapytania. Poproś go o dokładne zapytanie i surowy wynik dla tej liczby, a potem uruchom zapytanie sam. Resztę tej odpowiedzi traktuj jako niepotwierdzoną.
• Poprawka leczy objaw. Opóźnienie nie drgnęło, bo pula lub HPA były tylko skutkiem, a nie przyczyną problemu. Ponów prompt diagnostyczny z nowymi danymi i poproś o ponowny ranking przyczyn z pominięciem już naprawionej.
• Staging przeszedł, produkcja się pogorszyła. Pula, która wystarcza przy współbieżności stagingu, w szczycie nie nadąża z obsługą połączeń. Najpierw wycofaj zmianę, a potem zrób test obciążeniowy przy współbieżności wynikającej z maxReplicas w HPA, a nie ze średniej.
• Serwer Postgresa nie zwraca nic użytecznego. get_top_queries wymaga pg_stat_statements. Pamiętaj też, że ostatnie wydanie postgres-mcp na PyPI to 0.3.0 z 16.05.2025 (sprawdzone 26.09.2026); jeśli nowsza funkcja Postgresa zawodzi przez ten serwer, uruchom EXPLAIN (ANALYZE, BUFFERS) na replice samodzielnie.
• Agent przypadkiem dostał prawo zapisu. Kubeconfig z kontekstem cluster-admin albo --access-mode=unrestricted skopiowane z README zamienia diagnozę w ryzyko. Przejdź na opisane wyżej poświadczenia tylko do odczytu i sprawdź w logu audytowym, co sesja zmieniła.

Dokąd dalej z wydajnością produkcyjną

• Reagowanie na incydenty z AI: gdy regresja jest awarią, najpierw przeprowadź proces incydentowy, a dostrajaj później.
• Zarządzanie kosztami chmury i FinOps: dobór requestów i autoskalowania to także kwestia kosztów.
• Bezpieczeństwo MCP: jak ograniczać poświadczenia i oceniać serwery MCP, zanim dotkną danych produkcyjnych.
• Praca z bazami danych z AI: jak zamienić znalezione wolne zapytania w zindeksowane, przetestowane zmiany schematu.