Konrad Kowalski (rootsher)Principal Platform & Reliability Architect100101010010100110110101000011001101110011110001

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%).

Keep-alive

wpisy (1)

2026-03-10Warstwy HTTP w przeglądarce: od fetch() do QUIC5/9
Connections: dlaczego jeden fetch() nie oznacza jednego połączenia
Request i połączenie mają różny lifecycle. Pulą połączeń zarządza przeglądarka, a frontend wpływa na nią tylko przez architekturę zasobów i originów.
Software Development / Frontend

Keep-alive

wpisy (1)

Connections: dlaczego jeden fetch() nie oznacza jednego połączenia