Inżynier DevOps: najczęstsze pytania i odpowiedzi

Wzorcowa odpowiedź

Zaczynam od szybkiego feedbacku: lint, testy jednostkowe i skanowanie podstawowych błędów przy każdym pushu. Potem buduję jeden niezmienny artefakt i promuję go przez kolejne środowiska, zamiast za każdym razem budować coś nowego. Do wdrożenia wybieram bezpieczną strategię, np. rolling albo canary, z automatycznym rollbackiem po błędzie health check. Dzięki temu merge do main może trafić na produkcję bez ręcznego przepisywania kroków.

Wzorcowa odpowiedź

Mieliśmy powtarzające się awarie spowodowane przeciążeniem jednej bazy danych. Wprowadziłem read replicas, connection pooling i alerty na saturation, zanim problem zaczął blokować ruch. Ustaliłem też ze zespołem SLO, żebyśmy mieli wspólny, mierzalny cel niezawodności. W efekcie awarie tego typu zniknęły, a zespół zaczął podejmować decyzje w oparciu o konkretne wskaźniki.

Wzorcowa odpowiedź

Traktuję infrastrukturę jak kod aplikacyjny: wersjonuję ją, robię code review i wdrażam przez pipeline, a nie ręcznie przez panel w chmurze. Preferuję deklaratywne narzędzia, bo opisuję stan docelowy, a system sam doprowadza środowisko do zgodności. Dbam o moduły wielokrotnego użytku i bezpieczne zarządzanie stanem, żeby ograniczyć drift i ułatwić odtwarzanie środowisk. Dzięki temu disaster recovery jest prostsze, bo wystarczy ponownie uruchomić kod.

Wzorcowa odpowiedź

Nigdy nie commituję secrets do repozytorium. Używam dedykowanego secrets managera, a dostęp ograniczam do zasady least privilege. Sekrety wstrzykuję w runtime, np. przez zmienne środowiskowe lub sidecar, zamiast bake'ować je do obrazu. Regularnie rotuję dane dostępowe i rozdzielam konfigurację od kodu, żeby ten sam artefakt działał w różnych środowiskach po podaniu właściwych parametrów.

Wzorcowa odpowiedź

Najpierw przywracam usługę, więc zaczynam od mitigacji, np. rollbacku lub failoveru, zanim wrócę do root cause. Komunikuję się jasno na kanale incidentowym i pilnuję aktualizacji dla interesariuszy. Gdy system jest stabilny, robię blameless postmortem i zamieniam wnioski w konkretne działania zapobiegawcze. Najważniejsze jest dla mnie usunięcie całej klasy problemu, a nie tylko pojedynczego objawu.

Virtual machine wirtualizuje sprzęt i uruchamia pełny guest OS, więc jest cięższa i startuje wolniej. Container wirtualizuje warstwę OS, współdzieli kernel hosta i pakuje głównie aplikację oraz jej zależności, przez co jest lżejszy i startuje w sekundy. Containery dają lepszą gęstość i portability, a VM zwykle mocniejsze isolation.

Kubernetes to orchestrator kontenerów, który planuje uruchamianie na klastrze, obsługuje service discovery, scaling i self-healing przez restartowanie uszkodzonych podów. Pozwala deklarować desired state i stale doprowadzać rzeczywistość do zgodności z nim. Używasz go, gdy chcesz uruchamiać wiele kontenerów niezawodnie, z automatycznymi rolloutami i skalowaniem, zamiast zarządzać nimi ręcznie.

Blue-green utrzymuje dwa pełne środowiska i przełącza cały ruch z jednego na drugie naraz, co daje szybki rollback przez powrót na poprzednie środowisko. Canary wystawia nową wersję najpierw na mały procent ruchu, obserwuje ją i stopniowo zwiększa udział. Canary ogranicza blast radius i pozwala złapać problem na realnym ruchu, a blue-green jest prostszy, ale przełącza wszystkich jednocześnie.

Load balancer rozdziela ruch na wiele backendów, żeby jeden serwer nie był przeciążony. Wykonuje health checks i przestaje kierować ruch do unhealthy instance, więc awaria pojedynczego węzła nie kładzie usługi. Umożliwia to horizontal scaling i bezpieczne zero-downtime deploye przez graceful draining.

Monitoring śledzi znane metryki i alarmuje, gdy przekroczą progi, odpowiadając na pytanie, czy system działa zgodnie z oczekiwaniami. Observability to szersza zdolność zadawania nowych pytań o stan systemu na podstawie logów, metryk i trace'ów. Dobra observability pozwala diagnozować nowe, nieprzewidziane problemy, a nie tylko te, do których wcześniej ustawiłeś alerty.

Błędna zmiana konfiguracji wyłączyła nasz główny API w godzinach szczytu. Ogłosiłem incident, zrobiłem rollback w kilka minut i na bieżąco informowałem interesariuszy. Postmortem pokazał brak walidacji konfiguracji w pipeline, więc dodałem automatyczne testy i staged rollout dla configu. Tego typu awaria już się nie powtórzyła.

Deploye wymagały ręcznej checklisty, która trwała około godziny i łatwo prowadziła do pomyłek. Zautomatyzowałem cały flow w jednym pipeline z testami, approvalami i rollbackiem. Dodałem też czytelny status, żeby developerzy mogli sami bezpiecznie wdrażać zmiany. Częstotliwość deploymentów wzrosła, a liczba incydentów związanych z wdrożeniem spadła.

Produkt chciał codziennych release'ów, ale wskaźnik change failure rate był zbyt wysoki. Wprowadziłem progressive delivery z canary i automatycznym rollbackiem, żeby iść szybko, ale bezpiecznie. Powiązałem to ze SLO, więc zwalnialiśmy tylko wtedy, gdy burn rate był zbyt duży. Udało się przyspieszyć releases bez utraty stabilności, a decyzje były oparte na danych.

Koszt chmury rósł szybciej niż uzasadniał to ruch. Przeanalizowałem wykorzystanie zasobów, right-sized nadmiernie duże instancje, wdrożyłem autoscaling i dla części workloadów przeniosłem je na spot instances. Ustawiłem dashboardy kosztowe i alerty budżetowe, żeby utrzymać widoczność. Obniżyliśmy miesięczny rachunek o około jedną trzecią bez mierzalnego wpływu na performance.