Definisci la prontezza intorno a un risultato cliente
Inizia dagli obiettivi, non dalle etichette infrastrutturali. Una homepage raggiungibile non è sufficiente se un visitatore non può completare il compito che conta. Per ogni percorso critico, dichiara chi sta cercando di fare cosa, cosa significa successo e quale risultato è inaccettabile. Parti da pochi percorsi in modo che il team possa prendere decisioni reali.
Classifica ogni passaggio come essenziale, importante o rinviabile. Essenziale significa che il percorso non può concludersi senza quel passaggio; importante può permettere una soluzione temporanea; rinviabile può essere omesso, posticipato o semplificato. Questa è una decisione di prodotto informata dall'ingegneria, non una graduatoria tecnica universale.
Registra un risultato utilizzabile, come un ordine accettato e la conferma memorizzata, invece di limitarti a un obiettivo di risposta di pagina.
Mappa le dipendenze e decidi cosa può degradare
Per ogni percorso critico, mappa hosting o delivery, DNS, servizi applicativi, database, autenticazione, email, pagamento, ricerca, tag, strumenti di consenso e API esterne. Registra il proprietario, la via di supporto, il limite rilevante e l'effetto sull'utente se ciascuno non è disponibile. OWASP raccomanda conoscenza delle dipendenze software; la stessa disciplina di ownership aiuta con le dipendenze operative.
Una dipendenza rigida interrompe il compito quando fallisce. Una dipendenza morbida può essere assente o obsoleta mentre il compito principale continua a funzionare. AWS descrive la degradazione elegante (graceful degradation) come il mantenimento della funzione core quando le dipendenze sono malsane. Definisci una scelta specifica di prodotto: nascondi un widget non essenziale, differisci un report o presenti un fallback trasparente. Non inventare inventario, prezzi, stati d'ordine o esiti di pagamento.
Cattura scopo, proprietario, limite noto, fallback, contatto per le modifiche e data dell'ultimo test per ogni elemento.
Trasforma una previsione di traffico in un esperimento di capacità
Usa uno scenario, non un singolo numero di traffico. Descrivi l'evento, il pattern di arrivo, il mix di richieste, la quota di utenti autenticati, la geografia, l'attività concorrente di checkout o scrittura e il periodo di picco. Includi un caso alto e le assunzioni. Google nota che le richieste possono avere costi di risorse molto diversi, quindi le richieste al secondo da sole possono essere un modello di capacità fuorviante.
Testa traffico sostenuto, rappresentativo e end-to-end contro una configurazione vicina alla produzione, con approvazioni e salvaguardie. AWS mette in guardia dall'eseguire test solo su componenti, usare un sottoinsieme di richieste non rappresentativo o fermarsi a un piccolo margine oltre il carico previsto. Documenta il primo vincolo o rallentamento. I test in produzione possono influire sui clienti; usa un ambiente controllato a meno che non si tratti di un esercizio pianificato e presidiato.
Mantieni lo scenario, la configurazione, il mix di richieste, la durata, il vincolo osservato, il cambiamento di capacità e il referente per il follow-up.
Prepara scelte di modifica, rollback e recupero
Prima di una modifica ad alto rischio, identifica l'artefatto o la configurazione da ripristinare, le approvazioni necessarie, la persona autorizzata e il metodo di validazione. Mantieni un runbook breve per mettere in pausa una release, annullare una distribuzione, disabilitare un feature flag, ridurre un'integrazione non critica o ripristinare dati usando una procedura approvata. Prova la meccanica prima dell'evento; un backup o piano di rollback non esercitato è un'ipotesi.
Stabilisci obiettivi di recupero in base all'impatto sul business. Recovery Time Objective, o RTO, è il ritardo massimo accettabile prima che il servizio sia ripristinato. Recovery Point Objective, o RPO, è la perdita massima di dati accettabile misurata dall'ultimo punto di recupero. AWS avverte contro obiettivi arbitrari o irrealistici e osserva che gli obiettivi delle dipendenze influenzano ciò che è raggiungibile. Tratta i target come obiettivi di pianificazione, non come promesse al cliente.
Verifica un rollback o un ripristino limitato e sicuro e registra cosa è stato controllato, da chi e qualsiasi lacuna riscontrata.
Assegna ownership prima che le decisioni diventino urgenti
Una lista di contatti da sola non è ownership. Per ogni percorso critico, assegna un proprietario di business per il risultato accettabile, un proprietario tecnico per l'implementazione e un decision owner autorizzato a compiere una modifica protettiva. Nomina backup e chiarisci quando un provider, un'agenzia, un processore di pagamenti o un team interno detiene l'azione successiva.
Esegui una breve review di readiness prima che arrivi il traffico. Attraversa il fallimento di una dipendenza: cosa rimane disponibile, quale leva è sicura, chi la approva e come si verifica il successo. Questa è una prova proattiva, non un rapporto di stato live. Registra azioni datate, proprietari e scadenze.
Pre-autorizza azioni sicure e limitate dove appropriato in modo che la protezione non dipenda da una catena di approvazione poco chiara.
Tratta con cura i percorsi sensibili a pagamento e sicurezza
La prontezza del checkout deve preservare la correttezza oltre alla disponibilità. Non bypassare autorizzazioni, indebolire i controlli d'accesso, esporre credenziali o modificare alla leggera gli script della pagina di pagamento. La PCI SSC fornisce indicazioni su autorizzazione, integrità e rilevamento delle manomissioni per gli script della pagina di pagamento e gli header HTTP che impattano la sicurezza. Se il sito accetta carte o usa un frame di pagamento incorporato, fai esaminare le modifiche materiali dal merchant, dal processore, dall'acquirer e da consulenti qualificati per sicurezza o conformità.
Mantieni un inventario degli script di produzione, integrazioni, versioni e proprietà degli account e restringi chi può modificarli. OWASP osserva che gli inventari delle dipendenze e il pinning delle versioni possono ridurre l'incertezza su cosa entra in una build, mentre le segnalazioni automatiche richiedono comunque verifica manuale. Queste pratiche supportano la readiness ma non stabiliscono la conformità PCI né sostituiscono una valutazione di sicurezza.
Usa solo un flusso alternativo approvato e revisionato dal processore; non raccogliere mai dati delle carte tramite canali informali.