Rendi la prontezza
verificabile.
Un piano interattivo per assegnare e verificare il lavoro di lancio nelle aree Abilitare, Rafforzare, Accelerare e Ripristinare. Funziona senza account; i proprietari SIU connessi possono, se lo desiderano, salvare privatamente i progressi per categoria. Non è un gate di rilascio, né monitoraggio, né controllo di produzione.
USALO PER: Usa l'ordine di priorità deterministico per rendere visibili proprietà e verifiche, preservando Sconosciuto e Escludi come risultati espliciti invece che come completamento implicito.
Esegui il prossimo passo noto.
- Scegli una corsia, quindi assegna a ciascun elemento a priorità deterministica uno stato: Pronto, Sconosciuto o Escludi. Sconosciuto invita a raccogliere evidenze; Escludi richiede una decisione assunta da una persona responsabile.
- Rivedi il proprietario e la dichiarazione di verifica per ogni elemento. Modifica il campo proprietario solo per indicare un ruolo o una persona responsabile—non inserire mai credenziali o dati dei clienti nel piano.
- Scarica il piano corrente sul dispositivo quando è utile un passaggio portatile. Il salvataggio opzionale su account SIU memorizza solo l'etichetta del sito e gli stati d'azione per categoria; URL, credenziali, file e note libere del proprietario sono esclusi.
La bacheca di controllo del lancio.
Ordine deterministico: Gli elementi restano nella loro sequenza numerata di priorità. Scegli SCONOSCIUTO quando manca l’evidenza; scegli SALTA solo con una decisione del responsabile.
Abilitare
Stabilire le decisioni minime, i responsabili e gli elementi rivolti al pubblico prima che un rilascio proceda.
- 01Definire l'intento del rilascio e il percorso cliente che modifica
Un ambito piccolo e esplicito fornisce a revisori e responsabili della risposta un punto di partenza condiviso.
RESPONSABILE: Responsabile rilascio · VERIFICA: Un revisore può indicare il percorso modificato, l'esito previsto per il cliente e la finestra di rilascio in un unico breve documento. - 02Confermare il testo del contatto e dell'escalation rivolti ai clienti
I clienti necessitano di un modo chiaro per segnalare impatti senza un messaggio improvvisato durante un cambiamento.
RESPONSABILE: Responsabile comunicazioni clienti · VERIFICA: Il contatto on-call o del supporto è raggiungibile tramite il canale approvato e il testo pubblico ha un responsabile incaricato. - 03Percorrere il percorso cliente principale prima del lancio
Un percorso visibile dal browser può rivelare problemi che il risultato di una build non mostra.
RESPONSABILE: Responsabile prodotto o QA · VERIFICA: Il team registra l'URL iniziale, l'esito atteso e eventuali limiti di accesso che richiedono autenticazione o pagamento senza utilizzare dati dei clienti.
Rafforzare
Rendere il rilascio e il suo percorso di recupero più facili da ispezionare, limitare e invertire con le persone giuste.
- 04Catturare l'identificatore del rilascio e un record di cambiamento reversibile
Un riferimento preciso riduce le congetture se il cambiamento deve essere messo in pausa o invertito.
RESPONSABILE: Responsabile rilascio · VERIFICA: L'identificatore del rilascio, la sorgente del deployment, l'approvatore e la rotta di rollback nota sono disponibili al responsabile della risposta. - 05Verificare che gli operatori designati abbiano il percorso di accesso corretto
L'escalation è più lenta quando le assunzioni sull'accesso non sono testate.
RESPONSABILE: Responsabile piattaforma · VERIFICA: Un ambiente non di produzione o una simulazione approvata conferma che le persone responsabili possono raggiungere gli strumenti documentati; non condividere le credenziali in questo piano. - 06Revisionare la superficie di cambiamento delle dipendenze e dei terzi
I cambiamenti di terze parti possono alterare il percorso di lancio anche quando il codice dell'applicazione resta invariato.
RESPONSABILE: Responsabile engineering · VERIFICA: Il record di rilascio indica le dipendenze nuove o modificate, gli endpoint esterni e la persona che può valutarne ciascuno.
Accelerare
Ridurre il carico di consegna evitabile mantenendo un percorso di lancio osservabile e sottoposto a revisione.
- 07Ispezionare le immagini candidate nelle loro posizioni renderizzate
Una sola immagine sorgente non indica quali byte il cliente riceverà.
RESPONSABILE: Responsabile design o performance · VERIFICA: Per le immagini prioritarie, il team registra la larghezza renderizzata prevista, il testo alternativo accessibile e se esistono varianti responsive. - 08Stabilire un budget di consegna verificabile per il percorso modificato
Un contesto di misurazione dichiarato è più utile di una promessa di prestazioni senza limiti.
RESPONSABILE: Responsabile performance · VERIFICA: Il team documenta la metrica, il contesto del test e l'intervallo accettabile; non implica una dichiarazione universale sulla velocità. - 09Scegliere un piccolo insieme di percorsi di osservazione post-rilascio
Un controllo mirato è più facile da interpretare rispetto a un elenco di URL senza responsabile.
RESPONSABILE: Responsabile rilascio · VERIFICA: Non più di cinque percorsi relativi vengono assegnati a un responsabile, ciascuno con una nota di osservazione o una risposta attesa.
Ripristinare
Preparare un passaggio di consegne calmo, una via di escalation e una risposta reversibile prima che i clienti ne abbiano bisogno.
- 10Assegnare ruoli decisionali per incidente, tecnica e comunicazioni
La chiarezza dei ruoli sostiene una risposta coordinata senza presupporre che una sola persona possa diagnosticare ogni problema.
RESPONSABILE: Responsabile risposta agli incidenti · VERIFICA: Ciascun ruolo ha una persona nominata come responsabile o una chiara via di escalation per la finestra di rilascio. - 11Provare il confine decisionale per sospendere o ripristinare
Una procedura reversibile è più sicura quando i passaggi di approvazione e verifica sono noti prima che aumenti la pressione.
RESPONSABILE: Responsabile rilascio · VERIFICA: Il team conosce la condizione di attivazione approvata, chi la autorizza e quali evidenze devono essere raccolte prima e dopo l'azione. - 12Collegare il lavoro sullo stato del servizio live a Status Is Down
SIU fornisce indicazioni di pianificazione; il lavoro sullo stato del servizio in tempo reale appartiene a SID.
RESPONSABILE: Responsabile comunicazioni · VERIFICA: Il piano di comunicazione indirizza le persone alla destinazione SID pertinente per il segnale di servizio in tempo reale e gli aggiornamenti.
Rivedi tutti gli elementi non pronti con il proprietario pertinente prima della decisione di rilascio.
Confronta le dichiarazioni di verifica con l'ambiente di rilascio effettivo e il processo di risposta documentato.
Instrada lo stato del servizio in tempo reale e il lavoro sugli incidenti in corso verso SID e il flusso di lavoro per gli incidenti del team.
Esportazione di pianificazione lato client. Non è un'approvazione di rilascio, un record di monitoraggio o un controllo di produzione.
Note sulla fonte, non certezza presa in prestito.
Base di pianificazione: riferimenti di Google SRE, CISA, OWASP, web.dev e MDN usati dalle guide SIU collegate
- CISA — Planning: Response & Recovery ↗CISA evidenzia la pianificazione del recupero da incidenti e disastri, la prioritizzazione dell'impatto sul business, i percorsi di contatto e la struttura interna di reportistica.
- Google SRE Book — Production service best practices ↗La guida raccomanda rollout progressivi supervisionati e il rollback come prima azione quando si osservano comportamenti inaspettati, per poi diagnosticare e ridurre i tempi di recupero.
- OWASP — Software Supply Chain Security Cheat Sheet ↗OWASP raccomanda inventario delle dipendenze, generazione automatica di SBOM dove appropriato, monitoraggio, fissaggio delle versioni, inventario degli strumenti di build e controlli di provenienza.
- web.dev — Responsive images ↗web.dev spiega che i byte delle immagini possono essere significativi e descrive i candidati responsive, srcset, sizes e picture per i casi d'uso appropriati.
Autore: Bozza editoriale di SIU Enablement; linee guida operative vincolate alle fonti. Revisionato da: Un responsabile del rilascio deve rivedere ogni piano. Il salvataggio opzionale su account conserva privatamente solo l'etichetta del sito e gli stati d'azione per categoria; SIU non approva un rilascio. Rivalida: Rivalida prima di un rilascio rilevante e quando cambiano proprietà, strumenti o percorsi cliente.