Zacznij od obciążenia aplikacji, nie od planu hostingowego
Wypisz podróże (journeys), które generują wartość lub ryzyko: pierwsza wizyta, wyszukiwanie, logowanie, karta produktu, wysyłka formularza, finalizacja zakupu, edycja treści lub wywołanie API. Dla każdej zanotuj szczytowe żądania lub współużytkowników, rozmiar ładunku, personalizację, zależności i regiony odwiedzających. Uwzględnij pracę zaplanowaną i administracyjną, ponieważ konsumuje te same zasoby.
Przekształć listę w kryteria akceptacji. Largest Contentful Paint (LCP) mierzy ładowanie głównej zawartości; Interaction to Next Paint (INP) — responsywność; a Cumulative Layout Shift (CLS) — nieoczekiwane przesunięcia. Google podaje dobre progi: LCP w granicach 2,5 sekundy, INP poniżej 200 milisekund i CLS poniżej 0,1. Dodaj cele dotyczące ukończenia trasy, czasu odpowiedzi serwera i wskaźnika błędów.
Nie pozwól, aby szybka, cache’owana strona zastąpiła transakcję z uwierzytelnieniem lub opartą na bazie danych.
Zdefiniuj okres szczytowy, oczekiwany wzrost, skoki kampanii i nakładającą się pracę wsadową.
Określ, czy każdy prawdopodobny wąskie gardło kontroluje host, Twój zespół czy podmiot trzeci.
Porównaj pojemność, limity i zachowanie skalowania
Zapytaj o limity skryte za ofertą: obliczenia i pamięć, wydajność storage, połączenia z bazą danych, limity workerów, opóźnienia sieci, opłaty za transfer, kontrolę żądań i ograniczenia dotyczące sąsiadów współdzielonych. „Nielimitowany transfer” nie pokazuje, czy aplikacja potrafi wykonać wystarczająco dużo pracy niecache’owanej przy szczycie. Zapytaj, które metryki są widoczne i jak długo są przechowywane.
Skalowanie ma znaczenie tylko wtedy, gdy znany jest jego wyzwalacz, opóźnienie, sufit i cena. Potwierdź, czy jest automatyczne, czy sesje i zadania pozostają bezpieczne oraz co się dzieje po osiągnięciu limitu. Preferuj test przy oczekiwanym szczycie i poza nim zamiast teoretycznych deklaracji o pojemności. Zapas (headroom) to decyzja biznesowa, nie uniwersalny procent.
Porównuj czasy odpowiedzi p95 lub p99, nie tylko średnią.
Zbieraj czasy bazy danych, kolejek i upstream API podczas testu.
Oszacuj koszty skali, dostawy, kopii zapasowych i drugiego regionu przed zobowiązaniem.
Umieść origin świadomie i zweryfikuj dostawę
Wybierz region originu, kierując się lokalizacją odbiorców, zależnościami aplikacji, wymaganiami dotyczącymi lokalizacji danych i dostępem operacyjnym. Testuj z reprezentatywnych geografii i warunków sieciowych. CDN (content delivery network) to rozproszony cache, który może obsłużyć kwalifikujące się zasoby bliżej odwiedzających i zmniejszyć obciążenie originu; nie zastępuje zdrowego originu, bazy danych ani aplikacji.
Sprawdzaj nagłówki i zachowanie, nie tylko ustawienie na pulpicie operatora. Wersjonowane zasoby statyczne zwykle mogą mieć dłuższy czas życia, bo aktualizacja ma nowy URL. Odpowiedzi dynamiczne i spersonalizowane wymagają jasnych reguł. HTTP rozróżnia cache współdzielone i prywatne; dane konta nie mogą stać się ponownie wykorzystywalne przez innego klienta. Przećwicz czyszczenie cache i rollback.
Zarejestruj pierwszą wizytę i wizytę powrotną, bo stany cache się różnią.
Zweryfikuj Cache-Control i klucze cache dla stron, zasobów, cookies, parametrów i lokalizacji.
Udokumentuj, jak uprawniony personel wyłącza szkodliwą regułę bez ujawniania treści wrażliwych.
Traktuj dowody odzyskiwania jak wymóg wydajności
Zapytaj, co jest objęte kopią zapasową, gdzie przechowywane są kopie, retencję, uprawnienia do przywracania i czy backupy obejmują bazy danych, uploady, kod, konfigurację i infrastrukturę. Zdefiniuj RPO (recovery point objective) jako dopuszczalną utratę danych w czasie oraz RTO (recovery time objective) jako dopuszczalny czas przywrócenia. Ustal oba na podstawie konsekwencji biznesowych, nie domyślnych wartości pakietu.
Sama udana kopia zapasowa to nie dowód odzyskania. CISA zaleca zaplanowane testy przywracania, a AWS mówi, że odzyskiwanie po katastrofie powinno być oceniane i testowane. Przywróć niedawną kopię w izolacji, sprawdź ważne rekordy i media, użyj udokumentowanej sekwencji i zanotuj upływ czasu. Alternatywny region może zmniejszyć pewne ryzyka, ale zwiększa koszty i złożoność.
Odzyskaj pojedynczy plik lub rekord bez nadpisywania bieżących danych.
Ogranicz dostęp do przywracania i trzymaj poświadczenia oraz runbooki dostępne dla uprawnionych reagujących.
Snapshot bazy danych może nie odtworzyć ustawień, wersji aplikacji ani reguł dostawy.
Oceń wsparcie i model współodpowiedzialności zanim będzie potrzebne
Porównaj zakres wsparcia, godziny, kanały, eskalację oraz różnicę między incydentami platformy a diagnostyką aplikacji. Uzyskaj pisemne określenie odpowiedzialności za łatki, zarządzane bazy danych, TLS, reguły firewalla, kopie zapasowe i przywracanie. Obietnica wsparcia jest użyteczna, gdy wymienia właściciela i następne działanie w realistycznym scenariuszu.
Przejrzyj role dostępu, uwierzytelnianie wieloskładnikowe, logi audytu, obsługę sekretów i izolację kont. Dla kart płatniczych lub wrażliwych danych regulowanych funkcje hostingu same w sobie nie ustanawiają zgodności. Użyj tego porównania jako wkładu technicznego i uzyskaj kwalifikowaną ocenę bezpieczeństwa, prawna lub zgodności architektury płatniczej i obowiązków.
Zapytaj, jak dostawca postąpi przy nieudanego przywracania, nasyconej bazie danych lub szkodliwej regule cache.
Sprawdź, kto może zmieniać produkcję, czytać backupy, przeglądać logi i tworzyć poświadczenia.
Kredyty serwisowe i pokrycie zarządzane mogą mieć materialne warunki.
Przeprowadzaj realistyczne, bezpieczne testy porównawcze i prowadź kartę oceny
Użyj tej samej wersji wydania, intencji konfiguracji i skryptu testowego dla każdego kandydata. Uruchom bazę, oczekiwany szczyt, krótki skok, okres utrzymania i bezpieczne ćwiczenie odzyskiwania lub wdrożenia. AWS zaleca środowiska podobne do produkcyjnych, zdefiniowane scenariusze, monitorowanie obejmujące architekturę, zanonimizowane lub syntetyczne dane oraz regularne retesty. Uzyskaj zgodę dostawcy i przestrzegaj jego polityki testowania.
Łącz kontrolowane testy laboratoryjne z danymi z pola po uruchomieniu. Testy laboratoryjne są powtarzalne do debugowania; dane z pola odzwierciedlają rzeczywiste urządzenia, sieci, geografię, stan cache i zachowanie. Przeglądaj kartę oceny po dużych wydaniach lub zmianach zależności. SIU może przekształcić ustalenia w wzmocnienia przed uruchomieniem, naprawy przypisane właścicielom i ulepszenia gotowe do rollbacku.
Utrzymuj spójność lokalizacji, współbieżności, stanu cache i ładunków.
Zapisuj timingi tras, błędy, metryki zasobów, wersje, koszty i obserwacje.
Wybierz opcję spełniającą udokumentowane potrzeby przy zrównoważonych kosztach operacyjnych.