Dla studia internetowego lub agencji marketingowej serwer VDS umożliwia zbieranie stron klientów w jednym zarządzanym środowisku. Można tu umieścić projekty robocze, kopie testowe, bazy danych oraz wewnętrzne narzędzia zespołu, nie tworząc osobnej infrastruktury dla każdego małego zlecenia. Jednak wspólny serwer nie powinien oznaczać wspólnych haseł, katalogów i zasobów bez ograniczeń. W przeciwnym razie nieudana aktualizacja jednego wtyczki, zainfekowany plik lub ciężki import towarów wpłynie nie tylko na jedną stronę, ale na całą grupę.
Najczęściej problem nie wynika z niewystarczającej mocy VPS. Strony uruchamiane są z jednego użytkownika systemowego, łączą się z bazami danych przez wspólne konto i trafiają do jednego dużego archiwum kopii zapasowych. Na początku taki schemat wydaje się wygodny. Z czasem okazuje się, że oddzielny projekt nie może być bezpiecznie zatrzymany, przywrócony ani przekazany innemu deweloperowi, nie dotykając reszty infrastruktury.
Jak podzielić projekty klientów w obrębie jednego VPS
Każdą stronę warto od początku traktować jako oddzielny obiekt. Powinna mieć własne pliki, bazę, logi, ustawienia i granice wykorzystania zasobów. Wtedy można ją aktualizować, przenosić lub przywracać niezależnie od sąsiednich projektów.
Podstawowy schemat umieszczania lepiej ustandaryzować i stosować do wszystkich nowych klientów:
-
tworzyć oddzielnego użytkownika systemowego, katalog i pulę PHP dla każdej strony;
-
używać oddzielnej bazy danych i konta bez dostępu do cudzych tabel;
-
ustalać limity pamięci, czasu procesora, liczby procesów i przestrzeni dyskowej;
-
dzielić środowiska robocze i testowe;
-
prowadzić oddzielne logi błędów i zapytań dla każdego projektu;
-
nie przechowywać haseł i kluczy dostępu w otwartych plikach lub wspólnych tabelach zespołu.
Oddzielny użytkownik systemowy jest potrzebny nie tylko dla porządku w katalogach. Jeśli kilka stron uruchamianych jest z tymi samymi uprawnieniami, złośliwy skrypt na jednej z nich może czytać lub zmieniać pliki sąsiednich projektów. W zaleceniach dotyczących ochrony WordPress również zaleca się ograniczenie praw systemu plików i nie pozwalanie procesom na zapis tam, gdzie nie jest to potrzebne.
Tak samo niebezpieczne jest podłączanie wszystkich stron do baz danych przez jednego użytkownika z szerokimi uprawnieniami. Kompromitacja jednego pliku konfiguracyjnego w takim przypadku otwiera dostęp do danych innych klientów. Dla każdej CMS warto tworzyć własne konto i pozwalać mu działać tylko z odpowiednią bazą.
Czytaj także: Infrastructure as Code na VPS: jak uprościć zarządzanie infrastrukturą
Ograniczaj zasoby poszczególnych stron
Jeden sklep podczas nocnego importu może zająć całą dostępną pamięć lub uruchomić tyle procesów, że pozostałe strony zaczną wolno odpowiadać. Sam sklep może w tym czasie pozostać dostępny, dlatego przyczyna problemu nie zawsze jest od razu znajdowana.
Limity nie powinny być zbyt rygorystyczne. Ich zadaniem — nie spowolnić projektu, a nie pozwolić jednemu procesowi bez kontroli wykorzystywać cały serwer. Po uruchomieniu nowej strony warto przez kilka tygodni obserwować obciążenie, a następnie ustalić granice z rozsądnym zapasem.
Dawaj dostęp tylko do potrzebnego projektu
Wspólne hasło root, które znają wszyscy deweloperzy i wykonawcy, pozbawia agencję kontroli. Niemożliwe jest ustalenie, kto wprowadzał zmiany, szybko zamknąć dostęp jednej osobie lub ograniczyć jej pracę do konkretnej strony.
Aby zarządzać dostępami, warto wprowadzić kilka zasad:
-
wydawać osobiste klucze SSH zamiast jednego hasła dla całego zespołu;
-
nie przyznawać dostępu root, jeśli specjaliście wystarczą uprawnienia do oddzielnego katalogu;
-
prowadzić listę aktywnych dostępów z datą wydania i odpowiedzialną osobą;
-
usuwać konta i klucze po zakończeniu prac;
-
raz na kwartał sprawdzać, kto nadal ma dostęp do serwera i paneli zarządzania;
-
używać uwierzytelniania dwuskładnikowego dla kont z rozszerzonymi uprawnieniami.
Zewnętrznemu specjaliście SEO zazwyczaj potrzebne są CMS, analityka i konsolę wyszukiwania, ale nie środowisko plikowe całego VPS. Menedżerowi treści nie potrzebny jest dostęp do bazy, a deweloper jednej strony nie powinien widzieć katalogów innych klientów. To odpowiada zasadzie najmniejszych uprawnień: użytkownik otrzymuje tylko te prawa, bez których nie może wykonać swojej pracy.
Chroń staging nie słabiej niż stronę roboczą
Jeśli staging jest umieszczony w jednym koncie z innymi stronami, jego włamanie może otworzyć dostęp nie tylko do kopii testowej. Haker może dotrzeć do sąsiednich katalogów, znaleźć pliki konfiguracyjne z hasłami lub zmienić pliki innych projektów.
Dlatego dostęp do staging warto ograniczyć hasłem, adresami IP lub prywatną siecią. Zakaz indeksowania w robots.txt dla zewnętrznych odwiedzających nie chroni.
Sprawdź także integracje: wersja testowa nie powinna wysyłać rzeczywistych e-maili, przeprowadzać płatności, tworzyć umów w CRM ani zmieniać stanów towarów.
Jak utrzymywać infrastrukturę po uruchomieniu
Dobrze podzielić strony na początku to za mało. Liczba klientów rośnie, w projektach pojawiają się nowe moduły, zmieniają się wykonawcy i harmonogramy aktualizacji. Bez regularnej kontroli nawet starannie zorganizowany VPS stopniowo przekształca się w cyfrową dżunglę, w której nikt nie wie, jakie procesy działają i do kogo należą dostęp.
Skonfiguruj oddzielne kopie zapasowe dla każdej strony
Jedna kopia zapasowa całego VPS jest wygodna do przywracania serwera po całkowitej awarii, ale źle nadaje się do codziennej pracy agencji. Jeśli przez nieudaną aktualizację jeden projekt się zepsuł, nie można cofnąć razem z nim jeszcze piętnastu działających stron.
Schemat roboczy kopii zapasowej powinien uwzględniać:
-
oddzielne kopie plików i baz danych dla każdego klienta;
-
częstotliwość kopiowania zgodnie z tempem aktualizacji informacji;
-
przechowywanie przynajmniej jednej kopii poza głównym VPS;
-
szyfrowanie archiwów z danymi osobowymi;
-
automatyczną kontrolę zakończenia zadań i rozmiaru plików;
-
okresowe testowe przywracanie w czystym środowisku.
Częstotliwość tworzenia kopii zapasowych określa się nie według rozmiaru strony, ale według ilości informacji, które można stracić. Dla zasobów korporacyjnych, gdzie wiadomości pojawiają się kilka razy w miesiącu, może wystarczyć codzienna kopia. Dla sklepu z ciągłymi zamówieniami jedna kopia na dobę już oznacza ryzyko utraty znacznej części operacji.
Śledź, która strona generuje szczytowe obciążenie
Jedna zasobożerna strona może spowolnić wszystkie projekty na serwerze. Przyczyną często są import towarów, kopie zapasowe, zadania cron, ruch botów lub błąd wtyczki.
Skonfiguruj powiadomienia o szczytach CPU i pamięci, zapełnieniu dysku, błędach 5xx oraz wzroście czasu odpowiedzi. Gdy znajdziesz źródło obciążenia, zatrzymaj problematyczny proces i sprawdź logi, wtyczki, cron oraz zapytania do bazy.
Jeśli obciążenie spowodowane jest błędem, należy go usunąć. Jeśli strona rzeczywiście potrzebuje więcej zasobów, ogranicz jej zużycie lub przenieś na oddzielny serwer wirtualny, aby nie wpływała na innych klientów.
Prowadź kartę techniczną każdego projektu
Gdy agencja obsługuje wiele stron, ważne informacje nie powinny pozostawać tylko w głowie jednego dewelopera. Dla każdego projektu warto zarejestrować wersję PHP, lokalizację bazy, podłączone zewnętrzne usługi, harmonogram kopii zapasowych, odpowiedzialnych specjalistów i procedurę awaryjnego przywracania.
Przydatne jest również zaznaczenie, które procesy generują największe obciążenie. Jeśli wiadomo, że sklep codziennie o 03:00 importuje katalog, zespół nie będzie musiał za każdym razem badać krótkiego skoku użycia CPU. A jeśli obciążenie pojawiło się w innym czasie, można je już traktować jako odchylenie.
Czytaj także: Wirtualne serwery w rozwoju: jak ułatwić życie programiście
Kartę techniczną należy aktualizować po zmianie konfiguracji serwera, podłączeniu nowej integracji lub przekazaniu projektu innej ekipie. Ułatwia to utrzymanie i skraca czas przywracania po błędzie.
Kiedy stronę klienta należy przenieść na oddzielny serwer
Zwiększanie konfiguracji całego VPS przez jedną ciężką stronę nie zawsze jest opłacalne. Agencja zaczyna płacić za dodatkowe zasoby dla całej grupy, chociaż korzysta z nich głównie jeden klient. W takiej sytuacji logiczniej jest oddzielić projekt.
Przestój projektu ma wysoką cenę
Mała strona wizytówkowa i sklep internetowy, przez który przechodzi większość sprzedaży firmy, nie powinny mieć tej samej modelu umieszczania tylko dlatego, że obie działają na WordPressie. Dla krytycznej usługi ważne są oddzielne kopie zapasowe, własny zapas zasobów i możliwość przeprowadzania prac technicznych niezależnie od innych klientów.
Dla dużego sklepu, portalu lub systemu z dużymi ilościami danych następnym krokiem może być wynajem dedykowanego serwera. Jednak decyzji nie należy wiązać z liczbą domen. Dziesiątki prostych stron czasami wymagają mniej zasobów niż jeden katalog ze skomplikowanymi filtrami, wyszukiwaniem, synchronizacją stanów i ciągłym przetwarzaniem plików.
Projekt regularnie zabiera znaczną część zasobów
Jeśli jeden sklep wykorzystuje połowę pamięci VPS w zwykły dzień, podczas wyprzedaży, kampanii reklamowej lub masowego importu zapasów już jej nie będzie. Przeniesienie lepiej zaplanować przed szczytowym okresem, zostawiając czas na testowanie, synchronizację bazy i aktualizację DNS.
Przed migracją warto sprawdzić, czy nie można zmniejszyć obciążenia za pomocą cache'owania, optymalizacji zapytań, kolejek lub zmiany harmonogramu zadań w tle. Oddzielny serwer nie naprawi wolnego kodu, chociaż da mu więcej zasobów.
Stronie potrzebne jest szczególne środowisko programowe
Jeden klient może wymagać innej wersji bibliotek systemowych, własnego serwera WWW, niestandardowych modułów lub oddzielnego harmonogramu aktualizacji. Dostosowywanie wspólnego VPS do niego jest ryzykowne: zmiana konfiguracji może zakłócić działanie pozostałych stron.
Oddzielne środowisko jest również uzasadnione, gdy klient chce mieć dostęp administracyjny. Nie można go wydawać do serwera, na którym umieszczone są zewnętrzne projekty, nawet przy dobrych relacjach i podpisanych umowach.
Jeden VPS może przez lata pozostawać wygodnym centrum dla stron klientów. Stabilność nie zależy od maksymalnego zapasu mocy, ale od zasad, według których agencja tworzy projekty, wydaje dostęp, ustawia kopie zapasowe i reaguje na wzrost obciążenia. Gdy te procesy są opisane i wykonywane w sposób sekwencyjny, problem jednego klienta nie przekształca się w wspólną awarię.