Usługi

DevOps i utrzymanie serwerów

Serwery i wdrożenia pod kontrolą: Docker, CI/CD w GitHub Actions, Nginx i Cloudflare, monitoring, kopie zapasowe, VPN i SSO. Publikacja nowej wersji sprowadza się do jednego polecenia.

Aplikacja jest tak dobra, jak serwer, na którym działa. Ręczne wdrożenia przez FTP, brak kopii zapasowych i serwer, do którego hasło zna jedna osoba, to ryzyko, które wychodzi zwykle w najgorszym momencie. Porządkujemy infrastrukturę tak, żeby wdrożenie nowej wersji było rutyną, a awaria — czymś, o czym dowiadujemy się z alertu, a nie od klientów.

Zakres usług DevOps

  • Konteneryzacja w Dockerze — aplikacja, kolejki, cache i usługi pomocnicze w kontenerach, z identycznym środowiskiem na komputerze programisty, na testach i na produkcji.
  • CI/CD w GitHub Actions — testy przy każdym pull requeście i automatyczne wdrożenia. Publikacja nowej wersji sprowadza się do jednego polecenia.
  • Serwery dedykowane i chmura — konfiguracja, zabezpieczenie i aktualizacje serwerów, Nginx jako serwer WWW i reverse proxy, Cloudflare przed aplikacją.
  • Monitoring i alerty — Grafana, logi i śledzenie błędów, a po stronie użytkownika nagrania sesji w OpenReplay, które pokazują, co faktycznie zobaczył klient.
  • Kopie zapasowe i przechowywanie plików — automatyczne kopie baz danych i plików, przechowywanie w MinIO albo S3.
  • Bezpieczny dostęp — firmowy VPN na Tailscale z własnym serwerem Headscale i jednolite logowanie (SSO) przez Authentik. Więcej narzędzi na własnych serwerach opisujemy na stronie infrastruktury self-hosted.

Jak zaczynamy

Pierwszy krok to przegląd tego, co jest: serwery, sposób wdrażania, kopie zapasowe, dostępy, monitoring. Na tej podstawie dostajesz listę ryzyk i plan zmian w kolejności ważności — najpierw kopie zapasowe i dostępy, potem automatyzacja wdrożeń i monitoring. Zmiany wprowadzamy stopniowo, bez przestoju aplikacji.

DevOps jako część projektu albo osobna usługa

W projektach, które budujemy, DevOps jest w standardzie: od pierwszego dnia aplikacja ma środowiska, automatyczne wdrożenia i monitoring. Możemy też zająć się samą infrastrukturą aplikacji, którą rozwija Twój zespół — przygotować konteneryzację, pipeline CI/CD i monitoring, a potem przekazać je zespołowi albo dalej utrzymywać w ramach utrzymania aplikacji.

Jeśli potrzebujesz przede wszystkim bezpiecznego dostępu zespołu do zasobów firmy, zobacz wdrożenie firmowego VPN.

Kod i dostępy zostają u Ciebie

Konfiguracja infrastruktury trafia do repozytorium, a dostępy administracyjne są Twoje. Nie ma serwera, do którego klucze ma tylko jedna osoba — w razie zmiany wykonawcy całą infrastrukturę można przekazać dalej.

Najczęściej zadawane pytania

Czy przeniesiecie aplikację na nowy serwer bez przestoju?

Zwykle tak. Uruchamiamy aplikację równolegle na nowej infrastrukturze, synchronizujemy dane i przełączamy ruch, gdy wszystko działa. Jeśli krótkie okno serwisowe jest nieuniknione, planujemy je na porę najmniejszego ruchu.

Chmura czy serwer dedykowany?

Zależy od aplikacji. Przy stałym, przewidywalnym ruchu serwer dedykowany bywa wyraźnie tańszy. Chmura ma sens przy dużych wahaniach ruchu albo gdy potrzebne są jej usługi zarządzane. Doradzamy na podstawie realnego obciążenia.

Czy możecie zająć się tylko infrastrukturą, a kod zostanie u naszego zespołu?

Tak. Przygotujemy konteneryzację, CI/CD i monitoring, a potem przekażemy je Twojemu zespołowi albo zostaniemy przy utrzymaniu infrastruktury.

Jak chronicie serwery przed atakami?

Aktualizacje bezpieczeństwa, dostęp administracyjny tylko przez VPN i klucze, sekrety poza repozytorium, Cloudflare przed aplikacją oraz monitoring nietypowego ruchu.

Co jeśli serwer padnie w nocy albo w weekend?

Monitoring działa 24/7 i wysyła alerty. Czas reakcji na awarie poza godzinami pracy zapisujemy w umowie SLA. Kopie zapasowe i opisana procedura odtworzenia pozwalają postawić aplikację na nowym serwerze, jeśli stary nie wróci.

Czy musimy przechodzić na Dockera?

Nie jest to warunek, ale zwykle to rekomendujemy. Docker daje identyczne środowisko u programisty, na testach i na produkcji, więc znika klasa błędów typu „u mnie działa”, a przeniesienie aplikacji na inny serwer staje się proste.