Konrad Kowalski (rootsher)Principal Platform & Reliability Architect011110100100110111110110110101101100001111110111

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

Hardening

wpisy (1)

2025-03-25
Polityki na klastrze: po co Kyverno i CEL
Polityki na klastrze powstały dlatego, że RBAC mówi, kto może utworzyć zasób, ale nie odpowiada dobrze na pytanie, czy ten konkretny YAML jest bezpieczny.
Security / Infrastructure & Cloud Security

Hardening

wpisy (1)

Polityki na klastrze: po co Kyverno i CEL