Verifica dei prodotti, strategie di rilascio e flusso di lavoro AI end-to-end

Guadagni:

• Comprendere le strategie di rilascio per la riduzione del rischio (blu-verde, canarino, flag di funzionalità) e la disciplina di verifica del prodotto (controllo dello stato, test del fumo, monitoraggio del segnale dorato)
• Capacità di implementare l'abitudine di preparare un chiaro piano di rollback prima dell'implementazione e di verificare i percorsi aziendali critici dopo l'implementazione
• Capacità di combinare tutte le parti apprese durante il modulo in un flusso di lavoro end-to-end supportato dall'intelligenza artificiale e di applicare il principio "l'intelligenza artificiale produce, gli esseri umani verificano e garantiscono" in ogni fase

L'intero modulo scorreva verso un punto: la consegna sicura del codice e dell'infrastruttura alla produzione (l'ambiente live utilizzato dai clienti reali). Ora ci troviamo nell’anello più critico e stressante della catena: rendere operativo un cambiamento e verificare che funzioni effettivamente. In questo caso un errore non è astratto: colpisce direttamente il cliente, le entrate e la reputazione. Ecco perché i team maturi vanno in produzione non “sperando” ma con strategie di rilascio controllate e verifiche sistematiche.

In quest'unità finale combiniamo due cose: (1) metodi di rilascio che riducono il rischio (canarino, blu-verde, flag di funzionalità) e la disciplina della verifica del prodotto; (2) come ogni aspetto appreso durante il modulo (CI/CD, IaC, contenitore, monitoraggio, incidente, costo, script, sicurezza) si unisce in un unico flusso di lavoro end-to-end basato sull'intelligenza artificiale. Ripetiamo un'ultima volta la citazione iniziale: l'intelligenza artificiale genera e accelera le bozze ad ogni passaggio; Ma sei tu che premi il pulsante "Lo prendo dal vivo" e garantisci per il risultato.

Strategie di rilascio che riducono il rischio

Imporre una modifica a tutti gli utenti contemporaneamente è il modo più rischioso. Metodi maturi:

• Distribuzione blu-verde: vengono mantenuti due ambienti identici: "blu" (live) e "verde" (nuova versione). La nuova versione viene preparata e testata in verde, poi il traffico diventa improvvisamente verde. Se c'è un problema, il traffico torna immediatamente blu. Il rollback veloce è il suo più grande vantaggio.
• Distribuzione Canary: la nuova versione viene inizialmente rilasciata a una piccola percentuale di utenti (ad esempio 5%); Se i parametri sono buoni, aumenta gradualmente fino al 100%. Un problema riguarda una piccola parte dell'utente, non l'intero utente.
• Flag funzionalità: la nuova funzionalità inserisce il codice ma viene bloccata da un flag; Viene aperto a determinati utenti quando richiesto. Esiste una distinzione tra distribuzione e "rilascio"; Se si verifica un problema, il flag viene disattivato senza ripristinare il codice.

Suggerimento: la rete di sicurezza più rapida è avere un rollback pronto prima di ogni distribuzione. "Se qualcosa va storto, come posso ripristinare la vecchia versione in 60 secondi?" Se non esiste una risposta chiara alla domanda, non sei pronto per eseguire tale distribuzione.

Verifica del prodotto: il lavoro non finisce quando termina la distribuzione

Solo perché una distribuzione sembra "verde" non significa che funzioni. Verifica sistematica:

1. Controlli dello stato: il servizio è attivo, /healthz risponde?
2. Smoke test: i pochi percorsi utente più critici (login, pagamento, ricerca) funzionano davvero? Automatico e veloce.
3. Attenzione ai segnali d'oro: tasso di errore post-distribuzione, latenza, il traffico è normale? (Quattro segnali sull'unità 6.)
4. Espandi gradualmente: osserva le metriche in ogni passaggio man mano che aumenti la percentuale Canary.
5. Finestra di osservazione: monitorare attentamente per un periodo di tempo (ad esempio 30 minuti) dopo l'implementazione; I problemi insidiosi non sono immediatamente visibili.

Attenzione: l'IA potrebbe produrre un elenco di test del fumo o verifiche, ma è tuo compito determinare quali percorsi utente sono "critici". L'intelligenza artificiale fornisce un elenco generale; Solo tu sai che il tuo flusso di pagamento, il percorso che genera più entrate, deve essere testato.

Confronto delle strategie di rilascio

Strategia

Vantaggio principale

Costo/complessità

più adatto

Blu-Verde

Rollback istantaneo

Due ambienti = 2x risorse

Se il recupero rapido è fondamentale

canarino

Limita l'impatto a una fetta piccola

È richiesta la gestione del traffico

Base di utenti enorme

FunzionalitàFlag

Separa la distribuzione dal rilascio

Debito di gestione della bandiera

Apertura graduale/mirata

Aggiornamento continuo

Semplice, rispettoso delle risorse

rollback lento

Servizi semplici

Flusso di lavoro end-to-end basato sull'intelligenza artificiale

Ora combiniamo l'intero modulo in un unico flusso. Supponiamo che tu stia pubblicando un nuovo microservizio. L'intelligenza artificiale produce bozze ad ogni passaggio; verifichi ad ogni passaggio:

1. Codice e contenitore (Unità 4): l'intelligenza artificiale produce un Dockerfile ottimizzato e sicuro; Verifica il non-segreto e la taglia.
2. CI/CD (Unità 2): scrive la pipeline AI test-build-deploy; Restringi i permessi e controlli i riferimenti segreti.
3. Infrastruttura (Unità 3): definisce le risorse richieste con AI Terraform; Leggi l'output del piano e non cerchi eliminazioni impreviste.
4. Orchestrazione (Unità 5): l'intelligenza artificiale produce manifest Kubernetes; si verifica il limite delle risorse, l'analisi e l'RBAC.
5. Sicurezza (Unità 10): dà priorità agli output della scansione AI; Prendi prima quelli sfruttabili.
6. Monitoraggio (Unità 6): l'intelligenza artificiale genera regole di allarme e dashboard; Metti alla prova le soglie con i tuoi dati passati.
7. Rilascio e convalida (questa unità): delinea lo smoke test dell'IA e il piano di rollback; avvii Canary, guardi le metriche, premi il pulsante.
8. Se si verifica un incidente (Unità 7): l'intelligenza artificiale genera ipotesi e schizzo post-mortem; Verifichi e impari le lezioni.
9. Costo (Unità 8): l’intelligenza artificiale monitora lo spreco di nuove risorse; Sei tu a prendere le giuste decisioni sul dimensionamento.

Ad ogni passo, la regola comune rimane costante: l’intelligenza artificiale produce e accelera, l’uomo verifica e garantisce. Questa è l'essenza del modulo.

tre mini custodie

Caso 1: le Canarie hanno limitato il disastro al 5%. Un team ha fornito la nuova versione al 5% degli utenti con canary. La dashboard prodotta dall’intelligenza artificiale ha immediatamente mostrato che il tasso di errore è salito all’8% in questa fetta. Il team lo ha ripreso senza aumentarlo al 100%; Il problema ha interessato solo il 5% degli utenti e solo per pochi minuti. Se si verificasse un’implementazione di grande impatto, tutti i clienti ne risentirebbero.

Caso 2: il test del fumo ha rilevato il percorso mancante. L'intelligenza artificiale ha offerto un set per il test del fumo, ma non prevedeva un flusso di "pagamento". L'ingegnere lo aggiunse, sapendo che il flusso di entrate più importante era il pagamento. Il test post-distribuzione si è interrotto proprio nella fase di pagamento: una chiave di terze parti era scaduta. La verifica ha rilevato una silenziosa perdita di entrate in pochi minuti.

Caso 3: rollback pronto salvato in 90 secondi. Una squadra che ha installato il blu-verde ha portato la nuova versione al verde; Dopo 2 minuti il ​​ritardo è raddoppiato. Hanno trasformato il traffico in blu in 90 secondi con il rollback preparato in anticipo. Hanno trovato la causa principale (una query lenta nella nuova versione) non sotto pressione, quindi con calma. Il percorso di rollback già pronto ha reso l’interruzione quasi invisibile.

Quattro modelli copiabili

1) Selezione della strategia di rilascio:

Produrrò il seguente servizio: [SERVIZIO/CONTESTO: numero di utenti, tolleranza alle interruzioni, infrastruttura]. Quale mi consigliate tra blu-verde, canarino e feature flag? Confronta i vantaggi, i costi e la velocità di ripristino di ciascuno in questo contesto. Dai un suggerimento, ma dichiara che prenderò la decisione finale.

2) Prova del fumo/elenco di verifica:

Produrre una bozza di test del fumo e un elenco di verifica per [SERVIZIO] che eseguirò dopo la distribuzione: controllo dello stato, percorsi utente più critici, quali parametri devo monitorare per quanti minuti? Supponiamo che contrassegnerò i percorsi aziendali più critici e lascerò il campo vuoto.

3) Piano di ripristino:

Utilizzo [METODO DI IMPLEMENTAZIONE]. Scrivimi un piano di rollback chiaro: con quale comando/passaggio eseguo il rollback alla vecchia versione, quanto tempo ci vuole, quali sono i rischi del rollback stesso (ad esempio non è possibile eseguire il rollback della migrazione del database), cosa devo controllare prima del rollback?

4) Lista di controllo del rilascio end-to-end:

Produrre un elenco di controllo di preparazione end-to-end per il rilascio in un nuovo progetto [SERVIZIO]: sicurezza del codice/immagine, pipeline, piano dell'infrastruttura, monitoraggio e allarmi, scansione di sicurezza, strategia di rilascio, rollback e verifica. Controlla ogni elemento con la domanda "Sono pronto?" Trasformalo in una domanda.

Prompt debole / Prompt forte

Debole: "Come posso metterlo in produzione?"

Risultato: nessun contesto; L'intelligenza artificiale elenca i passaggi generali di distribuzione, non affronta la tolleranza al rischio, la scalabilità degli utenti e le esigenze di rollback.

Güçlü: "Produrrò un servizio di pagamento con 10 milioni di utenti, la mia tolleranza per i tempi di inattività è molto bassa. Consigliate Canary o Blue-Green, perché? Quali percorsi critici dovrei testare dopo l'implementazione, quali parametri dovrei monitorare per quanti minuti e come dovrebbe essere un piano di rollback di 60 secondi? Prenderò la decisione finale."

Differenza: il secondo prompt fornisce la scala, la tolleranza e l'aspettativa di rollback; Richiede strategia + verifica + annullamento e lascia la decisione all'umano.

Errori comuni

• Distribuzione senza un piano di rollback. Se non c’è via d’uscita, ogni schieramento è una scommessa.
• Distribuzione di grande impatto. Darlo all'intero utente in una sola volta massimizza il rischio.
• Supponendo che "verde = funzionante". Il servizio che ha superato il controllo dello stato potrebbe essere interrotto nel percorso critico.
• Pensare che stai lasciando percorsi aziendali critici all’intelligenza artificiale. È necessario contrassegnare metodi come il pagamento.
• Nessun monitoraggio dopo la distribuzione. I problemi insidiosi non compaiono nel primo minuto; è necessaria una finestra di osservazione.
• Pensare che la migrazione del database sia reversibile. Alcune modifiche non vengono ripristinate; sono pianificati separatamente.

In sintesi

Passare alla produzione è l'anello più critico della catena e viene fatto non "sperando" ma con strategie controllate: il blu-verde fornisce un rollback immediato, limitando l'effetto canary a una piccola fetta, separando l'implementazione del flag di funzionalità dal rilascio. Il lavoro non finisce quando la distribuzione è terminata; È essenziale una verifica sistematica attraverso controlli sanitari, test del fumo e monitoraggio del segnale d’oro. L'intelligenza artificiale genera e accelera le bozze in ogni fase dell'intero modulo: dal Dockerfile alla pipeline, da Terraform alla regola di allarme, dall'autopsia all'analisi dei costi. Ma rimane la persona competente che verifica ogni passaggio, preme il pulsante di avvio e garantisce il risultato. Questa è la regola d'oro del DevOps end-to-end basato sull'intelligenza artificiale.

Compito dell'applicazione

Scegli un servizio (reale o immaginario) su cui pubblicare. (1) Scegli una strategia adatta al tuo contesto con il modello "Selezione della strategia di rilascio" e scrivi perché. (2) Genera un elenco di verifica con il modello "Test del fumo/elenco di verifica" e aggiungi tu stesso i percorsi aziendali più critici. (3) Preparare un piano di rollback di 60 secondi con il modello "Piano di rollback" e verificare se sono presenti passaggi irreversibili.

lista di controllo

• [ ] Ho scelto una strategia di rilascio (canarino/blu-verde/bandiera) adatta al mio contesto.
• [ ] Ho un piano di rollback chiaro e veloce pronto prima della distribuzione.
• [ ] Ho aggiunto io stesso i percorsi aziendali più critici (ad esempio i pagamenti) ai miei test del fumo.
• [] Dopo la distribuzione, controllo i segnali dorati attraverso una finestra di osservazione.
• [ ] Ho pianificato anche passaggi irreversibili (migrazione del database, ecc.).
• [] Ho verificato il progetto AI in ogni passaggio; Ho deciso di andare in diretta.

Esame del modulo

1. Quale dei seguenti è il posizionamento migliore per DevOps e AI nel cloud?

• A) L’intelligenza artificiale è uno strumento di assistente e di supporto alle decisioni; Le persone sono responsabili delle decisioni critiche che riguardano il prodotto ✔
• B) L’intelligenza artificiale può finalizzare l’implementazione dei prodotti e la rotazione segreta senza l’approvazione umana
• C) L'intelligenza artificiale è utile solo per scrivere documentazione, non ha nulla a che fare con le infrastrutture
• D) L'audit non è necessario perché l'intelligenza artificiale produce sempre comandi più affidabili dell'ingegnere

Descrizione: è uno strumento di supporto e assistente alle decisioni che accelera attività ad uso intensivo di testo come pipeline di intelligenza artificiale, configurazione, script e registro. La responsabilità delle decisioni che riguardano tempi di inattività, denaro e sicurezza, come il rilascio della produzione, la gestione segreta e l'applicazione finale, rimane dell'ingegnere competente.

2. Qual è l'espressione più accurata per la disciplina di verifica prima di implementare un comando o una configurazione DevOps prodotta dall'intelligenza artificiale?

• A) Se l'output sembra fluido e sicuro, può essere eseguito direttamente in prod
• B) L'output è sicuro solo se non sono presenti errori di sintassi, non sono necessari ulteriori controlli
• C) Collegare l'output all'origine, pianificarlo/eseguirlo e filtrarlo con il contesto del sistema; quindi applicare ✔
• D) Fare il primo tentativo direttamente nel prod e vedere il risultato è la verifica più veloce

Spiegazione: la verifica in tre passaggi è essenziale: collegare l'output all'origine (è effettivamente il comando/flag nella documentazione ufficiale), eseguirlo a secco (vedere cosa succede con il piano/--dry-run) e passarlo attraverso il filtro di sistema (si adatta al suo contesto architettonico e di sicurezza). La fluidità non significa precisione.

3. Qual è l'approccio corretto quando si chiede all'intelligenza artificiale un errore o un problema di distribuzione con un file .env che contiene una password di database reale?

• A) Maschera i veri segreti con <PLACEholder>; condividi solo l'errore mascherato e il contesto ✔
• B) Incollare l'intero file .env così com'è risolve il problema più velocemente
• C) Poiché i segreti sono già base64, è sicuro incollarli in modo semplice
• D) Incollare la password è sicuro perché l'intelligenza artificiale non la memorizza mai

Descrizione: nessun vero segreto viene incollato nel prompt dell'IA. Valori come password e token vengono mascherati con <PLACEholder>; vengono condivisi solo il messaggio di errore e il contesto necessario. Se il Segreto è già trapelato, dovrebbe essere cancellato e ruotato immediatamente.

4. Quale delle seguenti è la corretta gestione dei segreti (password, token) in una pipeline CI/CD?

• A) È conservato nel repository segreto della piattaforma e chiamato per riferimento (ad esempio ${{ secrets.X }}), non scritto in testo semplice ✔
• B) Scritto in chiaro per pipeline YAML per comodità
• C) Si verifica premendo echo e log all'inizio di ogni lavoro.
• D) Se definito con il permesso più ampio (write-all), la sicurezza aumenta

Spiegazione: i segreti non vengono scritti in YAML in testo semplice; È conservato nel repository segreto della piattaforma e chiamato con riferimenti come ${{ secrets.X }}. Inoltre, con il principio dell'autorità minima, le autorizzazioni dei token vengono limitate e il registro segreto non viene registrato.

5. Nella gestione dell'infrastruttura con Terraform, qual è il passaggio più critico da compiere prima di implementare una modifica in tempo reale?

• A) Esecuzione diretta di "terraform apply"; il piano è una perdita di tempo
• B) Backup del file di stato su un archivio pubblico
• C) Esegui 'terraform plan' e controlla le linee di distruzione/sostituzione nell'output, quindi applica ✔
• D) Disinstallare la versione del Provider e assicurarsi che la versione più recente arrivi automaticamente

Spiegazione: 'terraform plan' deve essere eseguito prima di 'terraform apply'. Il piano mostra cosa aggiungere, cosa cambiare e soprattutto cosa eliminare (distruggere), senza fare nulla. Se viene visualizzata una riga di distruzione o sostituzione inaspettata, applicare non deve essere applicato.

6. Cosa significa e cosa si dovrebbe fare se la riga "-/+ replace" per il database di produzione viene visualizzata nell'output del piano Terraform?

• R) La fonte verrà semplicemente aggiornata sul posto, non c'è rischio
• B) La risorsa verrà eliminata e ricreata; Esiste il rischio di perdita di dati, l'applicazione deve essere interrotta se non prevista ✔
• C) Aggiungendo una nuova risorsa, il database esistente non viene influenzato
• D) Questo è solo un avvertimento, può essere tranquillamente ignorato

Spiegazione: '-/+ replace' significa che la risorsa verrà eliminata e ricreata; Per un database, ciò significa perdita di dati. Se non previsto, l'applicazione deve essere interrotta, la modifica deve essere convertita in un metodo sicuro o il campo immutabile deve essere lasciato intatto.

7. Quale delle seguenti affermazioni è vera affinché un Dockerfile sia pronto per la produzione in termini di sicurezza e dimensioni?

• A) Per comodità, incorporare il segreto nell'immagine con ENV ed eseguirlo come root
• B) Utilizza sempre il tag ':latest' e mantieni l'immagine di base quanto più grande possibile
• C) Creazione in una sola fase e lasciando tutti gli strumenti di creazione nell'immagine finale
• D) Non incorporare il segreto, lavorare con UTENTI non autorizzati, utilizzare un'immagine di base piccola e stabile e una creazione in più fasi ✔

Descrizione: un'immagine pronta per la produzione: non incorpora il segreto (lo inserisce in fase di runtime), viene eseguita con un USER non autorizzato anziché root, utilizza un'immagine di base piccola e con versione (slim/alpine, non :latest) ed è ridotta con una build in più fasi. Viene inoltre scansionato per individuare eventuali vulnerabilità prima della pubblicazione.

8. Qual è il rischio più importante derivante dalla non definizione dei limiti delle risorse per una distribuzione in Kubernetes?

• R) Il pod non si avvia mai perché il limite è un campo obbligatorio
• B) Sulla scheda di monitoraggio appare solo un avviso, il funzionamento non è influenzato
• C) Kubernetes applica automaticamente limiti predefiniti sicuri, senza rischi
• D) Il pod può crescere all'infinito e consumare le risorse del nodo, mandando in crash i servizi vicini ✔

Spiegazione: un pod che non ha limiti di risorse può crescere in modo illimitato, consumare tutte le risorse del nodo su cui è in esecuzione e arrestare in modo anomalo i servizi vicini, ad esempio, con una perdita di memoria. Ecco perché la definizione di richieste/limiti è la base della robustezza.

9. Come evitare l'affaticamento da avvisi nel monitoraggio e nell'impostazione degli allarmi?

• A) Imposta allarmi sul maggior numero possibile di parametri e genera avvisi per ogni fluttuazione.
• B) Impostare tutti gli allarmi al livello di gravità più alto
• C) Attivazione allarmi con valori istantanei senza impostazione temporale (per)
• D) Mantenere gli allarmi orientati all'azione e alla giusta urgenza, testare le soglie con dati storici, unire quelli non necessari ✔

Descrizione: Ogni allarme deve essere attuabile e della giusta urgenza; Le informazioni che non richiedono azione vengono visualizzate sul tabellone, non svegliano nessuno. Le soglie di allarme vengono testate rispetto ai dati storici del sistema e gli allarmi non necessari/ripetitivi vengono consolidati. In questo modo il vero allarme non si perderà nel rumore.

10. Qual è il miglior ordine di priorità durante un incidente di produzione?

• R) Innanzitutto trovare la causa principale esatta e ridurla solo quando la causa è chiara.
• B) Prima scrivere il rapporto autoptico, poi toccare il servizio
• C) Ridurre prima (ripristino/servizio di ripristino), lasciando l'analisi della causa principale per dopo ✔
• D) Individuare innanzitutto la persona responsabile dell'incidente e segnalarlo

Spiegazione: La regola d'oro è "prima ridurre, poi indagare". L'obiettivo è innanzitutto ripristinare il servizio o riportarlo a una versione sicuramente funzionante (mitigazione); L'analisi della causa principale viene eseguita con calma dopo che la pressione si è attenuata. L'attesa di trovare la causa principale esatta aumenta il tempo di ripristino (MTTR).

11. Qual è lo scopo principale della cultura post-mortem irreprensibile?

• A) Identificare la persona che ha commesso l'errore e attribuirgli la responsabilità
• B) Concentrarsi su sistemi e processi e incoraggiare l'apprendimento; ✔ Imparare lezioni che impediscano la ripetizione piuttosto che la colpa
• C) Non denunciare mai l'accaduto e fare in modo che venga dimenticato
• D) Scrivere solo dettagli tecnici e non aggiungere elementi utilizzabili

Spiegazione: l'autopsia senza colpa si concentra sulla domanda "quale sistema e processo ha permesso questo errore", non "chi lo ha fatto". Le persone condividono apertamente l’errore se sanno che non saranno punite; L'errore nascosto si ripete. Il rapporto non è un rapporto di accusa, ma un documento di apprendimento ricco di elementi orientati all'azione.

12. Nell'ottimizzazione dei costi del cloud (FinOps), qual è il passo più logico da compiere prima di passare agli sconti impegnati (Piano riservato/risparmio)?

• A) Prima prenditi l’impegno più lungo possibile, poi pensa agli sprechi
• B) Innanzitutto, ripulire i rifiuti (chiusura inattiva, dimensionamento corretto), quindi impegnarsi ad un utilizzo conforme ✔
• C) Spostare immediatamente tutte le risorse nella capacità Spot
• D) Eliminazione dell'articolo più costoso senza rivedere i dati della fattura

Spiegazione: i rifiuti devono essere prima ripuliti (chiudendo le risorse inattive, riducendo le risorse sovradimensionate). Altrimenti bloccherai l'utilizzo sprecato ad un prezzo scontato per 1-3 anni. Il corretto dimensionamento e la pulizia inattiva non richiedono impegno e sono quasi privi di rischi.

13. Qual è la misura di sicurezza più importante se uno script suggerito dall'intelligenza artificiale ha la riga 'rm -rf "$DIR"/'?

• R) L'esecuzione dello script direttamente in Prod senza leggerlo aumenterà la velocità
• B) Aggiungi set -euo pipefail e il controllo variabile vuoto e prova prima con una prova di funzionamento ✔
• C) È sufficiente abbreviare il nome della variabile
• D) L'uso di rm -rf --force invece di rm risolve il problema

Spiegazione: Se $DIR è vuoto, questa istruzione potrebbe tentare di eliminare la directory root. Fermarsi alla variabile non definita con 'set -u' e controllare che la variabile non sia vuota prima di eliminarla (ad esempio [ -n "$DIR" ] || exit 1) evita il disastro. Inoltre, le operazioni distruttive dovrebbero essere tentate prima con il funzionamento a secco.

14. Qual è la prima cosa da fare se una chiave di accesso al cloud penetra accidentalmente in un repository pubblico?

• A) Annullare e rinnovare (ruotare) immediatamente la chiave; La sola cancellazione non è sufficiente ✔
• B) Basta eliminare il file dall'archivio e la chiave è al sicuro
• C) Non fare nulla perché nessuno l'ha visto
• D) Rendere privato lo spazio di archiviazione elimina la necessità di ruotare la chiave

Spiegazione: il segreto trapelato deve essere annullato e ruotato immediatamente. La semplice eliminazione del file non è sufficiente perché il segreto rimane nella cronologia di Git e i repository pubblici vengono scansionati dai bot in pochi secondi. Dopo la cancellazione/restituzione, viene valutato l'impatto e viene aggiunto uno scanner segreto per prevenire il ripetersi.

15. Quale dei seguenti approcci minimizza il rischio quando si rilascia una nuova versione di Prod?

• R) Fornire la nuova versione a tutti gli utenti contemporaneamente (big-bang) e non preparare un piano di rollback
• B) Considerare terminata la distribuzione non appena appare "verde", senza eseguire ulteriori verifiche
• C) Utilizzo di una strategia controllata come canary/blu-verde/feature flag, piano di rollback già pronto e test del fumo + monitoraggio metrico dopo l'implementazione ✔
• D) Lasciare la sperimentazione dei percorsi aziendali critici interamente all’intelligenza artificiale e non determinarli affatto.

Spiegazione: le strategie di rilascio controllato (iniziando con una piccola percentuale con canary, rollback immediato con blu-verde, separando la distribuzione dal rilascio con flag di funzionalità) limitano il rischio. Inoltre, sono essenziali un chiaro piano di ripristino prima dell’implementazione e il monitoraggio del segnale d’oro con test del fumo dopo l’implementazione; "sembra verde" non significa che funzioni.