Rozwój systemów rozproszonych z AI

Rozwój systemów rozproszonych z AI działa kontraktowo: interfejsy serwisów definiuje się przed implementacją, więc Cursor, Claude Code i Codex generują i walidują kod względem współdzielonej specyfikacji zamiast zgadywać zachowanie innego serwisu. Kroki sagi, propagację kontekstu śladu i migracje schematów z podwójną publikacją buduje się i weryfikuje pojedynczo, bo awarie kryją się między serwisami.

Zmieniasz jedno pole w API serwisu Order, a trzy inne serwisy zaczynają zwracać błędy 500 na środowisku staging. Ślad jest niekompletny, bo dwa serwisy nigdy nie przekazały kontekstu śladu, saga przetwarzająca płatności po cichu pominęła krok kompensacji, a twój dashboard dyżurny świeci na zielono, podczas gdy klienci nie mogą sfinalizować zakupu. Trzy serwisy, trzy repozytoria, trzy różne zespoły — a narzędzie AI, którym sterujesz, widzi tylko to jedno otwarte repozytorium.

To właśnie w tej luce asystenci AI są najbardziej przydatni i najbardziej niebezpieczni: szybko generują wiarygodny szkielet wielu serwisów, ale „wygeneruj cały system produkcyjny” daje ci kod, którego nie jesteś w stanie zweryfikować. Ten przewodnik obejmuje te części, w których AI jest naprawdę dobre — szkicowanie zrębów serwisów, przekazywanie kontekstu śladu, pisanie nudnej logiki kompensacji — przy jednoczesnym utrzymaniu pętli weryfikacji na tyle ciasnej, że bez wahania wdrożysz wynik.

Co daje ten przepływ pracy dla systemów rozproszonych

Pliki reguł dla każdego narzędzia, które dają agentowi widzącemu jedno repozytorium brakujący kontekst integracji między serwisami
Gotowe prompty do projektowania granic serwisów, rozszerzania istniejącego kontraktu od strony endpointu i audytu klienta względem kontraktu, który rzekomo implementuje
Przepis na sagę budowaną po jednym kroku, każdy wraz z kompensacją i testem, który najpierw nie przechodzi
Plan migracji schematu z podwójną publikacją, który przeprowadza producentów i konsumentów przez zmianę wersji bez wzajemnego psucia się
Debugowanie oparte na śladzie i przyrostowe instrumentowanie OpenTelemetry, które zweryfikujesz w Jaegerze, zanim zrobisz z niego szablon
Realne, zweryfikowane serwery MCP do monitorowania (Sentry, Grafana, Dynatrace) i infrastruktury (Docker, Kubernetes, AWS) — wraz z dokładnymi poleceniami instalacji
Kroki naprawcze na tryby awarii, które naprawdę dają się we znaki: zerwany kontekst śladu, brakująca kompensacja w sadze, dryf kontraktów i błędy uwierzytelniania MCP

Dlaczego jedno otwarte repozytorium to za mało kontekstu

Mikrousługi dzielą system na repozytoria, języki i zespoły. Narzędzia AI widzą jedno repozytorium naraz, co oznacza, że domyślne założenie modelu — że ten serwis jest samodzielną aplikacją — jest błędne dokładnie w tych miejscach, które psują produkcję. Lekarstwem jest zakodowanie kontraktów i konwencji między serwisami wewnątrz każdego repozytorium, tak by kontekst integracji był zawsze załadowany niezależnie od tego, czy pamiętasz o nim wspomnieć.

Przechowuj definicje kontraktów w repozytorium serwisu i nazwij je w pliku reguł:

This service (order-service) communicates with:
- payment-service: REST API, OpenAPI spec at /contracts/payment-api.yaml
- inventory-service: Events via RabbitMQ, schemas at /contracts/inventory-events.json
- notification-service: Events via RabbitMQ, schemas at /contracts/notification-events.json

When implementing any integration:
1. Always read the relevant contract file first
2. Generate client code from the contract, do not hand-write it
3. Include retry logic with exponential backoff for all HTTP calls
4. Include dead-letter queue handling for all event consumers

Użyj @contracts/payment-api.yaml, aby wciągnąć konkretny kontrakt do konwersacji.

Claude Code czyta pliki kontraktów bezpośrednio, więc wskaż w CLAUDE.md katalog i zapisz zasadę regeneracji:

Microservice: order-service
Contracts directory: /contracts/
- payment-api.yaml (OpenAPI 3.1) - payment-service REST API
- inventory-events.json (AsyncAPI 2.6) - inventory-service event schemas
- notification-events.json (AsyncAPI 2.6) - notification-service events

Integration rules:
- All HTTP clients must use the generated SDK in /src/clients/
- Regenerate clients when contracts change: npm run generate-clients
- All event publishers must validate against the schema before publishing
- Circuit breaker pattern required for all external service calls

Codex może sięgnąć do wielu repozytoriów przez integrację z GitHubem, więc nazwij repozytoria siostrzane i miejsce, gdzie leżą współdzielone kontrakty:

This is part of a microservices architecture. Related repos:
- org/payment-service - Payment processing
- org/inventory-service - Stock management
- org/notification-service - User notifications

Shared contracts are in org/service-contracts repo.
When making changes that affect service boundaries:
1. Check the contract in org/service-contracts first
2. Update the contract if needed (creates PR to service-contracts)
3. Implement the change in this service
4. Note any downstream services that need updates

Serwery MCP, które naprawdę istnieją

Drugą połową problemu kontekstu jest żywa infrastruktura: pozwolenie AI, by ją odpytywało, bije pozwalanie mu zgadywać. Ale ekosystem jest pełen łudząco podobnych paczek npm — sentry-mcp to mało popularna zaślepka, a nie serwer Sentry. Korzystaj z tych zweryfikowanych serwerów. Konfiguracja MCP jest identyczna w Cursorze, Claude Code i Codeksie: wszystkie trzy czytają te same definicje serwerów (.mcp.json dla Claude Code, .cursor/mcp.json dla Cursora, ~/.codex/config.toml dla Codeksa), więc poniższe polecenia działają niezależnie od tego, którego narzędzia używasz.

Monitorowanie i obserwowalność

Sentry (błędy, ślady, wydania) — użyj oficjalnego, hostowanego serwera z OAuth, bez tokena do zarządzania:
Okno terminala
```
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
```
Dla samodzielnie hostowanego Sentry oficjalną paczką npm jest @sentry/mcp-server:
Okno terminala
```
claude mcp add sentry -- npx -y @sentry/mcp-server@latest --access-token=YOUR_TOKEN
```
Grafana (dashboardy, zapytania Loki/Prometheus, incydenty) — oficjalny serwer to grafana/mcp-grafana, binarka Go dystrybuowana przez Dockera (nie ma paczki npm mcp-grafana):
Okno terminala
```
claude mcp add grafana -- docker run --rm -i \
  -e GRAFANA_URL=http://localhost:3000 \
  -e GRAFANA_SERVICE_ACCOUNT_TOKEN=YOUR_TOKEN \
  grafana/mcp-grafana -t stdio
```
Dynatrace (APM, wykrywanie anomalii przez AI) — oficjalna paczka jest publikowana przez organizację Dynatrace OSS i wymaga Node 22.10+:
Okno terminala
```
DT_ENVIRONMENT=https://YOUR.apps.dynatrace.com \
  claude mcp add dynatrace -- npx -y @dynatrace-oss/dynatrace-mcp-server@latest
```

Kontenery i infrastruktura

Docker — oficjalny MCP jest dostarczany z MCP Toolkit w Docker Desktop; uruchamiasz bramę zamiast paczki npm:
Okno terminala
```
claude mcp add docker -- docker mcp gateway run
```
W Cursorze dodaj serwer typu polecenie w Settings → MCP, wskazując na to samo docker mcp gateway run.
Kubernetes — kubernetes-mcp-server to prawdziwa paczka; używa twojego bieżącego kontekstu kubeconfig:
Okno terminala
```
claude mcp add k8s -- npx -y kubernetes-mcp-server@latest
```
AWS — AWS Labs publikuje serwery o konkretnym przeznaczeniu (nie jeden monolityczny obraz). Wybierz ten, którego potrzebujesz, i polegaj na standardowym łańcuchu poświadczeń AWS, zamiast wpisywać klucze na sztywno:
Okno terminala
```
claude mcp add aws-api -- uvx awslabs.aws-api-mcp-server@latest
```
Przejrzyj pełny katalog na awslabs.github.io/mcp. Dla Google Cloud wdróż własny serwer MCP na Cloud Run — zobacz cloud.google.com/run/docs.

Projektowanie granic serwisów

AI szybko szkicuje propozycje ograniczonych kontekstów, ale granice to decyzja biznesowa — traktuj wynik jako pierwszą wersję do dyskusji, a nie wyrok. Zacznij wąsko: poproś o granice wraz z uzasadnieniem, abyś mógł wychwycić, gdzie model pomylił warstwę techniczną z domeną.

I have an e-commerce monolith with these features: user management,
product catalog, inventory tracking, order processing, payments,
shipping, notifications. Propose microservice boundaries using
domain-driven design. For each proposed service, give me:
(1) the bounded context and the single team that would own it,
(2) the data it owns exclusively,
(3) which other services it talks to and whether that's sync or async.

Flag any place where two contexts share a database or a write path—those
are coupling risks I need to resolve before splitting.

Gdy uzgodnisz już granice, projektuj po jednym serwisie naraz. Oprzyj się pokusie „wygeneruj wszystkie serwisy” — nie da się zrecenzować zrzutu siedmiu serwisów, a to właśnie w kontraktach między nimi kryją się błędy.

For the Order Processing context, design the service contract only (not
the implementation yet): the REST endpoints with request/response
schemas, the domain events it publishes (OrderCreated, OrderConfirmed,
OrderCancelled) with their payloads, and the events it consumes from
Payment and Inventory. Output the OpenAPI spec and the event schemas as
separate files. Do not generate business logic—I want to review the
contract first.

Zmiana istniejącego kontraktu, najpierw endpoint

Powyższy prompt projektuje kontrakt od zera. Na co dzień rozszerzasz taki, który już istnieje, a dyscyplina jest ta sama, tylko odwrócona: zmień specyfikację, pozwól specyfikacji wygenerować kod i przejrzyj specyfikację, zanim pojawi się choć linia implementacji.

I need to add a refund endpoint to the payment service. Work contract-first:
1. Read the existing OpenAPI spec at /contracts/payment-api.yaml
2. Add a POST /payments/{paymentId}/refund endpoint to the spec with:
   - Request body: { amount: number, reason: string, idempotencyKey: string }
   - Response 200: { refundId: string, status: "pending" | "completed", amount: number }
   - Response 404: Payment not found
   - Response 409: Refund already exists for this idempotency key
   - Response 422: Amount exceeds original payment
3. Generate the Express route handler from the contract
4. Generate the client SDK method from the contract
5. Generate integration test stubs from the contract

Show me the updated contract before generating any implementation code.

Kontrakty zaczynają dryfować w chwili, gdy ktoś ręcznie edytuje klienta. AI dobrze to wyłapuje i do audytu potrzebuje tylko twojej strony granicy — drugą stroną jest plik kontraktu. Każde narzędzie ma dla tego audytu naturalną formę:

Compare our order-service HTTP client for the payment service
against the payment-api.yaml contract:
1. Are we handling all documented error codes?
2. Are we sending all required headers?
3. Are we respecting rate limits and timeouts from the spec?
4. Are there any fields we're ignoring in responses that we should handle?

claude "Read /contracts/payment-api.yaml and /src/clients/payment-client.ts.
Perform a contract compliance audit:
- List every endpoint in the contract and whether our client implements it
- Check error handling for every documented error response
- Verify request/response types match the schema
- Check timeout and retry configurations against SLA requirements
Output as a compliance checklist with pass/fail for each item."

Audit contract compliance for the order-service against all its upstream contracts.
For each contract in /contracts/:
1. Find the corresponding client implementation in /src/clients/
2. Verify every endpoint, error code, and schema field is handled
3. Check for missing retry logic, circuit breakers, and timeout handling
4. Create issues for any violations found

Uruchamiaj ten audyt w CI, a nie tylko na żądanie: to npm run validate-contracts łamiące build powstrzymuje dryf przed dotarciem na produkcję.

Wzorce saga, które naprawdę da się zweryfikować

Wzorzec saga to miejsce, gdzie wygenerowany przez AI kod rozproszony najczęściej wygląda dobrze, a jest błędny. Tryb awarii jest zawsze taki sam: ścieżka szczęśliwa działa, ale krok kompensacji nie jest idempotentny albo brakuje budżetu czasowego (timeout). Lekarstwem jest budowanie po jednym kroku naraz, każdego wraz z jego kompensacją i najpierw testem, który nie przechodzi, a potem obserwowanie, jak zmienia się na zielony.

Otwórz repozytorium serwisu Order i przełącz się w tryb Agent. Poproś o jeden krok sagi wraz z testem, który nie przechodzi, uruchom test w terminalu Cursora i zaakceptuj diff dopiero, gdy zmieni się na zielony. Użyj punktu kontrolnego (checkpoint) przed każdym krokiem, abyś mógł cofnąć złą kompensację bez utraty poprzednich kroków. Widok inline diff w Cursorze ułatwia wychwycenie, gdy model „naprawił” test, osłabiając asercję zamiast kodu.

Steruj nim z terminala, aby uruchomienie testu było częścią pętli. Claude Code potrafi uruchomić test, odczytać błąd i iterować bez kopiowania i wklejania danych wyjściowych przez ciebie:

claude "Implement step 3 of the order saga (process payment) plus its
compensation (refund). Write a failing test that asserts the refund fires
when step 4 throws, then make it pass. Run the test with `npm test -- saga`
and show me the diff before committing."

Dodaj hook w .claude/settings.json, który uruchamia zestaw testów sagi przy każdej edycji w saga/, aby regresja we wcześniejszym kroku natychmiast wychodziła na jaw.

Użyj dedykowanego git worktree, aby praca nad sagą była odizolowana we własnym lokalnym checkoucie, a następnie pozwól Codeksowi uruchamiać zestaw testów po każdym kroku. ChatGPT desktop może utworzyć opcjonalny zarządzany worktree; zadania CLI i IDE używają wybranego przez ciebie checkoutu:

codex --sandbox workspace-write -c approval_policy=on-request "Implement the payment step of the order
saga with an idempotent compensation. Add a test that injects a failure at
the inventory step and asserts payment is refunded exactly once on retry.
Run the suite and stop for my review before applying."

Implement one step of the orchestrator-based order saga: "reserve
inventory." Requirements: (1) the step is idempotent—calling it twice
with the same order ID reserves once; (2) it has a compensation that
releases the reservation; (3) a 30s timeout budget, after which the
orchestrator triggers compensation.

Write the failing test first: simulate the payment step (the next step)
throwing, and assert the inventory reservation is released exactly once.
Then implement until the test passes. Show me the test and the diff—do
not add the remaining saga steps yet.

Powiąż każdy krok z obserwowalnym sprawdzeniem: gdy model twierdzi, że krok działa, uruchom ten jeden test, który dowodzi, że kompensacja się odpala. Jeśli nie potrafisz wyrazić testu, nie możesz ufać kodowi.

Komunikacja między serwisami i kontekst śladu

Konfiguracje service mesh i bramy są dla AI bardzo opłacalne — ale znów, przyrostowo. Zacznij od najmniejszej konfiguracji, którą da się zweryfikować jednym poleceniem (curl, istioctl analyze), a potem nakładaj wagi canary i wyłączniki obwodu.

Generate the minimal Istio config to enforce mTLS between the order and
payment services: one PeerAuthentication in STRICT mode plus the
DestinationRule. Give me the exact `istioctl analyze` and `curl` commands
to confirm mTLS is active and that plaintext calls are rejected. Once
that's verified, I'll ask you to add a 90/10 canary VirtualService—don't
add traffic splitting or circuit breakers yet.

W przepływach sterowanych zdarzeniami nawracający błąd produkcyjny to zerwany ślad: serwis konsumuje wiadomość Kafki, ale nigdy nie wyodrębnia i ponownie nie wstrzykuje kontekstu śladu, więc ślad urywa się w ślepym zaułku. Gdy prosisz AI o podłączenie konsumentów, uczyń propagację kontekstu jawnym, przetestowanym wymaganiem — a nie kwestią dodaną na końcu.

Generate a Node.js Kafka consumer template for the Order domain using
KafkaJS and OpenTelemetry. The critical requirement: extract the trace
context from incoming message headers and make it the active context for
the handler span, then inject the current context into headers of any
message it produces. Include a test that publishes a message with a known
traceId and asserts the downstream produced message carries the same
traceId. Handle poison messages with a dead-letter topic.

Gdy coś jednak pęknie na granicy, pracuj od śladu wstecz, a nie od serwisu, który akurat masz otwarty. Podaj AI oś czasu śladu i tego jednego konsumenta, którego podejrzewasz, i zmuś je do wyjaśnienia, dlaczego awaria jest sporadyczna — to pytanie odróżnia prawdziwą diagnozę od wiarygodnie brzmiącej.

I have a distributed trace showing this sequence:
1. web-gateway receives POST /checkout (200ms)
2. order-service creates order (150ms)
3. payment-service charges card (800ms, success)
4. inventory-service.reserve event published (50ms)
5. inventory-service.reserve event consumed (TIMEOUT after 30s)
6. order-service times out waiting for inventory confirmation

The inventory service logs show the event was received but processing hung.
Analyze our inventory service event consumer at /src/consumers/reserve.consumer.ts
and identify:
- Where the processing could hang (database locks, external calls, deadlocks)
- Why it only fails intermittently (race conditions, connection pool exhaustion)
- What observability we're missing (metrics, structured logs, health checks)

Rozproszone migracje schematów

Zmiana formatu danych przekraczającego granicę serwisu to nie zmiana kodu, tylko choreografia. Producenci i konsumenci wdrażają się niezależnie, więc jedyna bezpieczna ścieżka to taka, w której stary i nowy format są poprawne jednocześnie.

Zdefiniuj nową wersję schematu

Dodaj nowy schemat obok starego. Jeszcze go nie zastępuj.
Zaktualizuj producentów, aby publikowali obie wersje

Serwis produkujący wysyła zdarzenia w obu formatach — starym i nowym — w okresie przejściowym.
Zaktualizuj konsumentów, aby akceptowali obie wersje

Każdy konsumujący serwis obsługuje obie wersje schematu elegancko.
Zweryfikuj, że wszyscy konsumenci zostali zaktualizowani

Monitoruj, czy żaden serwis nie konsumuje jeszcze starego formatu — metryką, nie założeniem.
Usuń stary schemat

Dopiero po migracji wszystkich konsumentów przestań produkować stary format i go usuń.

I need to add a `currency` field to the PaymentCompleted event that's consumed by
order-service, notification-service, and analytics-service.

Generate a backward-compatible migration plan:
1. Update the event schema in /contracts/payment-events.json to v2 with currency field
2. Modify the payment-service publisher to emit both v1 and v2 events
3. Generate a v2 event consumer that handles both versions (check for currency field, default to "USD" if missing)
4. Create a test that verifies backward compatibility with v1 events
5. Add a metric to track which consumers are still on v1

Start with the contract change and show me before proceeding.

Obserwowalność: instrumentuj przyrostowo

Nowoczesna obserwowalność wykroczyła poza dashboardy ku wykrywaniu anomalii sterowanemu AI i analizie podstawowych przyczyn świadomej topologii — ale wciąż zdobywasz ją po jednym serwisie naraz. Podejście „zinstrumentuj 8 serwisów i 3 bazy danych w jednym promcie” daje konfigurację, której nie da się zwalidować. Zinstrumentuj jeden serwis od początku do końca, potwierdź, że span pojawia się w Jaegerze, a potem zrób z tego szablon.

Add OpenTelemetry auto-instrumentation to the Order service
(Node.js/Express). Auto-instrument the HTTP server and the Postgres
client, add one custom span around the order-creation business logic, and
export traces to a local Jaeger via OTLP. Give me the exact steps to send
one request and confirm the trace appears in Jaeger at localhost:16686,
including the custom span. Once I confirm, I'll ask you to extract this
into a shared instrumentation module the other services import.

Gdy ten pierwszy ślad już dotrze, szersza instrumentacja jest szablonem, a nie zakładem, i warto poprosić o cały kształt naraz — spany, skorelowane logi, health checki i metryki — bo każdy element da się teraz zweryfikować względem działającej bazy odniesienia.

Set up distributed tracing for our Express-based microservice:
1. Add OpenTelemetry instrumentation with automatic trace propagation
2. Include custom spans for: database queries, external HTTP calls, message queue operations
3. Add structured logging with trace ID correlation (use pino)
4. Create a health check endpoint that verifies all downstream dependencies
5. Add Prometheus metrics for: request duration, error rate, active connections, queue depth

Follow our existing patterns in /src/middleware/ for consistency.
Include the Docker Compose configuration for a local Jaeger instance.

Z podłączonymi serwerami MCP Grafany i Sentry możesz domknąć pętlę bez opuszczania edytora: poproś AI, by wyciągnęło faktyczny wskaźnik błędów albo najwolniejszy ślad dla serwisu i przeanalizowało go, zamiast robić zrzut ekranu dashboardu.

Using the Sentry MCP, find the top 3 unresolved issues for the
payment-service project in the last 6 hours, ranked by event count. For
the most frequent one, pull the stack trace and the linked trace, identify
which downstream call failed, and propose a fix as a diff. Don't apply
it—explain the root cause first so I can confirm.

Koordynowanie zmian w wielu repozytoriach

Funkcja taka jak „punkty lojalnościowe” dotyka serwisów Customer, Order, Payment i Notification. To problem koordynacji — a nie kod poszczególnych serwisów — czyni to trudnym, a trzy narzędzia podchodzą do tego naprawdę odmiennie.

Otwórz wszystkie cztery repozytoria serwisów w jednym wieloźródłowym workspace, aby agent widział każdy kontrakt naraz. Zaprojektuj najpierw kontrakty OpenAPI/zdarzeń, a potem użyj agenta w tle do zaimplementowania każdego serwisu w kolejności zależności, recenzując diffy per repozytorium. Punkty kontrolne na poziomie pliku w Cursorze pozwalają cofnąć zmiany jednego serwisu bez rozplątywania pozostałych. Najlepsze, gdy chcesz wizualnie obserwować i sterować diffem każdego serwisu.

Oskryptuj koordynację. Claude Code działa bezgłowo (headless), więc możesz sterować każdym repozytorium nieinteraktywnie i bramkować na testach kontraktów:

for svc in customer order payment notification; do
  (cd "../$svc" && claude -p "Implement the loyalty-points changes per
    ../contracts/loyalty.openapi.yaml. Add Pact contract tests against the
    services you call. Stop if any contract test fails." \
    --allowedTools Read Edit Bash)
done

Pod-agenci i bezgłowy tryb -p czynią Claude Code najlepszym wyborem, gdy zmiana jest mechaniczna w wielu repozytoriach i chcesz mieć ją audytowalną w CI.

We're adding Customer Loyalty Points across Customer, Order, Payment, and
Notification services. Step 1 only: design the API contracts and event
schemas (OpenAPI + event payloads) and a dependency-ordered implementation
plan that says which service to change first and why. Add the contract
tests (Pact) that must pass between each pair before we deploy. Do not
implement any service yet—I want to review the contracts and the sequence.

Gdy psują się systemy rozproszone wspomagane przez AI

Systemy rozproszone psują się w sposób, którego nie wychwytuje sposób myślenia o pojedynczym serwisie. Oto tryby awarii, które naprawdę wychodzą na jaw przy pracy wspomaganej AI, i sposoby na wyjście z nich.

Kontekst śladu urywa się na granicy asynchronicznej. Żądanie pojawia się w Jaegerze przez dwa skoki, a potem znika. Konsument nie wyodrębnił kontekstu śladu z nagłówków wiadomości. Przeszukaj konsumenta pod kątem wyodrębniania kontekstu; jeśli go brak, poproś AI o dodanie propagacji opartej na nagłówkach oraz testu, który potwierdza, że znany traceId przetrwa skok (zobacz prompt dla Kafki powyżej). Nie ufaj „dodałem śledzenie” — zweryfikuj traceId od początku do końca.
Saga zostawia osierocony stan. Płatność się powiodła, ale zapasy nigdy nie zostały zwolnione po awarii w dół strumienia. Kompensacja jest brakująca lub nieidempotentna. Odtwórz problem, wstrzykując awarię na kroku po tym, który podejrzewasz, i potwierdź, że kompensacja odpala się dokładnie raz. Przebuduj ten krok z promptem „najpierw test, który nie przechodzi”; nigdy nie akceptuj logiki kompensacji bez testu, który ją wyzwala.
AI traktuje każdy serwis jak samodzielną aplikację. Wygenerowany kod ignoruje kontrakt, wymyśla kształt endpointu albo pomija konwencje ponawiania i kolejek dead-letter, których trzyma się każdy inny serwis. Repozytorium nie ma sekcji integracyjnej w .cursor/rules / CLAUDE.md / AGENTS.md — dodaj ją, jawnie nazywając pliki kontraktów, zanim obwinisz model.
Wygenerowany kod klienta nie pasuje do kontraktu. Regeneruj klientów z kontraktów, nie pisz ich ręcznie. Potem wstaw audyt zgodności do CI, żeby dryf łamał build, zamiast wychodzić na jaw jako 422 na produkcji.
Zmiana kontraktu psuje serwisy w dół strumienia na produkcji. Pominąłeś fazę podwójnej publikacji. Uruchamiaj obie wersje schematu jednocześnie podczas migracji i użyj metryki śledzenia wersji, aby potwierdzić, że każdy konsument się przeniósł, zanim usuniesz stary format.
Uwierzytelnianie serwera MCP zawodzi lub nic nie zwraca. Narzędzie się łączy, ale każde zapytanie kończy się błędem albo zwraca pustkę. Zwykle to brakujący/wygasły token lub błędna zmienna środowiskowa (GRAFANA_SERVICE_ACCOUNT_TOKEN, DT_ENVIRONMENT, nieukończony OAuth Sentry). Uruchom claude mcp list, aby potwierdzić, że serwer jest połączony, sprawdź ponownie zmienne środowiskowe względem poleceń instalacji powyżej, a dla hostowanego serwera Sentry ponownie przejdź przepływ OAuth. Jeśli npm view <pkg> pokazuje podejrzanie niską liczbę pobrań, zainstalowałeś podróbkę — przeinstaluj oficjalną paczkę z przestrzenią nazw.
AI wygenerowało „rozproszony monolit”. Serwisy, które muszą być wdrażane razem, albo dwa serwisy zapisujące do tej samej tabeli. To wada projektowa, której model sam z siebie nie zgłosi. Poproś go o audyt: „Wypisz każde miejsce, gdzie dwa serwisy współdzielą bazę danych, ścieżkę zapisu lub muszą być wdrażane w blokadzie”. Rozwiąż te przypadki, zanim podzielisz dalej — współdzielone ścieżki zapisu niweczą sens mikrousług.
Debugowanie rozproszone wciąż trwa wieczność. AI pomaga znacznie mniej, gdy ma do dyspozycji tylko surowe pliki logów do ręcznego korelowania. Najpierw zainwestuj w warstwę obserwowalności: ustrukturyzowane logi niosące traceId, prawdziwy backend śladów i serwer MCP, który potrafi odpytać jedno i drugie. Powyższy prompt oparty na śladzie jest wart dokładnie tyle, ile ślad, który mu podasz.
Automatyczne cofnięcie canary nigdy się nie odpala. Wdrożenie poszło źle, ale pozostało na 100%. Próg cofnięcia odwołuje się do metryki, która nie jest emitowana, albo nazwa metryki jest błędna. Potwierdź, że metryki golden signals istnieją w Prometheus/Grafanie (użyj MCP Grafany, aby je odpytać), zanim zaczniesz polegać na automatycznym cofaniu, i przetestuj ścieżkę cofnięcia na staging z celowo wadliwym buildem.

Dokąd dalej z mikrousługami

Monitorowanie i obserwowalność — wejdź głębiej w OpenTelemetry, dashboardy Grafany i pętlę debugowania z MCP Sentry
Reagowanie na incydenty — przepływy dyżurów wspomagane AI dla awarii systemów rozproszonych
Automatyzacja potoków z AI — buildy świadome zmian i bezpieczne wdrożenia progresywne dla serwisów, które właśnie wydzieliłeś
Infrastruktura jako kod z asystentami AI — Terraform, Pulumi i serwery MCP dostawców, które osadzają AI w realnym stanie
Wzorce testów integracyjnych — testowanie kontraktów i weryfikacja granic serwisów bez kruchych atrap
Testowanie API — testowanie kontraktowe i automatyzacja API przez granice serwisów
Niezbędne serwery MCP dla każdego dewelopera — fundamentalne serwery stojące za każdym z powyższych przepływów