DevOps i infrastruktura

Projektujemy i utrzymujemy infrastrukturę, na której działają sklepy e-commerce, bez klastra Kubernetes, którego utrzymanie wymagałoby zatrudnienia doświadczonego inżyniera SRE.

Kiedy to pasuje

• Sklep na jednym VPS, który ulega awarii przy każdej promocji albo starcie kampanii
• Wdrożenia, które trwają 40 minut, zawodzą bez komunikatu o błędzie albo wymagają osoby, „która zna ten skrypt”
• Nikt nie wie, dlaczego w zeszły czwartek checkout działał wolno, bo nie ma ani logów, ani metryk
• Pytania o compliance (PCI, ślad audytowy pod RODO), które nagle wymagają konkretnych odpowiedzi
• Founder albo CTO, który faktycznie pełni rolę inżyniera on-call i każdy Black Friday spędza przy monitoringu

Co robimy

• Infrastruktura w chmurze i na edge’u. Cloudflare, AWS, GCP, Hetzner albo bare metal; wybieramy stack, który pasuje do workloadu.
• Pipeline’y CI/CD na GitHub Actions albo GitLab CI, z powtarzalnymi buildami, odwracalnymi wdrożeniami i sekretami, których nie ma w repo.
• Observability: logi, metryki i trace’y przez Grafanę, OpenTelemetry, Sentry albo Cloudflare Logpush. Na pytanie „co się stało we wtorek o 14:32” powinieneś umieć odpowiedzieć w niecałą minutę.
• Wydajność i koszty. Edge caching, image CDN, autoscaling dostrojony pod kampanijne skoki ruchu i przegląd kosztów, po którym rachunek za infrastrukturę zwykle spada.
• Incident response: runbooki, alerting, który nie podnosi fałszywych alarmów, i post-mortemy, po których ta sama awaria nie zdarza się drugi raz.
• Podstawy bezpieczeństwa. Zarządzanie sekretami, skanowanie zależności, podpisywanie obrazów, polityki sieciowe i regularne łatki, które chronią sklep przed znanymi exploitami.

Domyślnie sięgamy po najprostszą infrastrukturę, która spełnia wymagania.

Incydenty, które mamy za sobą

Próbka z systemów produkcyjnych, które prowadziliśmy przez lata:

• Dashboardy pamięci pokazywały płaską linię, podczas gdy aplikacja miała wyciek pamięci, bo agent metryk monitorował menedżera procesów zamiast aplikacji, którą ten uruchamiał. Diagnoza wynikła z analizy drzewa procesów i kodu źródłowego agenta; rozwiązaniem był niewielki init wrapper, który dodatkowo uporządkował zamykanie procesu.
• Powracające awarie z „trybem konserwacji”, których przyczyną była warstwa cache bez pamięci transient, pogłębiane przez samoaktualizujący się tag obrazu „stable”, który bez kontroli wersji podmieniał oprogramowanie na wszystkich środowiskach. Przypięliśmy wersje, przepisaliśmy VCL i hit rate wzrósł z 4% do prawidłowego poziomu.
• Agenty CI przerywane przez OOM w trakcie joba blokowały maszynę stanów indeksera bez zgłoszenia błędu i zatrzymywały aktualizacje stanów magazynowych. Awarię celowo odtworzyliśmy na stagingu, a następnie przebudowaliśmy warstwę zadań cyklicznych z izolacją per grupa i automatycznymi resetami.
• Cache frontendu całego kraju nie dawał się unieważnić z powodu literówki w jednym słowie przestrzeni nazw na liście hostów do purge’a. Doraźnie pomogły ręczne bany w cache’u, docelowo poprawka w konfiguracji.
• Środowisko klienta zostało omyłkowo usunięte, bez backupów logicznych. Odzyskaliśmy je ze snapshotów hypervisora, przez wymuszone odzyskiwanie InnoDB i skok o dużą wersję MySQL.

Wspólna praktyka za tymi przypadkami: alerty na niezmienniki biznesowe, na przykład „każde zamówienie dociera do ERP w 15 minut”, a nie tylko na wskaźniki błędów. Kilka z powyższych incydentów wykryła dokładnie taka sonda, zanim zauważył je jakikolwiek klient.

Jak zwykle zaczyna się współpraca

Znaczna część tej pracy pojawia się w trakcie innego zlecenia: audytu, który wskazuje hosting jako wąskie gardło, albo budowy, która wymaga pipeline’u deployów, zanim cokolwiek trafi na produkcję. Przy samodzielnym zleceniu infrastrukturalnym zaczynamy od krótkiego przeglądu tego, co gdzie działa, ile kosztuje i co pierwsze ulega awarii pod obciążeniem, a rekomendowane zmiany otrzymujesz na piśmie ze stałą ceną. Stała opieka działa jako miesięczny retainer z nazwanymi godzinami, na warunkach opisanych na Jak pracujemy.