Klasyczny scenariusz: piątek, 15:30. Monitoring pokazuje gwałtowny wzrost błędów HTTP 500. Zaczyna się znany scenariusz: sprawdzenie alertu, przejście do metryk, wyszukanie logów, kontrola stanu podów, porównanie z ostatnim deploymentem. Kilka narzędzi, kilka interfejsów i kilka zapytań, zanim powstanie spójny obraz sytuacji.
A gdyby zamiast przełączać się pomiędzy kolejnymi ekranami można było zapytać:
„Co zmieniło się w usłudze payments w ciągu ostatnich 15 minut i co najbardziej koreluje ze wzrostem błędów 500?” Asystent AI mógłby pobrać metryki z Prometheusa, sprawdzić logi w Loki lub Elasticsearch, odczytać informacje o incydencie i dyżurze, a następnie przedstawić operatorowi skorelowany obraz sytuacji. Nie oznacza to końca dashboardów, CLI ani klasycznych narzędzi observability. Oznacza raczej pojawienie się nad nimi nowej warstwy interakcji – konwersacyjnej warstwy operacyjnej. Jednym ze standardów, które umożliwiają jej budowę, jest Model Context Protocol (MCP).
Właśnie taką zmianę niesie ChatOps 2.0: czat przestaje być miejscem, w którym wydaje się polecenia botom, a staje się miejscem, w którym zespół IT zadaje pytania całej infrastrukturze i od razu dostaje odpowiedź z pełnym kontekstem, a decyzje nadal podejmują ludzie.
Spis treści:
- MCP – wspólny język między AI a narzędziami
- Co zmieniło MCP w 2026 roku?
- Observability nie znika. Zmienia się sposób dostępu do danych
- Grafana – metryki i logi dostępne jako narzędzia MCP
- Elastic – rozmowa bezpośrednio z danymi operacyjnymi
- PagerDuty – incydent jako część tej samej rozmowy
- Jeden incydent, kilka źródeł, jedna rozmowa
- Od obserwacji do działania – ale z kontrolą człowieka
- Bezpieczeństwo MCP zaczyna się poza samym protokołem
- Observability dla AI też jest potrzebne
- Czy ChatOps 2.0 skróci MTTR?
- MCP nie zastępuje observability. Łączy jego elementy
- Zintegrowane projektowanie telemetrii i AI
MCP – wspólny język między AI a narzędziami
Model Context Protocol to otwarty standard umożliwiający aplikacjom wykorzystującym modele AI łączenie się z zewnętrznymi danymi i narzędziami za pomocą ujednoliconego interfejsu. MCP został udostępniony jako projekt open source przez Anthropic w listopadzie 2024 r. W grudniu 2025 r. projekt został przekazany do Agentic AI Foundation działającej pod auspicjami Linux Foundation, co wzmocniło jego pozycję jako otwartego, rozwijanego wspólnie standardu.
Idea jest stosunkowo prosta. Zamiast tworzyć osobną, dedykowaną integrację każdego asystenta AI z każdym systemem, aplikacja AI może korzystać z serwerów MCP udostępniających określone możliwości.
Serwer może udostępnić między innymi:
- tools – operacje, które model może wywołać, np. wykonanie zapytania do systemu monitoringu,
- resources – dane i zasoby dostępne do odczytu,
- prompts – przygotowane szablony interakcji udostępniane użytkownikowi.
W praktyce oznacza to, że ten sam asystent może uzyskać kontrolowany dostęp do kilku różnych systemów bez konieczności budowania każdej integracji od podstaw.
MCP nie zastępuje jednak mechanizmów autoryzacji, jakości telemetryki ani wiedzy o znaczeniu danych. Standaryzuje sposób udostępniania kontekstu i funkcji aplikacjom AI – nie sprawia automatycznie, że dane stają się poprawne, kompletne czy bezpieczne.
Co zmieniło MCP w 2026 roku?
Wersja specyfikacji 2026-07-28 wprowadziła istotną zmianę architektoniczną. MCP stał się bezstanowy na poziomie protokołu. Usunięto wcześniejszy handshake initialize/initialized oraz identyfikator sesji protokołu. Każde żądanie zawiera informacje potrzebne do jego obsługi, a klient może opcjonalnie użyć server/discover, aby wcześniej poznać możliwości serwera. Ma to praktyczne znaczenie dla wdrożeń produkcyjnych. Serwery MCP łatwiej skalować za load balancerem, ponieważ kolejne żądania nie muszą trafiać do tej samej instancji serwera. Nie oznacza to oczywiście, że aplikacja nie może utrzymywać własnego stanu. Bezstanowość dotyczy protokołu MCP, a nie całego systemu.
W przypadku połączeń lokalnych nadal stosowany jest m.in. transport stdio, w którym aplikacja uruchamia serwer MCP jako proces lokalny. W rozwiązaniach sieciowych podstawowym kierunkiem jest Streamable HTTP. Starszy transport HTTP+SSE został w specyfikacji 2026-07-28 formalnie oznaczony jako przestarzały, choć w okresie przejściowym nadal może być obsługiwany przez konkretne produkty i biblioteki.
Dla zespołu operacyjnego ważniejszy od szczegółów protokołu jest jednak efekt: AI otrzymuje ustandaryzowany sposób odkrywania i wywoływania funkcji różnych systemów.
Observability nie znika. Zmienia się sposób dostępu do danych
Dashboardy pozostają podstawowym narzędziem observability i monitoringu IT – służą do ciągłego monitoringu, analizy trendów, capacity planningu, śledzenia SLO czy pracy z powtarzalnymi widokami operacyjnymi.
Asystent konwersacyjny sprawdza się w innym miejscu. Jego przewagą jest możliwość łączenia informacji z kilku źródeł i zachowywania kontekstu prowadzonej analizy. Operator nie musi od razu wiedzieć, który dashboard otworzyć ani jakie zapytanie przygotować. Może rozpocząć od problemu: „Dlaczego liczba błędów wzrosła po ostatnim wdrożeniu?”
Asystent może następnie wykorzystać dostępne narzędzia, aby zawęzić zakres analizy. Sprawdzić metryki, przeanalizować logi, znaleźć wyjątki występujące po deploymentcie i zestawić je z informacjami o incydencie. To ważne rozróżnienie: model nie „wie”, co dzieje się w infrastrukturze. Odpytuje źródła, do których otrzymał dostęp, i interpretuje zwrócone dane. Dlatego odpowiedź AI powinna być traktowana jako wsparcie analizy, a nie automatyczny dowód związku przyczynowego.
Grafana – metryki i logi dostępne jako narzędzia MCP
Dobrym przykładem jest open source’owy serwer MCP rozwijany przez Grafana. mcp-grafana może udostępniać asystentowi między innymi narzędzia do pracy z dashboardami, alertami, metrykami, logami, incydentami czy danymi z różnych datasource’ów. Wśród dostępnych operacji znajdują się m.in. zapytania do Prometheusa i Loki. W efekcie pytanie użytkownika: „Czy po wdrożeniu wzrosła liczba timeoutów w payments-api?” może zostać przełożone przez asystenta na odpowiednie wywołanie narzędzia i zapytanie do źródła danych.
Warto przy tym pamiętać o dwóch różnych granicach bezpieczeństwa. Czym innym jest uwierzytelnienie klienta wywołującego serwer MCP, a czym innym poświadczenie, którego sam serwer MCP używa do komunikacji z Grafaną. Dokumentacja Grafany rozdziela te mechanizmy, co pozwala stosować zasadę najmniejszych uprawnień po obu stronach integracji.
Elastic – rozmowa bezpośrednio z danymi operacyjnymi
Podobny model oferuje Elastic poprzez Elastic Agent Builder. Pojawił się on już wcześniej jako funkcja rozwijana w trybie preview, ale od Elastic 9.3 jest dostępny jako rozwiązanie GA. Udostępnia również endpoint MCP, dzięki któremu zewnętrzny host MCP może korzystać z narzędzi Agent Buildera.
Przykładem jest wbudowane narzędzie platform.core.search, pozwalające przeszukiwać dane Elasticsearch przy użyciu zapytania wyrażonego w języku naturalnym. Agent Builder może również korzystać z narzędzi pochodzących z zewnętrznych serwerów MCP. Dzięki temu asystent analizujący incydent może otrzymać możliwość przeszukiwania logów czy danych operacyjnych bez udostępniania mu nieograniczonego dostępu do całego środowiska. Dostęp nadal podlega uprawnieniom Elasticsearch i Kibany. Dla klientów programistycznych mogą być wykorzystywane klucze API, a w Elastic Cloud Serverless MCP obsługuje również OAuth 2.1.
Linux Polska wspiera organizacje w projektowaniu, wdrażaniu i utrzymaniu środowisk Elastic.
PagerDuty – incydent jako część tej samej rozmowy
Trzecim elementem układanki może być PagerDuty. 4 września 2026 r. firma zdeprecjonowała lokalny PagerDuty MCP Server i przeniosła rozwój do hostowanego Remote MCP Server. Istniejące instalacje lokalne mogą nadal działać, ale nie otrzymują nowych funkcji ani poprawek.
Remote MCP Server pozwala agentom m.in. pracować z incydentami, usługami i informacjami o dyżurach. W praktyce oznacza to, że dane o incydencie mogą stać się kolejnym źródłem kontekstu dla asystenta prowadzącego analizę.
Jeden incydent, kilka źródeł, jedna rozmowa
Wróćmy do piątkowego incydentu. Operator pyta: „Co wiemy o błędach 500 w payments-api?”. Asystent może wykonać kilka kroków. Najpierw sprawdza dane dotyczące incydentu i ustala, kiedy rozpoczął się problem oraz jaki serwis jest nim objęty. Następnie korzysta z danych observability. W Prometheusie sprawdza wzrost error rate i zachowanie latency. W logach szuka wyjątków pojawiających się w tym samym przedziale czasu.
Kolejne pytanie operatora może brzmieć: „Czy coś zmieniło się bezpośrednio przed początkiem problemu?”. Jeżeli odpowiednie dane są dostępne dla narzędzi asystenta, może on skorelować czas incydentu z deploymentem, zmianą konfiguracji albo wzrostem obciążenia. Wynik mógłby wyglądać następująco:
Wzrost błędów rozpoczął się kilka minut po wdrożeniu nowej wersji payments-api. W tym samym czasie wzrosło wykorzystanie puli połączeń do bazy danych, a w logach pojawiły się błędy ConnectionTimeoutException. Dane wskazują na silną korelację, ale wymagają potwierdzenia przed uznaniem jej za przyczynę incydentu.
To ostatnie zdanie jest istotne. AI może bardzo szybko połączyć fakty, ale nadal trzeba odróżniać korelację, hipotezę i potwierdzoną przyczynę.
Od obserwacji do działania – ale z kontrolą człowieka
Największa zmiana pojawia się wtedy, gdy MCP przestaje służyć wyłącznie do odczytu. Asystent może potencjalnie nie tylko sprawdzić stan systemu, ale również wywołać narzędzie zmieniające ten stan: zaktualizować incydent, uruchomić workflow, zmienić konfigurację czy wykonać operację naprawczą.
Wówczas granica między AI assistant a AI operator zaczyna się zacierać. Dlatego warto projektować środowisko tak, aby operacje odczytu i zapisu były wyraźnie rozdzielone. Dobrym punktem wyjścia jest tryb read-only, ograniczony zestaw narzędzi i zasada najmniejszych uprawnień. Operacje o wysokim ryzyku powinny wymagać świadomego potwierdzenia użytkownika. MCP 2026-07-28 wspiera również scenariusze, w których serwer może w trakcie wywołania poprosić klienta o dodatkowe dane lub potwierdzenie i dopiero potem kontynuować operację.
Human-in-the-loop nie jest więc przeszkodą w automatyzacji operacji IT. W środowisku produkcyjnym jest jednym z mechanizmów jej kontrolowania.
Bezpieczeństwo MCP zaczyna się poza samym protokołem
Połączenie modelu AI z narzędziami infrastrukturalnymi tworzy nową powierzchnię ataku. Jednym z najważniejszych problemów jest prompt injection – również pośredni. Złośliwa instrukcja nie musi pochodzić bezpośrednio od użytkownika. Może znaleźć się w dokumencie, logu, odpowiedzi narzędzia lub innym materiale, który agent pobiera jako kontekst.
OWASP MCP Top 10 wskazuje między innymi ryzyka związane z niewłaściwym zarządzaniem tokenami i sekretami, tool poisoning, prompt injection, brakiem audytu, niekontrolowanymi serwerami MCP oraz nadmiernym współdzieleniem kontekstu. Dlatego nawet w środowisku odizolowanym od Internetu nie należy zakładać, że wszystkie dane przekazywane modelowi są zaufane.
Drugim ważnym elementem jest zarządzanie poświadczeniami. Specyfikacja MCP jednoznacznie zabrania traktowania tokenu klienta jako uniwersalnego poświadczenia przekazywanego dalej do systemów backendowych. Token przeznaczony dla serwera MCP powinien być zweryfikowany jako przeznaczony właśnie dla niego, a dostęp serwera do kolejnych usług powinien korzystać z właściwych dla nich mechanizmów uwierzytelnienia.
W przypadku lokalnych serwerów uruchamianych przez stdio dochodzi jeszcze jeden aspekt: proces MCP działa z uprawnieniami systemowymi, które otrzymał. Jeżeli nie zastosujemy sandboxingu lub innego mechanizmu izolacji, jego możliwości mogą być znacznie szersze niż te, które chcieliśmy udostępnić modelowi.
Observability dla AI też jest potrzebne
Jeżeli AI staje się częścią procesu operacyjnego, samo również powinno podlegać obserwowalności. W praktyce warto wiedzieć:
- jakie narzędzie zostało wywołane i jak długo trwało wykonanie,
- czy operacja zakończyła się sukcesem, błędem czy timeoutem,
- jakie wersje klienta, serwera i modelu brały udział w operacji,
- czy wymagane było potwierdzenie użytkownika albo decyzja polityki bezpieczeństwa,
- jaki trace lub correlation ID łączy rozmowę z operacjami backendowymi,
- jaki był koszt i wykorzystanie tokenów.
Nie oznacza to jednak automatycznego zapisywania całych promptów, parametrów i odpowiedzi modelu. Mogą one zawierać dane osobowe, sekrety lub informacje biznesowo wrażliwe. Zakres takiej telemetrii powinien być świadomą decyzją architektoniczną i bezpieczeństwa.
Co ciekawe, same implementacje MCP zaczynają dostarczać coraz lepszą telemetrykę. Na przykład mcp-grafana może eksportować metryki Prometheusa oraz tracing OpenTelemetry dla operacji MCP.
Czy ChatOps 2.0 skróci MTTR?
Potencjalnie – tak. Największą korzyścią nie musi być jednak „inteligencja” samego modelu. Może nią być ograniczenie czasu traconego na przechodzenie między narzędziami, ręczne budowanie zapytań i przenoszenie kontekstu pomiędzy kolejnymi etapami analizy. Asystent może przejąć część tej pracy i pozwolić operatorowi koncentrować się na decyzjach. Nie warto jednak z góry zakładać konkretnej poprawy MTTR. Lepiej ją zmierzyć. Dobry pilotaż powinien porównywać między innymi:
- czas od alertu do pierwszej użytecznej hipotezy,
- czas potrzebny na zebranie danych z kilku systemów,
- liczbę ręcznych przełączeń między narzędziami,
- odsetek poprawnych i błędnych hipotez generowanych przez AI,
- czas do potwierdzenia przyczyny i przywrócenia usługi.
Dopiero takie dane pokażą, czy konwersacyjny model operacji rzeczywiście poprawia efektywność konkretnego zespołu.
MCP nie zastępuje observability. Łączy jego elementy
Najbardziej interesującą cechą MCP nie jest możliwość „rozmawiania z Prometheusem”.
Wartość pojawia się wtedy, gdy jedna rozmowa może objąć kilka systemów jednocześnie: monitoring, logi, incydenty, dokumentację, konfigurację i – przy odpowiednich zabezpieczeniach – również mechanizmy automatyzacji. Dashboard nadal będzie najlepszym miejscem do obserwowania trendu. CLI nadal będzie niezastąpione przy wielu precyzyjnych operacjach. Runbook nadal będzie definiował sprawdzony sposób postępowania.
MCP dodaje do tego warstwę orkiestracji kontekstu. Dzięki niej operator może zacząć nie od pytania: „Które narzędzie mam teraz otworzyć?” ale od właściwego problemu: „Co się dzieje z moją usługą?”
To może być jeden z bardziej praktycznych kierunków rozwoju ChatOps. Nie zastępowanie narzędzi operacyjnych przez AI, lecz umożliwienie AI bezpiecznej i kontrolowanej pracy z narzędziami, które organizacja już posiada.
Zintegrowane projektowanie telemetrii i AI
Observability nie sprowadza się do wdrożenia jednego narzędzia. Jakość wyników zależy od architektury telemetrycznej, spójności danych, ich kontekstu oraz kontroli dostępu.
Podsumowanie
W Linux Polska patrzymy na ten model właśnie z tej perspektywy – jako na połączenie kompetencji z zakresu Linux, Kubernetes, observability, Elastic i AI w ramach podejścia Security, Observability & AI.
Bezpieczne połączenie warstwy operacyjnej z analityką zasilaną sztuczną inteligencją wymaga precyzyjnego zaprojektowania modelu tożsamości i autoryzacji, wdrożenia zasady least privilege oraz określenia granic zaufania między komponentami. Zapraszamy do kontaktu, aby omówić gotowość środowiska do bezpiecznych integracji konwersacyjnych, odpowiedni model uprawnień oraz architekturę łączącą AI z warstwą observability.
