Klient to usługa logistyczna obsługująca dziesiątki tysięcy zamówień dziennie, z wieczornymi szczytami i pikami podczas wyprzedaży oraz rygorystycznymi umowami SLA wobec partnerów handlowych. Infrastruktura rozwijała się spontanicznie: rozproszone VPS-y, konfiguracje „na serwerach” i ręczne wdrożenia według instrukcji w wiki. Każde wydanie oznaczało nocne wdrożenie z przestojem, a każdy szczyt groził utratą zamówień. Impulsem do kontaktu był incydent podczas przedświątecznej wyprzedaży: platforma nie działała przez cztery godziny, a usługa wypłaciła partnerom rekompensaty.
Przenieść platformę do zarządzanej infrastruktury bez zatrzymywania biznesu:
infrastruktura jako kod, automatyczne dostarczanie, konteneryzacja i orkiestracja, obserwowalność oraz przewidywalne odzyskiwanie po awariach. Założyciel określił kryterium sukcesu: „wdrożenie w godzinach pracy, bez przestoju i bez osoby z dostępem SSH”.
Działaliśmy według sprawdzonej kolejności: najpierw kontenery i odtwarzalne środowiska, potem automatyzacja dostarczania, a dopiero na końcu orkiestracja z autoskalowaniem.
- Przeprowadziliśmy audyt infrastruktury: zmapowaliśmy usługi i zależności, zmierzyliśmy profil szczytowego obciążenia i sporządziliśmy rejestr ręcznych działań najczęściej prowadzących do awarii.
- Skonteneryzowaliśmy usługi: ujednoliciliśmy budowanie, przenieśliśmy konfigurację z kodu do zmiennych środowiskowych i przygotowaliśmy identyczne środowiska dev/stage/prod.
- Opisaliśmy infrastrukturę kodem w Terraformie: środowiska są wdrażane z repozytorium, a ręczne zmiany w konsoli dostawcy chmury są zabronione.
- Zbudowaliśmy potok GitLab CI: testy i obrazy budują się automatycznie, wdrożenie na stage następuje od razu, produkcyjne — przyciskiem po przeglądzie, a wycofanie zmian wymaga jednej czynności.
- Przenieśliśmy platformę do Kubernetesa z autoskalowaniem: wieczorne szczyty i wyprzedaże obsługiwane są przez dodatkowe instancje zamiast awaryjnej ręcznej pracy.
- Uruchomiliśmy monitoring i alerty dla kluczowych sygnałów — opóźnień, błędów, ruchu i wysycenia — wraz z dyżurami i eskalacją według harmonogramu.
- Skonfigurowaliśmy kopie zapasowe i odzyskiwanie po awarii: procedurę odtworzenia oraz próbę awarii na stage z pomiarem rzeczywistego MTTR.
Najcenniejszy rezultat projektu to nie technologia, lecz zmiana odpowiedzialności: infrastruktura przestała zależeć od „osoby z dostępem SSH”. Każde wdrożenie można odtworzyć, każde środowisko przywrócić z kodu, a pulpity nawigacyjne pokazują awarię, zanim napisze pierwszy klient. Dzięki temu przestój przestaje być katastrofą, a staje się rutynowym incydentem z jasnym planem działania i mierzalnym czasem przywrócenia.
Ekonomia projektu składała się z trzech elementów: bezpośrednie oszczędności na infrastrukturze — 32% dzięki autoskalowaniu i rezygnacji ze stale „rozgrzanej” mocy na szczyty; oszczędność godzin zespołu, które wcześniej pochłaniały nocne wdrożenia; oraz, co najważniejsze, zachowanie przychodów podczas szczytów, które teraz przebiegają bez incydentów. Duży klient będący siecią sklepów przedłużył umowę właśnie po pierwszej wyprzedaży na nowej infrastrukturze.
| Wskaźnik | Wynik |
|---|---|
| Wdrożenie wydania | 3–4 godziny ręcznie → 15 minut automatycznie |
| Częstotliwość wydań | 2–3 miesięcznie → Prawie codziennie |
| Dostępność platformy | 97,8% → 99,95% |
| Szczytowe obciążenia | Ryzyko przestoju → Autoskalowanie bez udziału człowieka |
Wskaźniki przeniesiono z oryginalnych materiałów przypadku. Okres podano tam, gdzie został określony w źródle.
- wdrożenie wydania (wcześniej 3–4 godziny ręcznie)
- 15 min
- dostępność platformy (wcześniej 97,8%)
- 99,95%
- przywrócenie po awarii (wcześniej 2–4 godziny)
- 20–30 min
- koszt infrastruktury
- −32%
Pokazano górne granice przedziałów (4 godziny, 30 minut). Przestój = 100% − dostępność.
- 01Commit
- 02Testy
- 03Budowanie obrazu
- 04Stageod razu
- 05Prodprzyciskiem po przeglądzie
Kierunki rozwoju infrastruktury na kolejny cykl:
- Praktyki FinOps — alerty o anomaliach kosztów i przejrzystość wydatków według zespołów.
- Podejście GitOps — stan produkcji opisany w repozytorium, zmiany wyłącznie przez pull requesty.
- Wieloregionowość — repliki krytycznych usług zwiększające odporność na awarię dostawcy.
Kiedyś wydanie oznaczało noc, kawę i modlitwę. Teraz to przycisk i piętnaście minut. Pierwszą wyprzedaż bez incydentów świętowaliśmy całą firmą.
— Dyrektor techniczny usługi logistycznej