SREday London 2026 Q3
24 września 2026 roku, Everyman Canary Wharf w Londynie zamieni się na jeden dzień w centrum rozmów o niezawodności, obserwowalności i tym, co AI robi z rolą inżyniera SRE. SREday London Q3 to trzecia londyńska edycja w tym roku — i zgodnie z tradycją cyklu, trzy równoległe ścieżki przez cały dzień, ponad 30 prelegentów i zaledwie 150+ uczestników, co gwarantuje kameralne rozmowy niemożliwe na wielotysięcznych konferencjach.
Keynote'y — trzy perspektywy na SRE w erze AI
„7 Deadly Traps of SRE" — Miko Pawlikowski (SRE Author, 9:00)
Keynote otwierający od Miko Pawlikowskiego — autora książki o SRE i inżyniera platformowego w Quadrature, który wcześniej prowadził inicjatywy SRE w Citadel i Bloomberg. Tytuł mówi sam za siebie: SRE pełne jest wzorców, które wyglądają jak najlepsze praktyki, ale po cichu podkopują niezawodność.
Od obsesji na punkcie pięciu dziewiątek, przez kult bohaterstwa dyżurnego, po fałszywy komfort narzędzi i list kontrolnych — każda pułapka zostanie rozeznana i skontrontowana z tym, co faktycznie działa. Obowiązkowy punkt programu dla każdego, kto ma dość gaszenia pożarów zamiast budowania niezawodnych systemów.
„AI Needs a New Data Platform" — Peter Marshall (Imply, 9:30)
Keynote od dyrektora relacji deweloperskich w Imply, twórcy platformy analitycznej opartej na Apache Druid. Teza: agenty AI generują tysiące równoległych dochodzeń, zmieniając ekonomikę przechowywania i obliczania danych. Platformy bezpieczeństwa i obserwowalności ewoluują w kierunku otwartego storage'u, elastycznych obliczeń i odsprzężonych architektur — i trzeba zrozumieć dlaczego.
„On-Call for Things You Did Not Provision" — Rob Reid (Cockroach Labs, 10:00)
Keynote, który dotyka coraz częstszego scenariusza: samoobsługowa infrastruktura sprawia, że ludzie i agenty provisionują bazy danych bez angażowania SRE, ale gdy coś się psuje, te same zespoły SRE lądują na dyżurze dla infrastruktury, której nie wdrażały. Rob Reid — autor książki „Practical CockroachDB" i Technical Evangelist w Cockroach Labs — przedstawi jak utrzymać niezawodność gdy park baz danych rośnie, i jak warstwa operacji agentowych może zmniejszyć obciążenie przez ciągłą obserwację i rekomendacje — z ludzkimi decyzjami o tym co faktycznie się wykonuje.
Sesje warte szczególnej uwagi — według ścieżek tematycznych
Obserwowalność agentów AI
„Your Agent Did What? Forensic Observability for Systems That Don't Leave Obvious Footprints" Adriana Villela (Dynatrace) & Kasper Borg Nissen (Dash0), 12:30
Jedna z najciekawiej zatytułowanych sesji całej konferencji — zawartość jest równie interesująca co tytuł. Przestrzeń obserwowalności GenAI jest zdezintegrowana: OpenInference, OpenLLMetry i konwencje specyficzne dla frameworków rozwiązują te same problemy z niekompatybilnymi nazwami atrybutów.
Adriana i Kasper — CNCF Ambassadors oboje — pokażą jak genainormalizer processor w warstwie kolektora OTel łata tę lukę, i co rzeczywiście mówi Twoja telemetria gdy agent coś skasuje. Niezbędne dla każdego, kto uruchamia agenty AI w środowiskach produkcyjnych.
„Agentic Observability | The Path to AI Co-SRE" Shyam Sreevalsan (Netdata), 13:00
Trzy lata budowania produkcyjnych systemów obserwowalności AI, w tym silnik konsensusu 18 modeli osiągający współczynnik fałszywych pozytywów 10⁻³⁶ i framework złożony z 22 wyspecjalizowanych agentów diagnostycznych. Matematyczny argument za ensemble'ami modeli zamiast alertowania progowego, wzorce orkiestracji wieloagentowej i realistyczna ocena gdzie technologia stoi dziś.
„Topology, Not Telemetry" Louis Fradin (Anyshift.io), 12:00 (ścieżka 2)
Analiza awarii Cloudflare z 18 listopada 2025 roku — gdy zmiana uprawnień w jednej wewnętrznej bazie danych wyłączyła Workers KV, Access, Turnstile i Dashboard na ponad trzy godziny. Monitoring złapał skok w sekundy. Znalezienie przyczyny zajęło godziny — bo prawdziwy łańcuch był w topologii, nie w telemetrii. Louis Fradin z Anyshift.io zrekonstruował graf topologii tej awarii i pokaże, jak agent AI przeszedł od alertu do wadliwego commita w zaledwie 30 sekund — zamiast 20 minut czy nawet 2 godzin, których potrzebowałby znający kod człowiek.
Terraform i IaC — sesja obowiązkowa
„Safe Terraform auto-apply with conftest" Ricard Bejarano & Josep Medialdea (Cisco), 13:30
Ricard zarządza pipeline'em Terraform z 500+ deweloperami, ponad 140 000 zasobów i wieloma tysiącami planów dziennie w Cisco ThousandEyes. W skali, ludzki przegląd planów Terraform przestaje być mechanizmem bezpieczeństwa, a staje się wąskim gardłem. Delegowanie do AI łamie wymagania compliance i usuwa ludzką odpowiedzialność. Trzecia droga: conftest — policy-as-code, który można uzasadnić, wersjonować, testować i któremu można ufać. Bardzo konkretna, praktyczna sesja od kogoś kto robi to produkcujnie na ogromną skalę.
„Letting Agents Change Production Without Breaking It" Ehsan Ashouri (Justice AI Unit), 15:30 (ścieżka 3)
terraform validate/plan dowodzą intencji, nie że zmiana jest faktycznie bezpieczna w realnym świecie. Ehsan z Justice AI Unit (UK Ministry of Justice) pokaże jak budować harnesses używając paradygmatu software factory z cyfrowym bliźniakiem chmury, który wdraża każdą zmianę (plan → apply → destroy na prawdziwych dostawcach chmury) zanim trafi do produkcyjnego repo. Bezpośrednie zastosowanie dla każdego środowiska Terraform zarządzanego przez agenty.
Kubernetes i FinOps
„Finding the 33% Your Kubernetes Clusters Are Wasting" Ozlem Tanrikulu (Near East University), 15:30 (ścieżka 2)
Prelegentka zbudowała Burn — open-source'owe CLI, które czyta kubeconfig, pobiera ceny z AWS i Azure API i daje rozbicie kosztów per przestrzeń nazw w 30 sekund. Bez agenta, bez dashboardu, bez zmian w klastrze. Na produkcji znalazła 33% nieużywanej pojemności, pod żądający 500m CPU ale używający 0.12m, i debug pody których nikt nie pamięta. Kasper i matematyka kosztów Kubernetes wyjaśnione przez kogoś, kto rozwiązał problem dla siebie — a potem udostępnił narzędzie publicznie.
Produkcyjne AI dla SRE
„Beyond CPU and Memory: Reliability Signals for Production AI" Trupti Kolekar (GBST), 13:30 (ścieżka 3)
Żądanie może zwrócić HTTP 200 podczas gdy użytkownik doświadcza wolnego generowania tokenów, słabej jakości retrieval, złamanych wywołań narzędzi, przekroczenia limitów modelu lub niespodziewanych skoków kosztów. Trupti — Senior SRE z certyfikatami CKA, AWS i HashiCorp — mapuje tradycyjne koncepty SRE (SLI, SLO, capacity planning, rollback) na produkcyjne workloady AI. Konkretne wskaźniki: Time to First Token, inference latency end-to-end, tokens per second, queue depth, GPU saturation, retrieval success, fallback success.
„AI-Native SRE at Alibaba Cloud" Yitian Xu (Alibaba Cloud), 15:00 (ścieżka 2)
Jak Alibaba Cloud stosuje AI do prawdziwych workloadów SRE w skali chmury: segregacja zaszumionych sygnałów, korelacja telemetrii, streszczanie kontekstu incydentów, prognozowanie pojemności, copilot incydentów, uczenie się z postmortemów. Ważne: jak budować fundament dla AI-wspomaganego SRE z odpowiednimi ścieżkami audytu i rollback.
Odporność i disaster recovery
„Automate the Work, Not the Thinking: Why Disaster Recovery Comes First" Gabriel Okiri (Admiral Group Plc), 12:00 (ścieżka 3)
Podczas redukcji EBS storage na flocie 142 serwerów jeden serwer baz danych po cichu wypadł z listy DR. Gdy automatyzacja zadziałała, ta jedna luka pozwoliła rsync na uszkodzenie ok. 700 GB danych produkcyjnych. Sesja o kulisach inżynierii niezawodności: dlaczego pozostawienie starego wolumenu do weryfikacji zamieniło o krok od katastrofy w czysty rollback. Zasada, którą każdy SRE powinien wytatuować na swoich runbookach: DR musi domyślnie obejmować każdy system — bo automatyzacja jest tylko tak bezpieczna jak plan odbudowy stojący za nią.
„The Hypervisor Hunger Games" Michael Cade (Veeam Software), 12:30 (ścieżka 2)
Kubernetes jako system operacyjny dla infrastruktury enterprise — KubeVirt VMs, mikrousługi kontenerowe i control plane DevOps (GitHub, Jira) zarządzane razem. Jak integrować niezmienne polityki ochrony danych bezpośrednio w deklaratywne pipeline'y GitOps (ArgoCD) i automatyzować odbudowę wielo-klastrową tak by stan odbudowywał się tak szybko jak kod.
Ludzka strona SRE
„Human SRE: Applying Reliability Engineering to the System Behind the Systems" Gena Frangina (IT Stress Relief), 12:30 (ścieżka 3)
SRE dało nam potężne sposoby projektowania systemów przeżywających awarie. Ale co z ludźmi odpowiedzialnymi za utrzymanie tych systemów? Inżynierowie mogą godzinami badać usługę, ignorując własne sygnały ostrzegawcze: zmniejszona koncentracja, zmęczenie decyzjami, eskalująca frustracja, niemożność odłączenia się po incydencie. Gena — z doświadczeniem w inżynierii oprogramowania, psychologii biznesu i hipnoterapii klinicznej — wprowadza praktyczny model Human SRE: Observe, Respond, Recover and Learn.
Trendy i GreenOps
„From Waterfall to Cloudburst" Alttaf Hussain (Yoti), 13:00 (ścieżka 2)
Cykl wytwarzania oprogramowania uległ radykalnej kompresji. Waterfall dawał nam miesiące, Agile tygodnie, a development wspomagany przez AI przynosi nagłe ulewy (cloudbursts): intencja staje się kodem niemal natychmiast. Większość organizacji próbuje przyjąć tę powódź za pomocą systemów odprowadzania zaprojektowanych z myślą o mżawce. Oto praktyczny framework: żadne przyspieszenie nie przyniesie efektu, dopóki nie zbudujemy odpowiedniego zbiornika retencyjnego (review architecture, policy-as-code, feature flags, chaos engineering).
„The Green Pipe: GreenOps Decides Where You'll Pop" Leo Visser (OGD ict-diensten), 16:00 (ścieżka 1)
Pipeline CI/CD używający danych o emisjach energii do decyzji kiedy najlepiej uruchomić. Ograniczenie cykli obliczeniowych przez uruchamianie tylko testów wpływanych przez zmianę. Skanowanie szablonów wdrożeń pod kątem bardziej zrównoważonych opcji. GreenOps jako jednoczesna redukcja śladu węglowego i kosztów infrastruktury.
Plan dnia — szybkie podsumowanie
| Godzina | Ścieżka 1 | Ścieżka 2 | Ścieżka 3 |
|---|---|---|---|
| 9:00 | Keynote: 7 Deadly Traps of SRE | — | — |
| 9:30 | Keynote: AI Needs a New Data Platform | — | — |
| 10:00 | Keynote: On-Call for Things You Did Not Provision | — | — |
| 11:30 | Przerwa kawowa | ||
| 12:00 | SREs, Shadow AI, and the AI CoE | Topology, Not Telemetry | Automate the Work, Not the Thinking |
| 12:30 | Your Agent Did What? | Hypervisor Hunger Games | Human SRE |
| 13:00 | Agentic Observability | From Waterfall to Cloudburst | CI/CD Pipelines for Landing Zone on AWS |
| 13:30 | Safe Terraform auto-apply | SRE State Of Play | Beyond CPU and Memory |
| 14:00 | Lunch & networking | ||
| 15:00 | Ephemeral Environments | AI-Native SRE at Alibaba | Beyond Root Cause |
| 15:30 | You can't retrofit self-healing | Finding the 33% Wasting | Letting Agents Change Production |
| 16:00 | The Green Pipe | AI Agents in Enterprise: Reality | The Rise of Agentic SRE |
| 16:30 | Stranger Platforms (IDP) | Agent Run Phase | Learning SRE by Accident |
| 17:00 | Networking & sponsor crawl | ||
| 17:30 | Wrap up |
Dlaczego ta edycja jest warta uwagi
Agenda SREday London Q3 2026 jest jedną z najbardziej spójnych tematycznie edycji w historii cyklu — niemal każda sesja, nawet te pozornie niezwiązane z AI, jest osadzona w kontekście tego, co agenty AI i automatyzacja robią z rolą SRE.
Trzy wątki przewijają się przez cały dzień: agentic SRE — od keynote'ów przez sesje Netdata, Scrubbe i StackGen po prezentację Justice AI Unit; obserwowalność systemów niedeterministycznych — Adriana Villela, Louis Fradin i Trupti Kolekar każdy z innej perspektywy, ale z tym samym pytaniem: co telemetria faktycznie mówi gdy agent zrobi coś nieoczekiwanego; i governance jako nowa wąskie gardło — Cisco, Yoti, Cognizant i Microsoft każdy po kolei wskazują że problem nie jest w tym czy AI potrafi generować kod i infrastrukturę, ale kto i jak decyduje co z tym kodem się dzieje.
Rejestracja
Bilety dostępne na sreday.com/2026-london-q3 przez Luma. Poprzednie edycje w Londynie rozchodziły się szybko — przy ponad 30 prelegentach i limicie 150+ uczestników, miejsca są ograniczone.
Dla czytelników devopsnews.pl planujących udział — za miesiąc czeka kolejna edycja SREday bliżej domu: 22 października 2026, Warszawa, Google for Startups Campus.
Źródło: oficjalna strona konferencji sreday.com/2026-london-q3
Comments ()