Reagowanie na incydenty wspomagane przez AI

Jest 02:47. PagerDuty wrzeszczy o błędach płatności, masz otwartych sześć dashboardów rozsianych po Datadog, Grafana i Sentry, a Twój PM już pyta o ETA. Wąskim gardłem nigdy nie jest sama naprawa — to te dziesięć minut zbierania kontekstu, zanim w ogóle wiesz, co się zepsuło. Dokładnie tę pracę może wykonać asystent AI podłączony do Twojego stosu obserwowalności, gdy Ty jeszcze szukasz laptopa.

Co z tego wyniesiesz

• Wielokrotnego użytku prompt do korelacji alertów, który ściąga sygnały z Datadog, Grafana i Sentry na jedną oś czasu
• Prompt do bezpiecznej automatycznej naprawy z bramami pewności i twardymi ograniczeniami bezpieczeństwa
• Generator post-mortemów, który rekonstruuje oś czasu z danych monitoringu
• Poprawne, zweryfikowane polecenia instalacji MCP dla Sentry, Datadog, Grafana i PagerDuty w Cursor, Claude Code i Codex
• Etapowy plan wdrożenia, dzięki któremu najpierw automatyzujesz diagnozę, a naprawę na końcu

Podłączanie stosu obserwowalności przez MCP

Wszystko poniżej opiera się na serwerach MCP, które łączą Twojego asystenta AI z narzędziami monitoringu. Konfiguracja MCP jest identyczna w Cursor, Claude Code i Codex — wszystkie trzy czytają tę samą konfigurację serwera, więc każdy serwer konfigurujesz raz. Najszybsza ścieżka w 2026 to oficjalne zdalne (hostowane) serwery: uwierzytelniają się przez OAuth w przeglądarce, więc nie ma długowiecznych tokenów API do wklejania ani rotowania.

Sentry

Cursor

Dodaj do projektowego .cursor/mcp.json (lub globalnego ~/.cursor/mcp.json):

{
  "mcpServers": {
    "sentry": {
      "url": "https://mcp.sentry.dev/mcp"
    }
  }
}

Cursor otwiera okno OAuth przy pierwszym użyciu — token nie jest potrzebny.

Claude Code

Zdalnie (zalecane, OAuth):

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

Awaryjnie self-hosted przez stdio (używa @sentry/mcp-server, wymaga tokenu):

claude mcp add sentry \
  --env SENTRY_HOST=sentry.io \
  --env SENTRY_ACCESS_TOKEN=YOUR_TOKEN \
  -- npx -y @sentry/mcp-server

Codex

Dodaj do ~/.codex/config.toml:

[mcp_servers.sentry]
url = "https://mcp.sentry.dev/mcp"

Codex obsługuje uzgadnianie OAuth przy pierwszym połączeniu.

Serwer Sentry udostępnia zgłoszenia błędów, ślady stosu, wydania oraz analyze_issue_with_seer do analizy przyczyny źródłowej wspieranej przez AI.

Datadog

Datadog udostępnia teraz oficjalny zdalny serwer MCP (już nie w wersji Preview). Użyj endpointu US poniżej lub https://mcp.datadoghq.eu/api/unstable/mcp-server/mcp dla witryny EU.

Cursor

{
  "mcpServers": {
    "datadog": {
      "url": "https://mcp.datadoghq.com/api/unstable/mcp-server/mcp"
    }
  }
}

Claude Code

claude mcp add --transport http datadog https://mcp.datadoghq.com/api/unstable/mcp-server/mcp

Awaryjnie self-hosted (społecznościowy, npm @winor30/mcp-server-datadog):

claude mcp add datadog \
  --env DD_API_KEY=YOUR_KEY \
  --env DD_APP_KEY=YOUR_APP_KEY \
  -- npx -y @winor30/mcp-server-datadog

Codex

[mcp_servers.datadog]
url = "https://mcp.datadoghq.com/api/unstable/mcp-server/mcp"

Grafana i PagerDuty

Cursor

Grafana (self-hosted przez npm @leval/mcp-grafana) i PagerDuty (oficjalny zdalny) w jednej konfiguracji:

{
  "mcpServers": {
    "grafana": {
      "command": "npx",
      "args": ["-y", "@leval/mcp-grafana"],
      "env": {
        "GRAFANA_URL": "https://your-org.grafana.net",
        "GRAFANA_API_KEY": "YOUR_SERVICE_ACCOUNT_TOKEN"
      }
    },
    "pagerduty": {
      "url": "https://mcp.pagerduty.com/mcp"
    }
  }
}

Claude Code

# Grafana (self-hosted stdio)
claude mcp add grafana \
  --env GRAFANA_URL=https://your-org.grafana.net \
  --env GRAFANA_API_KEY=YOUR_SERVICE_ACCOUNT_TOKEN \
  -- npx -y @leval/mcp-grafana

# PagerDuty oficjalny zdalny (OAuth)
claude mcp add --transport http pagerduty https://mcp.pagerduty.com/mcp

Notatka

PagerDuty udostępnia też oficjalny serwer lokalny, ale działa on na Pythonie przez uvx pagerduty-mcp, a nie npx. Domyślnie jest tylko do odczytu — dodaj --enable-write-tools tylko jeśli chcesz, by agent potwierdzał lub rozwiązywał incydenty.

Codex

[mcp_servers.grafana]
command = "npx"
args = ["-y", "@leval/mcp-grafana"]
env = { "GRAFANA_URL" = "https://your-org.grafana.net", "GRAFANA_API_KEY" = "YOUR_SERVICE_ACCOUNT_TOKEN" }

[mcp_servers.pagerduty]
url = "https://mcp.pagerduty.com/mcp"

Uwaga

Serwery MCP uruchamiasz, nazywając je w języku naturalnym („Używając serwerów MCP Datadog i Sentry, …”), a nie prefiksem @server. W Cursor ani Claude Code nie ma składni czatu w stylu @datadog — agent sam dobiera właściwy serwer na podstawie Twojego tekstu i opisów serwerów, a przed każdym wywołaniem narzędzia prosi Cię o zatwierdzenie.

Inteligentna korelacja alertów

Pierwsze zadanie w każdym incydencie to przebicie się przez szum. Zamiast wpatrywać się w sześć dashboardów, niech AI skoreluje sygnały według usługi i znacznika czasu w jedną oś czasu. Ta część przepływu pracy jest w zasadzie identyczna we wszystkich trzech narzędziach — różni się tylko punkt wejścia.

Cursor

Otwórz panel Agenta w Cursorze (Cmd/Ctrl+I) i wklej poniższy prompt korelacyjny. Agent po kolei odpytuje każdy serwer MCP i renderuje ujednoliconą oś czasu w miejscu.

Claude Code

Uruchom go headless z terminala, żeby przekierować wynik prosto na kanał incydentu:

claude -p "Using the Datadog, Grafana, and Sentry MCP servers, correlate the last 30 minutes of alerts into one timeline grouped by service."

Codex

Użyj CLI z zatwierdzeniami tylko do odczytu, żeby podczas triażu agent mógł odpytywać, ale nigdy niczego nie zmieniał:

codex --ask-for-approval untrusted --sandbox read-only \
  "Using the Datadog, Grafana, and Sentry MCP servers, correlate the last 30 minutes of alerts into one timeline grouped by service."

Wskazówka

Prompt do skopiowania do korelacji alertów między narzędziami:

Using the Datadog, Grafana, and Sentry MCP servers, analyze our current
incident landscape:

1. List all critical alerts and firing monitors from the last 30 minutes.
2. Correlate them by affected service and timestamp — group signals that
   are almost certainly the same root cause.
3. Pull the top error patterns from Sentry for the affected services.
4. Flag which alerts are likely false positives or downstream symptoms.
5. Output a single timeline (UTC) and a one-line probable root cause with a
   confidence level. Do not take any remediation action.

Skorelowana odpowiedź jest zwięzła — oś czasu plus hipoteza, a nie ściana dashboardów. Na przykład (poglądowo):

Probable root cause: payment-service DB connection pool exhaustion (confidence: high)

02:30  payment-service v2.3.1 deployed (pool size 100 -> 10)
02:45  DB connection timeouts +400% (Grafana); error rate 0.2% -> 15% (Datadog)
02:47  User-facing checkout errors spike (Sentry, ConnectionTimeoutError 67%)

Recommendation: roll back v2.3.1; verify pool size before re-deploy.

Ten krok korelacji normalnie pochłania dziesięć minut ręcznego przeskakiwania między dashboardami.

Pogłębione dochodzenie

Gdy masz już hipotezę, popchnij AI do potwierdzenia jej względem baselinów, ostatnich zmian i stanu zależności, zanim ktokolwiek tknie produkcję. To jest identyczne we wszystkich narzędziach — wklej prompt do tego agenta, w którym korelowałeś alerty.

Wskazówka

Prompt do skopiowania do ustrukturyzowanego dochodzenia incydentu:

Using the Datadog, Sentry, and GitHub MCP servers, investigate the
payment-service incident and produce a structured report:

1. METRICS: error rate, p95 latency, and throughput for payment-service vs
   the trailing 7-day baseline. State exactly when degradation started (UTC).
2. ERRORS: top 3 Sentry error patterns and the endpoints they hit.
3. CHANGES: every deploy and config change to payment-service in the last
   4 hours, with timestamps and PR links.
4. DEPENDENCIES: health of the database, cache, and any upstream APIs.
5. IMPACT: estimate affected requests and revenue, and whether specific
   regions or customer tiers are hit harder.

End with a ranked action list and a confidence level for each action.
Investigate only — do not execute changes.

Wartość tkwi tu w orkiestracji: jeden prompt rozchodzi się po metrykach, błędach i kontroli wersji, zamiast żebyś ręcznie odpalał kilkanaście zapytań. Z podłączonym serwerem Sentry możesz też poprosić go o uruchomienie Seer („Use Sentry’s Seer to analyze issue PROJECT-1234 and propose a fix”), aby uzyskać analizę przyczyny źródłowej wspieraną przez AI dla konkretnego błędu.

Bezpieczna automatyczna naprawa

Dla dobrze rozpoznanych, wielokrotnie widzianych awarii AI może przejść od diagnozy do działania — ale wyłącznie za jawnymi bramami pewności i krokiem zatwierdzenia przez człowieka. Tutaj narzędzia naprawdę się rozchodzą, bo każde inaczej wymusza zatwierdzenia.

Cursor

Tryb Agenta w Cursorze proponuje edycje (np. PR z wycofaniem albo zmianę wartości Helm) i pokazuje diff, który zatwierdzasz, zanim cokolwiek się wykona. Dla serwerów z prawem zapisu trzymaj automatyczne uruchamianie narzędzi MCP wyłączone, żeby każde modyfikujące wywołanie wymagało kliknięcia. Załóż checkpoint przed startem, żeby móc cofnąć całą sesję jednym ruchem.

Claude Code

Uruchom interaktywnie (nie -p), żeby każda akcja Bash/MCP wyświetlała prośbę o uprawnienie. Zawężaj dozwolone narzędzia ściśle, zamiast przyznawać dostęp całościowy:

claude --allowedTools "Read,Edit,Bash(git*)" \
  "Roll back payment-service to the last healthy release."

Podczas trwającego incydentu nigdy nie sięgaj po --dangerously-skip-permissions.

Codex

--ask-for-approval on-request w Codeksie zatrzymuje się przed każdym poleceniem; --full-auto (sandbox workspace-write + zatwierdzenia on-request) to najwięcej, co powinieneś przyznać, i tylko dla pętli wyłącznie monitorującej:

codex --ask-for-approval on-request \
  "Prepare a rollback PR for payment-service to the last healthy release and wait for my approval before pushing."

Wskazówka

Prompt do skopiowania do bramkowanej automatycznej naprawy:

Using the GitHub MCP server, execute a SAFE remediation for the
payment-service connection-pool incident:

1. Confirm this matches a previously-resolved pattern (pool exhaustion after
   a deploy). State the matching past incident.
2. Only if confidence > 90%:
   - Open a rollback PR to the last healthy release.
   - Propose a temporary connection-pool bump as a separate diff.
3. After I approve and merge, monitor error rate and p95 latency for 5 min.
4. Document every action taken for the post-mortem.

SAFETY CONSTRAINTS:
- Require my explicit confirmation before ANY production change.
- Abort immediately and page me if any metric worsens.
- Never run destructive commands (drop, delete, force-push).

Jeśli zamiast działania wolisz pasywny nadzór, podmień cel na samo monitorowanie:

Wskazówka

Prompt do skopiowania do śledzenia powrotu do normy w trybie wyłącznie monitorującym:

Using the Datadog and Grafana MCP servers, monitor recovery for the
payment-service incident. Every 30 seconds report whether error rate, p95
latency, and queue depth are trending down. Tell me when it is safe to
resolve. Do NOT execute any changes.

Komunikacja podczas incydentu

Codex naturalnie pasuje do warstwy komunikacji ze względu na integracje ze Slackiem i GitHubem na różnych powierzchniach — możesz prowadzić aktualizacje z aplikacji lub z Cloud, podczas gdy w terminalu wciąż skupiasz się na naprawie.

Cursor

Cursor zostaje w IDE, więc komunikację trzymaj ręcznie albo ją deleguj: sam wklejaj podsumowanie statusu od AI na swój kanał incydentu. Cursor sprawdza się najlepiej przy naprawie z rękami na klawiaturze, a nie w pętli z interesariuszami.

Claude Code

Wygeneruj aktualizację headless i przekieruj ją prosto na Slacka przez oficjalny serwer MCP Slacka albo opublikuj ją własnym CLI:

claude -p "Write a 5-line incident status update for #incidents-critical: current status, impact, what we've done, ETA, next update time."

Codex

Podłącz Codex do Slacka/GitHuba i pozwól mu prowadzić cykliczne aktualizacje, podczas gdy Ty pracujesz nad naprawą. Z aplikacji Codex lub z Cloud skieruj go na wątek incydentu i niech publikuje postępy w stałym rytmie.

Wskazówka

Prompt do skopiowania do automatycznej aktualizacji statusu:

Using the Slack and PagerDuty MCP servers, draft an incident status update
for #incidents-critical:

- Severity and current status (Investigating / Mitigating / Resolved)
- User-facing impact in plain language (no internal jargon)
- Actions taken so far and what's in progress
- Best-estimate ETA and the time of the next update
- @-mention the incident commander and on-call

Keep it under 6 lines. Show it to me before posting.

Analiza po incydencie

Prawdziwą wypłatą jest nauka. AI rekonstruuje oś czasu z tych samych danych monitoringu, które odpytywało na żywo, więc post-mortem pisze się sam z faktów, a nie z mglistych wspomnień. Ten krok jest identyczny we wszystkich narzędziach — użyj tego, które masz akurat otwarte.

Wskazówka

Prompt do skopiowania do szkicu post-mortemu:

Using the Datadog, Sentry, and GitHub MCP servers, draft a blameless
post-mortem for the payment-service incident:

1. TIMELINE: exact sequence from monitoring data, correlated with deploys
   and config changes, including responder actions and response times.
2. IMPACT: affected requests, revenue, customer tiers, and SLA/error-budget
   burn.
3. ROOT CAUSE: technical cause with supporting evidence, plus contributing
   factors and why existing alerts didn't catch it sooner.
4. ACTION ITEMS: concrete prevention work, each with a suggested owner and
   rough effort. Separate "stop the bleeding" from "never again".

Format as a standard post-mortem doc. Be blameless — describe systems and
decisions, not people.

Ten sam wzorzec możesz uruchomić na danych z wielu miesięcy („analyze incident patterns over the last 90 days and rank prevention opportunities by incidents-prevented per dev-day”), aby znaleźć powracające przyczyny źródłowe warte wyeliminowania inżynieryjnie.

Kiedy to się psuje

Uwaga

Agent zmyśla metryki zamiast je odpytywać. Jeśli za jakimś „wynikiem” nie stoi wywołanie narzędzia, model halucynuje dashboard. Obserwuj log wywołań narzędzi; jeśli nie widzisz żadnego, serwer MCP nie jest podłączony albo agent go nie dobrał. Wskaż serwer ponownie z nazwy i potwierdź połączenie.

• Serwer MCP nie chce się połączyć. Przy serwerach zdalnych okno OAuth mogło zostać zablokowane albo token wygasł — ponów połączenie. Wylistuj skonfigurowane serwery poleceniem claude mcp list (lub sprawdź panel ustawień MCP w Cursorze) i potwierdź status. Większość awarii to wygasły token albo brakujący zakres uprawnień, a nie zepsuty serwer. Pełny triage znajdziesz w Problemy z połączeniem MCP.
• Niezgodność npx i uvx. Serwery oparte na Pythonie (jak lokalny serwer PagerDuty) nie wystartują pod npx. Jeśli serwer stdio błyskawicznie zwraca błąd, sprawdź, czy jest publikowany na npm czy na PyPI, i użyj pasującego runnera.
• Agent działa za bardzo. Podczas incydentu uruchamiaj Claude Code interaktywnie (nie -p), trzymaj Codex na zatwierdzeniach on-request, a w Cursorze zostaw automatyczne uruchamianie wyłączone dla serwerów z prawem zapisu. Jeśli mimo to działa za szybko, zawęź --allowedTools do narzędzi tylko do odczytu i dodaj do promptu jawną linijkę „require confirmation before any production change”.
• Za dużo szumu w aktualizacjach. Każ promptowi komunikacyjnemu grupować powiązane alerty w jedno powiadomienie i publikować tylko przy zmianach stanu, a nie przy każdym tiknięciu metryki.

Co dalej

• Pipeline’y CI/CD — wyłap złe wdrożenie, zanim Cię wezwie
• Infrastruktura jako kod — zarządzaj wycofaniami, które uruchamia ten artykuł
• Niezbędne serwery MCP — głębszy materiał o konfiguracji serwerów użytych tutaj
• Monitoring i obserwowalność — proaktywna warstwa, która wzywa Cię wcześniej i z mniejszym szumem

Zacznij od jednego serwera i jednego przepływu pracy: podłącz Sentry, uruchom prompt korelacyjny przy następnym prawdziwym wezwaniu i trzymaj każdą naprawę ręcznie, dopóki diagnoza nie będzie niezawodnie trafna. Stąd automatyzuj na zewnątrz.