Zdefiniuj gotowość wokół rezultatu dla klienta
Zacznij od rezultatów, nie etykiet infrastrukturalnych. Osiągalna strona główna nie wystarczy, jeśli odwiedzający nie może wykonać istotnego zadania. Dla każdej krytycznej ścieżki określ, kto próbuje zrobić co, co oznacza sukces i który wynik jest nieakceptowalny. Zacznij od kilku ścieżek, aby zespół mógł podejmować rzeczywiste decyzje.
Sklasyfikuj każdy krok jako niezbędny, ważny lub odroczalny. "Niezbędny" oznacza, że bez niego ścieżka nie może zostać zakończona; "ważny" może pozwolić na tymczasowe obejście; "odroczalny" można pominąć, opóźnić lub uprościć. To decyzja produktowa wsparta przez inżynierię, nie uniwersalna techniczna klasyfikacja.
Zapisz użyteczny wynik, na przykład: zamówienie zostało przyjęte i potwierdzenie jest zapisane, zamiast ograniczać się tylko do celu odpowiedzi strony.
Zmapuj zależności i zdecyduj, co może się pogorszyć
Dla każdej krytycznej ścieżki zmapuj hosting lub dostawę treści, DNS, usługi aplikacyjne, bazy danych, uwierzytelnianie, e-mail, płatności, wyszukiwanie, tagi, narzędzia zgody i zewnętrzne API. Zanotuj właściciela, trasę wsparcia, odpowiedni limit i efekt dla użytkownika, jeśli element będzie niedostępny. OWASP rekomenduje wgląd w zależności oprogramowania; ta sama dyscyplina odpowiedzialności pomaga też w przypadku zależności operacyjnych.
Twarda zależność zatrzymuje zadanie, gdy zawiedzie. Miękka zależność może być nieobecna lub przestarzała, podczas gdy rdzeń zadania nadal działa. AWS opisuje graceful degradation jako utrzymanie podstawowej funkcji dostępnej, gdy zależności są niezdrowe. Zdefiniuj wybór specyficzny dla produktu: ukryć nieistotny widget, odłożyć raport lub zaprezentować uczciwy fallback. Nie wymyślaj inwentarza, cen, stanów zamówień ani wyników płatności.
Zarejestruj cel, właściciela, znany limit, fallback, kontakt do zmiany i datę ostatniego testu dla każdego elementu.
Zamień prognozę ruchu w eksperyment pojemności
Użyj scenariusza, nie pojedynczej liczby ruchu. Określ wydarzenie, wzorzec przybywania, miks żądań, udział zalogowanych, geografię, aktywność jednoczesnych checkoutów lub zapisów, oraz okres szczytowy. Dołącz wariant wysoki i założenia. Google zauważa, że żądania mogą mieć bardzo różne koszty zasobów, więc sama liczba żądań na sekundę może być słabym modelem pojemności.
Testuj utrzymujący się, reprezentatywny ruch end-to-end przeciwko konfiguracji bliskiej produkcji, z zatwierdzeniem i zabezpieczeniami. AWS ostrzega przed testowaniem jedynie komponentów, używaniem niereprezentatywnego podzbioru żądań lub zatrzymywaniem się na niewielkim marginesie powyżej oczekiwanego obciążenia. Udokumentuj pierwsze ograniczenie lub spowolnienie. Testy na żywej produkcji mogą wpływać na klientów; użyj kontrolowanego środowiska, chyba że planowane, obsadzone ćwiczenie jest stosowne.
Zachowaj scenariusz, konfigurację, miks żądań, czas trwania, zaobserwowane ograniczenie, zmianę pojemności i właściciela dalszych działań.
Przygotuj wybory dotyczące zmian, rollbacku i odzyskiwania
Przed zmianą o dużym ryzyku określ artefakt lub konfigurację do przywrócenia, wymagane zatwierdzenie, osobę upoważnioną i metodę weryfikacji. Miej krótki runbook dotyczący zatrzymania wydania, przywrócenia deployu, wyłączenia flagi funkcji, ograniczenia niekrytycznej integracji lub przywrócenia danych za pomocą zatwierdzonej procedury. Przetestuj mechanikę przed wydarzeniem; nieprzetestowana kopia zapasowa lub plan rollbacku to założenie.
Ustal cele odzyskiwania z perspektywy wpływu biznesowego. Recovery Time Objective (RTO) to maksymalne akceptowalne opóźnienie przed przywróceniem usługi. Recovery Point Objective (RPO) to maksymalna dopuszczalna utrata danych mierzona od ostatniego punktu przywracania. AWS ostrzega przed arbitralnymi lub nierealistycznymi celami i zauważa, że cele dla zależności wpływają na to, co jest osiągalne. Traktuj cele jako cele planistyczne, a nie obietnice dla klienta.
Zweryfikuj ograniczony, bezpieczny rollback lub przywrócenie i zarejestruj, co sprawdzono, przez kogo i wykrytą lukę.
Przydziel własność zanim decyzje staną się pilne
Lista kontaktów to nie to samo co własność. Dla każdej krytycznej ścieżki przypisz właściciela biznesowego za akceptowalny wynik, właściciela technicznego za implementację oraz właściciela decyzji upoważnionego do dokonania ochronnej zmiany. Wymień zastępstwa i wyjaśnij, kiedy dostawca, agencja, procesor płatności lub zespół wewnętrzny ma następne zadanie.
Przeprowadź krótką przegląd gotowości przed nadejściem ruchu. Przejdź przez jedną awarię zależności: co pozostaje dostępne, który dźwignia jest bezpieczna, kto ją zatwierdza i jak sprawdza się sukces. To proaktywna próba, nie raport stanu na żywo. Zarejestruj datowane działania, właścicieli i terminy.
Wstępnie autoryzuj wąskie, bezpieczne działania tam, gdzie to stosowne, aby ochrona nie czekała na niejasny łańcuch zatwierdzeń.
Traktuj ścieżki płatności i wrażliwe na bezpieczeństwo z dodatkową ostrożnością
Gotowość ścieżki płatności musi zachować poprawność, a nie tylko dostępność. Nie obchodź autoryzacji, nie osłabiaj kontroli dostępu, nie narażaj poświadczeń ani nie zmieniaj lekkomyślnie skryptów strony płatności. Wytyczne PCI SSC dotyczą autoryzacji, integralności i wykrywania manipulacji dla skryptów strony płatności i nagłówków HTTP wpływających na bezpieczeństwo. Jeśli witryna akceptuje karty lub używa osadzonej ramki płatności, zleć przegląd materiałowych zmian sprzedawcy, procesorowi, acquirerowi i wykwalifikowanym doradcom ds. bezpieczeństwa lub zgodności.
Prowadź inwentarz skryptów produkcyjnych, integracji, wersji i własności kont oraz ogranicz dostęp do zmian. OWASP wskazuje, że inwentarze zależności i przypinanie wersji mogą zmniejszyć niepewność co do tego, co trafia do builda, podczas gdy automatyczne wykrycia nadal wymagają ręcznej weryfikacji. Te praktyki wspierają gotowość, ale nie ustanawiają zgodności PCI ani nie zastępują oceny bezpieczeństwa.
Używaj tylko alternatywnego flow zatwierdzonego przez procesora; nigdy nie zbieraj danych kart przez nieformalne kanały.