Konrad Kowalski (rootsher)Principal Platform & Reliability Architect000111110110111001110110010110011001011100010111

kategorie

rolaESC ×

Principal Platform & Reliability Architect

Po kolei - z czego składa się ta rola i co w każdym z obszarów do niej należy.

01
Automatyzacja i kultura DevOpsInfrastructure as Code
Promowanie podejścia Infrastructure as Code (IaC, np. Terraform) zamiast klikania po konsoli, pakowanie usług w Helm charty i wdrażanie ich na Kubernetes w modelu GitOps - ArgoCD pilnuje, żeby stan klastra zgadzał się z repozytorium, więc wdrożenie jest scaleniem gałęzi. Automatyzacja procesów CI/CD zdejmuje z zespołu powtarzalną pracę manualną (tzw. toil).
02
Standardy SRE i observabilitySLI / SLO
Wdrażanie observability, czyli zdolności odpowiedzenia na pytanie „co się właśnie stało” bez logowania się na serwer: Prometheus i Grafana pod metryki oraz alerty, New Relic jako APM - logi, ślady żądań, czasy odpowiedzi i wąskie gardła w jednym miejscu, OpenTelemetry jako niezależny od dostawcy sposób instrumentacji, Sentry pod błędy aplikacji. Określanie na tym wskaźników stabilności: SLI (Service Level Indicators) oraz SLO (Service Level Objectives).
03
Strategia i przywództwoPrincipal Level
Wyznaczanie kierunku technologicznego całej firmy razem z biznesem, CTO oraz innymi architektami - „Principal” to pozycja ekspercka na poziomie dyrektorskim, ale bez bezpośredniego zarządzania ludźmi (ścieżka IC - Individual Contributor). Taka osoba nie chodzi na spotkania z klientami: jej robota idzie do wewnątrz - spiąć zespół, zdjąć mu z drogi blokady, dopilnować, żeby nie brakowało narzędzi, dostępów ani decyzji.
04
Projektowanie platformyPlatform Architecture
Projektowanie i utrzymywanie platformy, na której stoją wszystkie usługi firmy: klaster Kubernetes, sieć, sekrety, uprawnienia, wdrożenia, chmura pod spodem (AWS, Azure, GCP). Zespół dostaje gotowe środowisko i jedną komendę do wdrożenia, a nie serwer do skonfigurowania.
05
Bezpieczeństwo platformySecurity by default
Wbudowywanie bezpieczeństwa w platformę, zamiast doklejania go audytem na końcu: sekrety w Vaulcie i nigdy w repozytorium, dostęp po najmniejszych potrzebnych uprawnieniach (least privilege), ruch między usługami spięty service meshem (np. Istio, Linkerd) - z szyfrowaniem mTLS i politykami mówiącymi, kto z kim może rozmawiać - a obrazy i zależności skanowane w pipelinie. Podatność łata się wtedy wdrożeniem, a nie zgłoszeniem.
06
Niezawodność i skalowalnośćReliability & Scalability
Definiowanie strategii odporności systemów na awarie (resiliency) i projektowanie ich tak, aby wytrzymywały nagłe skoki ruchu, automatycznie naprawiały się po awarii (self-healing) i spełniały wysokie normy dostępności (np. SLA na poziomie 99,99%).

p99

wpisy (1)

2026-09-02CPU w Kubernetes od kernela w górę12/12
Anatomia problemu CPU: od zaniżonego requestu do p99 latency
Jeden incydent od początku do końca: request 500m, brak limitu, brak throttlingu, a p99 rośnie z 35 do 180 ms. Cała ścieżka mechanizmu.
Reliability / SRE / Capacity & Performance

p99

wpisy (1)

Anatomia problemu CPU: od zaniżonego requestu do p99 latency