Baza pytań rekrutacyjnych i wiedzy. Filtruj, szukaj i sprawdzaj swoją wiedzę.
Mikroserwis to mała usługa, która robi jedną rzecz biznesową i może być wdrażana niezależnie. Zwykle ma własne dane i komunikuje się z innymi usługami przez API/zdarzenia, więc da się ją skalować i wydawać osobno.
IaaS dostarcza infrastrukturę (VM‑ki, sieć, storage) — Ty zarządzasz systemem, runtime i aplikacją. PaaS daje zarządzaną platformę/runtime, gdzie wdrażasz kod, a dostawca dba o OS i skalowanie. SaaS to gotowa aplikacja dostarczona użytkownikowi końcowemu.
Kontenery (Docker) wirtualizują na poziomie systemu operacyjnego: współdzielą kernel hosta, startują szybko i są lekkie. Maszyny wirtualne wirtualizują sprzęt: każda VM ma własny system i kernel, jest cięższa i startuje wolniej, ale zapewnia mocniejszą izolację.
Kubernetes to system orkiestracji kontenerów. Podstawowe pojęcia to klaster (control plane + nody), pody jako najmniejsza jednostka uruchamiająca kontenery, deploymenty/statefulsety utrzymujące żądaną liczbę replik, serwisy/ingress do sieciowania oraz ConfigMapy/Secrety i Namespaces do konfiguracji i izolacji.
Serverless pozwala uruchamiać kod bez zarządzania serwerami: dostawca zajmuje się provisioningiem, skalowaniem i patchowaniem. Płacisz za wykonanie, możesz skalować do zera i szybko wdrażać. Minusy to m.in. cold starty, limity wykonania i vendor lock‑in.
IaaS daje infrastrukturę (VM, sieć), PaaS daje zarządzaną platformę/runtime (wdrażasz kod, a dostawca uruchamia), a SaaS to gotowa aplikacja (po prostu używasz).
Region to obszar geograficzny (np. `eu-central-1`) zawierający wiele Availability Zones. AZ to fizycznie odseparowane centrum danych (lub ich grupa) w obrębie regionu. Rozłożenie na AZ poprawia dostępność, a na regiony — odporność geograficzną.
Skalowanie poziome dodaje więcej instancji (scale out), zwiększając pojemność i odporność. Skalowanie pionowe powiększa jedną instancję (scale up). Poziome jest zwykle bardziej odporne, pionowe bywa prostsze, ale ma ograniczenia.
Blue/green przełącza cały ruch z wersji starej na nową naraz (z szybkim rollbackiem). Canary wdraża najpierw na mały % ruchu i stopniowo zwiększa, zmniejszając ryzyko dzięki obserwacji metryk.
L4 działa na warstwie transportowej (TCP/UDP) i routuje połączenia bez rozumienia HTTP. L7 rozumie protokoły aplikacyjne (HTTP), więc potrafi routować po ścieżce/headerach, robić TLS termination i stosować bardziej zaawansowane reguły.
Metryki to liczby w czasie (CPU, latency), logi to pojedyncze zdarzenia/wiadomości, a trace śledzi jedno żądanie przez serwisy (span). Razem pomagają wykrywać i diagnozować incydenty.
Multi-AZ chroni przed awarią data center w regionie — mniejsze opóźnienia i prostsze operacje. Multi-region potrafi przetrwać awarię całego regionu, ale dokłada latency, złożoność replikacji danych i koszty.
Przy at-least-once wiadomość może zostać dostarczona więcej niż raz (retry), więc konsument powinien być idempotentny (bezpiecznie obsługiwać duplikaty). Exactly-once jest trudne i kosztowne, więc idempotencja to typowe rozwiązanie.
Sekrety trzymaj w secret managerze (lub zaszyfrowanym storage KMS) i wstrzykuj w runtime (env/volume), a nie w gicie czy jawnych plikach. Rotuj sekrety i stosuj least privilege.
Dopasuj rozmiar instancji na podstawie metryk i użyj autoskalowania zamiast overprovisioningu. Dodaj caching (CDN/cache aplikacyjny) i rozważ reserved/committed capacity dla przewidywalnych obciążeń.
CDN cache’uje statyczne treści (obrazy, JS, CSS) blisko użytkownika. Zmniejsza opóźnienia i odciąża serwery origin, poprawiając szybkość i odporność.
Autoscaling dopasowuje liczbę instancji do obciążenia (metryki typu CPU, latency, kolejka). Typowa pułapka to thrashing: zbyt agresywne skalowanie góra/dół przez szum w metrykach — pomagają cooldowny i dobre progi.
IaC opisuje infrastrukturę w kodzie (Terraform/CloudFormation), więc masz wersjonowanie, review i powtarzalność. Zmniejsza configuration drift i ułatwia automatyzację oraz spójne środowiska.
Least privilege oznacza nadanie minimalnych uprawnień potrzebnych do działania (i nic więcej). Ogranicza blast radius: gdy klucz lub serwis zostanie przejęty, atakujący zrobi mniej szkód.
Service mesh dodaje warstwę do ruchu między serwisami (często sidecar proxy): mTLS, retry, timeouty i observability. Ma sens przy wielu serwisach i potrzebie spójnych kontroli sieci/bezpieczeństwa, ale dokłada złożoność operacyjną.
Object storage przechowuje pliki jako obiekty (klucz + dane + metadane) i jest świetny na bloby (obrazy, backupy). Block storage daje surowy wolumen dyskowy dla VM; jest dobry dla baz danych i filesystemów, gdzie liczy się niska latencja i losowy dostęp.
Health check sprawdza, czy instancja jest gotowa obsługiwać ruch. Load balancer używa go, żeby wyłączyć chore instancje z rotacji, zwiększając dostępność i zmniejszając błędy dla użytkowników.
RPO (Recovery Point Objective) mówi ile danych możesz stracić (w czasie). RTO (Recovery Time Objective) mówi ile może trwać przywrócenie działania. Te wartości determinują backupy, replikację i projekt DR.
Backup/restore jest najtańsze, ale ma większe RTO/RPO. Warm standby trzyma mniejsze żywe środowisko gotowe do skalowania przy failover (lepsze RTO). Active-active działa w wielu regionach jednocześnie (najlepsze RTO i często dostępność), ale jest najbardziej złożone i drogie.
Rozdzielenie zmniejsza blast radius i zapobiega wpadkom (np. przypadkowe usunięcie zasobów prod). Poprawia bezpieczeństwo i zgodność, ułatwia kontrolę kosztów i pozwala stosować ostrzejsze polityki/akceptacje na produkcji.
VPC to prywatna, odizolowana sieć w chmurze, gdzie definiujesz zakresy IP, subnety, routing i reguły zapory. Używasz go, żeby kontrolować kto z kim może rozmawiać (np. trzymać bazę w prywatnej sieci) i bezpiecznie łączyć się z innymi sieciami (VPN/peering).
Subnet publiczny ma trasę do Internet Gateway, więc zasoby mogą być osiągalne z internetu (przy odpowiednich regułach zapory). Subnet prywatny nie ma bezpośredniej trasy inbound z internetu; zwykle trzyma się tam serwery aplikacji i bazy. Często load balancer jest publiczny, a app/DB są prywatne.
NAT gateway pozwala instancjom w prywatnym subnecie robić połączenia wychodzące do internetu (aktualizacje, zewnętrzne API), pozostając nieosiągalnymi dla ruchu przychodzącego z internetu. To typowy wzorzec: prywatne serwery aplikacji + NAT na outbound, publiczny load balancer na inbound.
Multi-tenant współdzieli infrastrukturę między klientami (taniej i łatwiej skalować), ale trudniej o izolację i pojawia się ryzyko “noisy neighbor”. Single-tenant daje mocniejszą izolację i prostsze limity “na klienta”, ale jest droższy i cięższy operacyjnie. Wiele systemów robi podejście hybrydowe.
Rate limiting chroni system przed nadużyciami i skokami ruchu (zwykle zwracając HTTP 429). Możesz go egzekwować na edge (CDN/WAF), w API gateway/load balancerze i w samej aplikacji. Im wcześniej, tym oszczędniej, ale aplikacja i tak powinna mieć zabezpieczenia, bo nie każdy ruch przechodzi przez jeden punkt wejścia.
Container registry przechowuje i udostępnia obrazy kontenerów (jak “repo Git dla obrazów”). Zespoły używają go do wersjonowania obrazów, skanowania pod kątem podatności, kontroli dostępu i wdrażania tego samego przetestowanego obrazu na różne środowiska.
Service daje stabilną sieć do podów (stała nazwa/IP) i load-balansuje w klastrze. Service typu LoadBalancer zwykle tworzy chmurowy load balancer L4, żeby wystawić Service na zewnątrz. Ingress to zwykle routing HTTP L7 (reguły host/path, TLS) przed Service’ami, obsługiwany przez Ingress Controller.
Stosuj nakładającą się ważność: tworzysz nową wersję sekretu, wdrażasz aplikacje, które potrafią użyć nowego sekretu, a dopiero potem unieważniasz stary. Jeśli się da, używaj krótkotrwałych poświadczeń. Dopilnuj bezpiecznego przeładowania sekretów (restart/sidecar/hook) i monitoruj błędy w trakcie rollout.
Zależnie od dostawcy i operacji (szczególnie nadpisania i listowanie) object storage może zachowywać się jak system eventual consistency, więc nie zawsze zobaczysz najnowszy stan od razu. Projektuj to tak: unikaj nadpisań (unikalne klucze/versioning), stosuj retry z backoff i nie zakładaj, że “lista pokaże wszystko natychmiast”.
HPA (Horizontal Pod Autoscaler) skaluje liczbę podów na podstawie metryk (CPU, memory, custom). Cluster Autoscaler skaluje liczbę nodów w klastrze, gdy nie da się schedulować podów z powodu braku zasobów. Często działają razem: HPA dodaje pody, a Cluster Autoscaler dodaje nody, jeśli trzeba.
Publiczne subnety mają trasę do internetu (przez Internet Gateway). Prywatne subnety nie mają bezpośredniego wejścia z internetu. NAT gateway pozwala instancjom w prywatnych subnetach inicjować ruch wychodzący (np. pobierać aktualizacje) bez wystawiania ich na świat.
Users to tożsamości dla ludzi lub długotrwałych poświadczeń. Roles są zakładane przez usługi lub użytkowników dla tymczasowego dostępu. Least privilege oznacza nadanie tylko minimalnych uprawnień potrzebnych do zadania, najlepiej przez role i dostęp czasowy.
CDN cache’uje treści w lokalizacjach brzegowych blisko użytkowników, zmniejszając opóźnienia i odciążając origin. Używaj go dla statycznych assetów, dużych plików i globalnej publiczności, by poprawić wydajność i odporność.
Blue/green utrzymuje dwa pełne środowiska i przełącza ruch z „starego” na „nowe” jednym krokiem (szybki rollback). Canary wypuszcza zmianę na mały procent ruchu i stopniowo zwiększa, zmniejszając ryzyko kosztem monitoringu i etapowego rollout’u.
Serwisy stateless nie trzymają stanu użytkownika w pamięci, więc łatwo je skalować i zastępować. Stateful trzymają lokalny stan, więc skalowanie wymaga sticky sessions, współdzielonego storage lub replikacji. Stateless jest zwykle bardziej „cloud‑friendly”.
RTO (Recovery Time Objective) określa, jak szybko musisz przywrócić usługę po awarii. RPO (Recovery Point Objective) określa, ile utraty danych jest akceptowalne (czas między ostatnim poprawnym backupem a awarią).
Metryki to numeryczne szeregi czasowe (np. latency, error rate). Logi to szczegółowe zdarzenia z kontekstem. Traces łączą zdarzenia między usługami, pokazując end‑to‑end przepływ requestu. Razem pomagają wykrywać i diagnozować problemy.
On‑demand jest elastyczne, ale najdroższe. Reserved (lub savings plans) są tańsze przy stałych workloadach, ale wymagają zobowiązania. Spot jest najtańszy, lecz może zostać przerwany, więc nadaje się do zadań tolerujących przerwy lub batch.