Baza pytań rekrutacyjnych i wiedzy. Filtruj, szukaj i sprawdzaj swoją wiedzę.
DevOps to kultura i praktyki łączące development i operacje wokół szybkiego, niezawodnego dostarczania oraz współodpowiedzialności. Sukces mierzy się m.in. częstotliwością wdrożeń, lead time dla zmian, odsetkiem awarii po wdrożeniu i MTTR, oraz metrykami wpływu na użytkownika.
Pipeline CI zwykle: checkout kodu, build, testy jednostkowe/integracyjne, analiza statyczna, paczkowanie i publikacja artefaktów. Awarie wynikają często z flaky testów, brakujących zależności, driftu środowisk, problemów z secretami/config oraz niedeterministycznych buildów.
Continuous delivery utrzymuje kod zawsze gotowy do wdrożenia i zwykle wymaga ręcznej akceptacji przed produkcją. Continuous deployment automatycznie wdraża na produkcję po przejściu pipeline’u.
Rolling stopniowo zastępuje instancje przy minimalnym dodatkowym koszcie, ale ryzykuje częściowe problemy. Blue/green utrzymuje dwa środowiska i przełącza ruch naraz; rollback jest łatwy, lecz koszt wyższy. Canary wdraża najpierw na mały % ruchu, zmniejsza ryzyko, ale wymaga dobrego monitoringu.
GitOps traktuje Git jako źródło prawdy dla stanu docelowego. Zmiany przechodzą przez pull requesty i są automatycznie uzgadniane z docelowym środowiskiem, co daje spójność i audytowalność.
Idempotencja oznacza, że wielokrotne zastosowanie tej samej konfiguracji daje ten sam stan, co umożliwia bezpieczne, powtarzalne wdrożenia. Zmiany waliduj przez linting, plan/diff, policy checks oraz środowisko staging przed produkcją.
Konfiguracja jest niesensytywna i może być wersjonowana. Sekrety powinny trafić do secret managera/KMS, być wstrzykiwane w runtime, rotowane i dostępne zgodnie z zasadą least privilege.
Używaj minimalnych baz, multi-stage buildów, pinuj wersje, usuwaj zależności buildowe, stosuj .dockerignore, uruchamiaj jako non‑root i skanuj podatności.
Deployment jest dla usług stateless, StatefulSet dla aplikacji stateful ze stałą tożsamością i storage, a DaemonSet uruchamia po jednym podzie na węzeł (np. agenty logów).
Readiness kontroluje ruch, liveness restartuje niezdrowe kontenery, a startup pozwala na dłuższą inicjalizację. Zła konfiguracja może powodować pętle restartów lub kierowanie ruchu zanim aplikacja jest gotowa.
Metryki pokazują trendy i zdrowie, logi dają szczegóły zdarzeń, a trace śledzą pojedyncze żądanie przez serwisy. Razem pomagają wykrywać, diagnozować i wyjaśniać incydenty.
Alertuj na symptomy powiązane z SLO, używaj burn‑rate/multi-window, deduplikuj, kieruj do właścicieli i upewnij się, że każdy alert jest akcjonowalny z jasnym runbookiem.
Runbook zawiera kroki wykrycia, triage, mitigacji/rollbacku, role, eskalacje i komunikację. Postmortem dokumentuje przyczynę i tworzy zadania z właścicielami, by zapobiec powtórkom.
SLI to mierzona metryka, SLO to cel, SLA to obietnica kontraktowa. Error budget to dopuszczalna awaryjność (1 - SLO); gdy budżet się wyczerpie, spowalniasz releasy i skupiasz się na niezawodności.
Dopasuj rozmiar instancji na podstawie metryk, używaj autoskalowania przy zmiennym obciążeniu i kupuj reserved/committed capacity dla stabilnych workloadów. Dodaj polityki lifecycle dla storage i caching tam, gdzie ma sens.