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 są powolne, 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
• Wymagania dotyczące compliance (PCI, ślad audytowy pod RODO), które nagle wymagają udokumentowanych odpowiedzi
• Founder albo CTO, który faktycznie pełni rolę inżyniera on-call, łącznie z nocami w Black Friday

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: za co faktycznie płacisz.
• Incident response: runbooki, alerting, który nie podnosi fałszywych alarmów, i post-mortemy, które są spisywane i zamieniane na poprawki.
• 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.

Przykładowe incydenty

Próbka z dziesięciu lat pracy inżynierskiej w e-commerce, na których opiera się ta praktyka, zanonimizowana:

• 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 z wyczerpaną pamięcią transient, pogłębiane przez samoaktualizujący się tag obrazu „stable”, który bez ostrzeżenia podmieniał wdrożone oprogramowanie. Przypięliśmy wersje, przepisaliśmy VCL i hit rate wzrósł z 4% do prawidłowego poziomu.
• Agenty CI przerywane przez OOM killer 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ą na grupę 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 blokady 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 stojąca 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. Sonda na niezmienniku wykrywa tę klasę awarii wtedy, gdy wskaźnik błędów wciąż wygląda normalnie.

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 określoną liczbą godzin, na warunkach opisanych na Jak pracujemy.