Questo documento descrive il ripristino di emergenza (RE) e la pianificazione della continuità aziendale nel contesto della integrazione e distribuzione continua (CI/CD). Fornisce inoltre indicazioni su come identificare e mitigare le dipendenze durante lo sviluppo di un piano di continuità aziendale (BCP) completo. Il documento include le best practice che puoi applicare al tuo piano di continuità aziendale, indipendentemente dagli strumenti e dalle procedure che utilizzi. Il documento presuppone che tu abbia familiarità con le nozioni di base del ciclo di operazioni e distribuzione del software, CI/CD e RE.
Le pipeline CI/CD sono responsabili della creazione e del deployment delle applicazioni business critical. Pertanto, come per l'infrastruttura delle applicazioni, il processo CI/CD richiede la pianificazione del RE e della continuità aziendale. Quando pensi al RE e alla continuità aziendale per CI/CD, è importante comprendere ogni fase del ciclo di distribuzione e delle operazioni del software e capire come funzionano insieme come processo olistico.
Il seguente diagramma è una rappresentazione semplificata del ciclo di operazioni e sviluppo del software, che include le tre fasi riportate di seguito:
- Loop interno di sviluppo: codifica, prova e commit
- Integrazione continua: compilazione, test e sicurezza
- Distribuzione continua: promozione, implementazione, rollback e metriche
Questo diagramma mostra anche che Google Kubernetes Engine (GKE), Cloud Run e Google Distributed Cloud sono possibili target di deployment del ciclo di operazioni e sviluppo del software.
Durante il ciclo di operazioni e sviluppo del software, devi considerare l'impatto di un disastro sulla capacità dei team di operare e mantenere le applicazioni business critical. In questo modo, potrai determinare il Recovery Time Objective (RTO) e Recovery Point Objective (RPO) per gli strumenti della tua toolchain CI/CD.
Inoltre, la maggior parte delle organizzazioni ha molte pipeline CI/CD diverse per applicazioni e insiemi di infrastrutture diversi e ogni pipeline ha requisiti unici per la pianificazione RE e della continuità aziendale. La strategia di recupero che scelgono per una pipeline varia in base al RTO e al RPO degli strumenti. Ad esempio, alcune pipeline sono più critiche di altre e avranno requisiti RTO e RPO inferiori. È importante identificare le pipeline di importanza fondamentale per l'attività nel piano di continuità aziendale e queste devono anche ricevere maggiore attenzione quando implementi le best practice per testare ed eseguire le procedure di recupero.
Poiché ogni processo CI/CD e la relativa toolchain sono diversi, gli scopi di questa guida sono aiutarti a identificare i singoli punti di défaillance nel processo CI/CD e a sviluppare un piano di continuità aziendale completo. Le sezioni seguenti ti consentono di:
- Scopri cosa serve per recuperare da un evento di RE che influisce sul processo CI/CD.
- Determina il RTO e il RPO per gli strumenti nel processo CI/CD.
- Comprendi i modi di errore e le dipendenze del processo CI/CD.
- Scegli una strategia di recupero appropriata per gli strumenti della tua toolchain.
- Scopri le best practice generali per l'implementazione di un piano di recupero RE per il tuo processo CI/CD.
Informazioni sulla procedura di continuità aziendale
La creazione di un BCP è fondamentale per garantire che la tua organizzazione possa continuare le sue operazioni in caso di interruzioni ed emergenze. Aiuta la tua organizzazione a tornare rapidamente a uno stato di normale funzionamento per il suo processo CI/CD.
Le sezioni seguenti descrivono le fasi di alto livello che includono i passaggi necessari per creare un piano di continuità aziendale efficace. Sebbene molti di questi passaggi si applichino in generale alla gestione del programma e RE, alcuni sono più pertinenti alla pianificazione della continuità aziendale per il processo CI/CD. I passaggi particolarmente pertinenti alla pianificazione della continuità aziendale per CI/CD sono evidenziati nelle sezioni seguenti e costituiscono anche la base per le indicazioni nel resto del documento.
Iniziazione e pianificazione
In questa fase iniziale, i team tecnici e aziendali collaborano per stabilire le basi per la procedura di pianificazione della continuità aziendale e la sua manutenzione continua. I passaggi chiave di questa fase sono i seguenti:
- Sostegno del team direttivo: assicurati che il top management supporti e promuova lo sviluppo del BCP. Assegna un team dedicato o una persona responsabile della supervisione del piano.
- Allocazione delle risorse: assegna il budget, il personale e le risorse necessari per lo sviluppo e l'implementazione del BCP.
- Ambito e obiettivi: definisci l'ambito del piano di continuità aziendale e i relativi obiettivi. Determina quali processi aziendali sono fondamentali e devono essere affrontati nel piano.
- Valutazione del rischio: identifica potenziali rischi e minacce che potrebbero interrompere la tua attività, come calamità naturali, violazioni della cybersecurity o interruzioni della catena di approvvigionamento.
- Analisi dell'impatto: valuta le potenziali conseguenze di questi risultati della valutazione del rischio sulle operazioni aziendali, sulle finanze, sulla reputazione e sulla soddisfazione dei clienti.
Analisi dell'impatto sull'attività
In questa fase, i team aziendali e tecnici analizzano l'impatto delle interruzioni sull'attività dei clienti e dell'organizzazione e danno la priorità al recupero delle funzioni aziendali critiche. Queste funzioni aziendali vengono eseguite da diversi strumenti durante le diverse fasi di un processo di compilazione e implementazione.
L'analisi dell'impatto aziendale è una fase importante del processo di pianificazione della continuità aziendale per CI/CD, in particolare i passaggi per identificare le funzioni aziendali critiche e le dipendenze dagli strumenti. Inoltre, comprendere la toolchain CI/CD, incluse le dipendenze e il funzionamento all'interno del ciclo di vita DevOps, è un componente di base per lo sviluppo di un piano di continuità aziendale per il processo CI/CD.
I passaggi chiave nella fase di analisi dell'impatto sull'attività includono:
- Funzioni critiche: determina le funzioni e i processi aziendali chiave che devono avere la priorità per il recupero. Ad esempio, se stabilisci che il deployment delle applicazioni è più importante dell'esecuzione dei test di unità, darai la priorità al recupero per gli strumenti e le procedure di deployment delle applicazioni.
- Dipendenze: identifica le dipendenze interne ed esterne che potrebbero influire sul recupero delle funzioni critiche. Le dipendenze sono particolarmente importanti per garantire il funzionamento continuo del processo CI/CD tramite la relativa toolchain.
- RTO e RPO: definisci limiti accettabili per i tempi di riposo e la perdita di dati per ogni funzione critica. Questi target RTO e RPO sono collegati all'importanza di una funzione aziendale per il proseguimento delle operazioni e richiedono strumenti specifici necessari per il funzionamento regolare della funzione aziendale.
Sviluppo della strategia
In questa fase, il team tecnico sviluppa strategie di recupero per le funzioni aziendali critiche, come il ripristino delle operazioni e dei dati e la comunicazione con fornitori e stakeholder. Lo sviluppo della strategia è anche un aspetto fondamentale della pianificazione della continuità aziendale per il processo CI/CD, in particolare del passaggio di selezione delle strategie di recupero di alto livello per le funzioni critiche.
I passaggi chiave nella fase di sviluppo della strategia includono:
- Strategie di recupero: sviluppa strategie per ripristinare le funzioni critiche. Queste strategie potrebbero prevedere sedi alternative, lavoro da remoto o sistemi di backup. Queste strategie sono legate ai target RTO e RPO per ogni funzione critica.
- Relazioni con i fornitori: stabilisci piani di comunicazione e coordinamento con i fornitori e i partner chiave per mantenere in funzione la catena di approvvigionamento durante le interruzioni.
- Recupero di dati e risorse IT: crea piani per il backup dei dati, il recupero del sistema IT e le misure di cybersicurezza.
- Piano di comunicazione: sviluppa un piano di comunicazione chiaro per gli stakeholder interni ed esterni durante e dopo un'interruzione.
Sviluppo del piano
In questa fase, il passaggio principale è documentare il piano di continuità aziendale. Il team tecnico documenta gli strumenti, i processi, le strategie di recupero, la motivazione e le procedure per ogni funzione critica. Lo sviluppo del piano include anche la stesura di istruzioni dettagliate da seguire per i dipendenti durante un'interruzione. Durante l'implementazione e la manutenzione continua, potrebbe essere necessario apportare modifiche al piano, che deve essere considerato un documento dinamico.
Implementazione
In questa fase, implementi il piano per la tua organizzazione utilizzando il BCP creato dal team tecnico. L'implementazione include la formazione dei dipendenti e i test iniziali del BCP. L'implementazione include anche l'utilizzo del piano in caso di interruzione per ripristinare le normali operazioni. I passaggi di implementazione principali includono quanto segue:
- Test e formazione iniziali: dopo aver documentato il BPC, testalo tramite simulazioni ed esercizi per identificare le lacune e migliorare l'efficacia. Forma i dipendenti sui loro ruoli e sulle loro responsabilità durante un'interruzione.
- Attivazione: quando si verifica un'interruzione, avvia il piano di risposta alle emergenze in base agli attivatori e alle procedure predefiniti.
- Comunicazione: tieni informati gli stakeholder sulla situazione e sugli sforzi di recupero.
Manutenzione e revisione
Questa fase non è un processo definito che si verifica una sola volta, ma rappresenta un impegno continuo che dovrebbe diventare una parte normale delle operazioni di CI/CD. È importante rivedere, testare e aggiornare regolarmente il piano di continuità aziendale all'interno della tua organizzazione in modo che rimanga pertinente e attuabile in caso di interruzione. I passaggi chiave della manutenzione e della revisione includono quanto segue:
- Aggiornamenti regolari: rivedi e aggiorna periodicamente il piano di risposta alle emergenze in modo che rimanga aggiornato ed efficace. Aggiornala ogni volta che si verificano cambiamenti nel personale, nella tecnologia o nei processi aziendali.
- Lezioni apprese: dopo ogni interruzione o test, svolgi un debriefing per identificare le lezioni apprese e le aree di miglioramento.
- Conformità alle normative: allinea il tuo piano di continuità aziendale alle normative e agli standard di settore.
- Sensibilizzazione dei dipendenti: informa continuamente i dipendenti sul BCP e sul loro ruolo nella sua esecuzione.
Crea un processo di continuità aziendale per CI/CD
Questa sezione fornisce linee guida specifiche per la creazione di un piano di continuità aziendale incentrato in modo specifico sul ripristino delle operazioni di CI/CD. Il processo di pianificazione della continuità aziendale per CI/CD inizia con una conoscenza approfondita della toolchain CI/CD e del suo collegamento al ciclo di vita delle operazioni e del distribuzione del software. Sulla base di queste informazioni, puoi pianificare in che modo la tua organizzazione recupererà le operazioni CI/CD dopo un'interruzione.
Per creare un processo di continuità aziendale solido per il processo CI/CD, devi svolgere i seguenti passaggi principali:
- Informazioni sulla toolchain
- Identifica i dati e le dipendenze
- Determinare i target RTO e RPO
- Scegliere una strategia di alto livello per la continuità aziendale
- Documenta il piano di continuità aziendale e implementa le best practice
- Testa gli scenari di errore e mantieni il piano
Le sezioni seguenti forniscono ulteriori dettagli su ciascuno di questi passaggi.
Informazioni sulla toolchain
Le toolchain CI/CD sono composte da molti singoli strumenti diversi e le possibili combinazioni di strumenti possono sembrare infinite. Tuttavia, comprendere la tua toolchain CI/CD e le relative dipendenze è fondamentale per la pianificazione della continuità aziendale per CI/CD. La missione principale del processo CI/CD è fornire il codice ai sistemi di produzione per l'utilizzo da parte degli utenti finali. Durante questo processo vengono utilizzati molti sistemi e origini dati diversi. È fondamentale conoscere queste origini dati e le relative dipendenze per sviluppare un piano di continuità aziendale. Per iniziare a creare la tua strategia di RE, devi prima conoscere i diversi strumenti coinvolti nel processo CI/CD.
Per aiutarti a capire come valutare la tua toolchain e sviluppare il tuo piano di continuità aziendale, questo documento utilizza l'esempio di un'applicazione Java aziendale in esecuzione su GKE. Il seguente diagramma mostra il primo livello di dati e sistemi nella toolchain. Questo primo livello è sotto il tuo diretto controllo e include quanto segue:
- La sorgente delle tue applicazioni
- Strumenti della tua piattaforma CI/CD, come Cloud Build o Cloud Deploy
- Interconnessioni di base dei diversi strumenti
Come mostrato nel diagramma, il flusso principale per l'applicazione di esempio è il seguente:
- Gli eventi di sviluppo del codice nel loop interno di sviluppo attivano Cloud Build.
- Cloud Build estrae il codice sorgente dell'applicazione dal repository di controllo del codice sorgente.
- Cloud Build identifica le eventuali dipendenze necessarie specificate nei file di configurazione di compilazione, ad esempio i file JAR di terze parti del repository Java in Artifact Registry. Cloud Build estrae quindi queste dipendenze dalle relative posizioni di origine.
- Cloud Build esegue la compilazione ed effettua la convalida necessaria, come l'analisi statica e i test delle unità.
- Se la compilazione è riuscita, Cloud Build crea l'immagine del contenitore e la esegue nel repository del contenitore in Artifact Registry.
- Viene attivata una pipeline Cloud Deploy che estrae l'immagine container dal repository e la esegue in un ambiente GKE.
Per comprendere gli strumenti utilizzati nel processo CI/CD, ti consigliamo di creare un diagramma che mostri il processo CI/CD e gli strumenti utilizzati, simile all'esempio in questo documento. Puoi quindi utilizzare il diagramma per creare una tabella che raccolga le informazioni chiave sulla tua toolchain CI/CD, ad esempio la fase del processo, lo scopo dello strumento, lo strumento stesso e i team che sono interessati da un errore dello strumento. Questa tabella fornisce una mappatura degli strumenti nella tua toolchain e li identifica con fasi specifiche del processo CI/CD. Pertanto, la tabella può aiutarti a ottenere una visione complessiva della tua toolchain e del suo funzionamento.
Le tabelle seguenti mappano l'esempio di un'applicazione aziendale citato in precedenza a ciascun strumento nel diagramma. Per fornire un esempio più completo di come potrebbe essere una mappatura della toolchain, queste tabelle includono anche altri strumenti non menzionati nel diagramma, come strumenti di sicurezza o di test.
La prima tabella mappa gli strumenti utilizzati nella fase CI del processo CI/CD:
| Integrazione continua | Origine | Strumenti utilizzati | Utenti principali | Utilizzo |
|---|---|---|---|---|
| Fase: controllo del codice sorgente |
|
|
|
|
| Fase: compilazione |
|
Sviluppatori |
|
|
| Fase: test |
|
Sviluppatori |
Esegui test di unità e di integrazione in una piattaforma on demand coerente. |
|
| Fase: sicurezza |
|
|
Esegui una scansione del codice per rilevare eventuali problemi di sicurezza. |
La seconda tabella si concentra sugli strumenti utilizzati nella fase di CD del processo CI/CD:
| Deployment continuo | Origine | Strumenti utilizzati | Utenti principali | Utilizzo |
|---|---|---|---|---|
| Fase: deployment | File di configurazione del deployment |
|
Automatizza i deployment per promuovere, approvare e gestire il traffico in una piattaforma sicura e coerente. |
|
| Fase: test |
|
|
Sviluppatori |
Testa l'integrazione e le prestazioni per verificarne la qualità e l'usabilità. |
| Fase: logging |
|
|
Conserva i log per l'osservabilità e la risoluzione dei problemi. |
|
| Fase: monitoraggio | Monitoraggio dei file di configurazione, tra cui:
|
|
|
|
Man mano che continui a lavorare al tuo piano di risposta alle emergenze e la tua conoscenza della toolchain CI/CD aumenta, puoi aggiornare il diagramma e la tabella di mappatura.
Identifica i dati e le dipendenze
Dopo aver completato l'inventario di base e la mappa della tua toolchain CI/CD, il passaggio successivo consiste nell'acquisire eventuali dipendenze da metadati o configurazioni. Quando implementi il piano di continuità aziendale, è fondamentale avere una comprensione chiara delle dipendenze all'interno della tua toolchain CI/CD. Le dipendenze in genere rientrano in una delle due categorie: dipendenze interne (di primo ordine) e dipendenze esterne (di secondo o terzo ordine).
Dipendenze interne
Le dipendenze interne sono i sistemi utilizzati dalla tua toolchain e di cui hai il controllo diretto. Anche le dipendenze interne vengono selezionate dai tuoi team. Questi sistemi includono lo strumento CI, il magazzino di gestione delle chiavi e il sistema di controllo del codice sorgente. Puoi considerare questi sistemi come appartenenti al livello successivo rispetto alla stessa toolchain.
Ad esempio, il seguente diagramma mostra un esempio di come le dipendenze interne si inseriscono in una toolchain. Il diagramma espande il precedente diagramma della toolchain di primo livello per l'applicazione Java di esempio in modo da includere anche le dipendenze interne della toolchain: le credenziali dell'applicazione, il file deploy.yaml e il file cloudbuild.yaml.
Il diagramma mostra che, per funzionare correttamente nell'applicazione Java di esempio, strumenti come Cloud Build, Cloud Deploy e GKE devono accedere a dipendenze non della toolchain come cloudbuild.yaml,deploy.yaml e le credenziali dell'applicazione. Quando analizzi la tua toolchain CI/CD, valuti se uno strumento può essere eseguito autonomamente o se deve chiamare un'altra risorsa.
Prendi in considerazione le dipendenze interne documentate per l'applicazione Java di esempio.
Le credenziali vengono archiviate in Secret Manager, che non fa parte della toolchain, ma sono necessarie per l'avvio dell'applicazione al momento del deployment. Pertanto, le credenziali dell'applicazione sono incluse come dipendenza per GKE. È inoltre importante includere i file deploy.yaml e
cloudbuild.yaml come dipendenze, anche se sono archiviati nel controllo
delle sorgenti con il codice dell'applicazione, perché definiscono la pipeline CI/CD per
l'applicazione.
Il piano di backup per l'applicazione Java di esempio deve tenere conto di queste dipendenze
nei file deploy.yaml e cloudbuild.yaml perché ricreano la
pipeline CI/CD dopo l'implementazione degli strumenti durante il processo di recupero.
Inoltre, se queste dipendenze vengono compromesse, la funzionalità complessiva della pipeline viene interessata anche se gli strumenti stessi sono ancora operativi.
Dipendenze esterne
Le dipendenze esterne sono sistemi esterni su cui si basa la tua toolchain per funzionare e non sono sotto il tuo controllo diretto. Le dipendenze esterne derivano dagli strumenti e dai framework di programmazione selezionati. Puoi considerare le dipendenze esterne come un altro livello sotto le dipendenze interne. Alcuni esempi di dipendenze esterne sono i repository npm o Maven e i servizi di monitoraggio.
Sebbene le dipendenze esterne non siano sotto il tuo controllo, puoi incorporarle nel tuo piano di continuità aziendale. Il seguente diagramma aggiorna l'applicazione Java di esempio includendo le dipendenze esterne oltre a quelle interne: le librerie Java in Maven Central e le immagini Docker in Docker Hub. Le librerie Java vengono utilizzate da Artifact Registry e le immagini Docker da Cloud Build.
Il diagramma mostra che le dipendenze esterne possono essere importanti per il processo CI/CD: sia Cloud Build che GKE si basano su due servizi esterni (Maven e Docker) per funzionare correttamente. Quando valuti la tua toolchain, documenta sia le dipendenze esterne a cui i tuoi strumenti devono accedere sia le procedure per gestire le interruzioni delle dipendenze.
Nell'esempio di applicazione Java, le librerie Java e le immagini Docker non possono essere controllate direttamente, ma puoi comunque includerle e le relative procedure di recupero nel piano di continuità aziendale. Ad esempio, considera le librerie Java in Maven. Sebbene le librerie siano archiviate in un'origine esterna, puoi stabilire un processo per scaricare e aggiornare periodicamente le librerie Java in un repository Maven o Artifact Registry locale. In questo modo, la procedura di recupero non deve basarsi sulla disponibilità dell'origine di terze parti.
Inoltre, è importante capire che le dipendenze esterne possono avere più di un livello. Ad esempio, puoi considerare i sistemi utilizzati dalle tue dipendenze interne come dipendenze di secondo ordine. Queste dipendenze di secondo ordine potrebbero avere dipendenze proprie, che puoi considerare come dipendenze di terzo ordine. Tieni presente che potresti dover documentare e tenere conto sia delle dipendenze esterne di secondo e terzo ordine nel tuo piano di continuità aziendale sia delle operazioni di recupero durante un'interruzione.
Determina gli obiettivi RTO e RPO
Dopo aver compreso la tua toolchain e le dipendenze, definisci i target RTO e RPO per i tuoi strumenti. Gli strumenti del processo CI/CD eseguono ciascuno un'azione diversa che può avere un impatto diverso sull'attività. Pertanto, è importante associare la priorità degli obiettivi RTO e RPO della funzione aziendale al suo impatto sull'attività. Ad esempio, la creazione di nuove versioni di applicazioni tramite la fase CI potrebbe avere un impatto minore rispetto al deployment delle applicazioni tramite la fase CD. Pertanto, gli strumenti di deployment potrebbero avere target RTO e RPO più lunghi rispetto ad altre funzioni.
Il seguente grafico a quattro quadranti è un esempio generale di come potresti determinare i target RTO e RPO per ogni componente della toolchain CI/CD. La toolchain mappata in questo grafico include strumenti come una pipeline IaC e origini dati di test. Gli strumenti non sono stati menzionati nei diagrammi precedenti per l'applicazione Java, ma sono inclusi qui per fornire un example più completo.
Il grafico mostra i quadranti in base al livello di impatto su sviluppatori e operazioni. Nel grafico, i componenti sono posizionati come segue:
- Impatto moderato sugli sviluppatori, impatto ridotto sulle operazioni: prova le origini dati
- Impatto moderato sugli sviluppatori, impatto moderato sulle operazioni: Cloud Key Management Service, Cloud KMS
- Impatto moderato sugli sviluppatori, impatto elevato sulle operazioni: pipeline di deployment
- Impatto elevato sugli sviluppatori, impatto ridotto sulle operazioni: loop interno di sviluppo
- Impatto elevato sugli sviluppatori, impatto moderato sulle operazioni: pipeline CI, pipeline Infrastructure as Code (IaC)
- Impatto elevato sugli sviluppatori e sulle operazioni: gestione del controllo del codice (SCM), Artifact Registry
Componenti come la gestione del controllo del codice sorgente e Artifact Registry, che hanno un impatto elevato sugli sviluppatori e sulle operazioni, hanno il maggiore impatto sull'attività. Questi componenti devono avere gli obiettivi RTO e RPO più bassi. I componenti in altri quadranti hanno una priorità inferiore, il che significa che gli obiettivi RTO e RPO saranno più elevati. In generale, gli obiettivi RTO e RPO per i componenti della toolchain devono essere impostati in base alla quantità di dati o configurazione che può essere tollerata rispetto al tempo necessario per ripristinare il servizio per quel componente.
Ad esempio, prendi in considerazione le diverse posizioni di Artifact Registry e della pipeline IaC nel grafico. Un confronto tra questi due strumenti mostra che un'interruzione di Artifact Registry ha un impatto maggiore sulle operazioni aziendali rispetto a un'interruzione nella pipeline IaC. Poiché un'interruzione di Artifact Registry influisce notevolmente sulla tua capacità di eseguire il deployment o la scalabilità automatica dell'applicazione, avrà obiettivi RTO e RPO inferiori rispetto ad altri strumenti. Al contrario, il grafico mostra che un'interruzione della pipeline IaC ha un impatto minore sulle operazioni aziendali rispetto ad altri strumenti. La pipeline IaC avrebbe quindi obiettivi RTO e RPO più elevati perché puoi utilizzare altri metodi per eseguire il deployment o l'aggiornamento dell'infrastruttura durante un'interruzione.
Scegli una strategia di alto livello per la continuità aziendale
I processi di continuità aziendale per le applicazioni di produzione si basano spesso su una delle tre strategie di ripristino di emergenza comuni. Tuttavia, per CI/CD puoi scegliere tra due strategie di alto livello per la continuità aziendale: attiva/passiva o backup/ripristino. La strategia che scegli dipende dai tuoi requisiti e dal tuo budget. Ogni strategia presenta dei compromessi in termini di complessità e costi e devi prendere in considerazione aspetti diversi per il processo CI/CD. Le sezioni seguenti forniscono maggiori dettagli su ciascuna strategia e sui relativi compromessi.
Inoltre, quando si verificano eventi che interrompono il servizio, potrebbero avere un impatto maggiore sull'implementazione di CI/CD. Devi anche considerare tutta l'infrastruttura necessaria, inclusa la rete, il calcolo e lo spazio di archiviazione. Devi avere un piano di RE per questi elementi di base e testarlo regolarmente per assicurarti che sia efficace.
Attivo/passivo
Con la strategia attiva/passiva (o in attesa attiva), le applicazioni e la pipeline CI/CD passiva sono mirror. Tuttavia, la pipeline passiva non gestisce effettivamente il carico di lavoro del cliente e qualsiasi compilazione o implementazione, pertanto è in uno stato ridotto. Questa strategia è più appropriata per le applicazioni di importanza critica per l'attività, dove è tollerabile un breve tempo di riposo.
Il seguente diagramma mostra una configurazione attiva/passiva per l'applicazione Java di esempio utilizzata in questo documento. La pipeline passiva duplica completamente la toolchain dell'applicazione in un'altra regione.
In questo esempio, la regione 1 ospita la pipeline CI/CD attiva e la regione 2 ha la controparte passiva. Il codice è ospitato su un provider di servizi Git esterno, come GitHub o GitLab. Un evento del repository (ad esempio l'unione da una richiesta di pull) può attivare la pipeline CI/CD nella regione 1 per eseguire la compilazione, i test e il deployment nell'ambiente di produzione multiregionale.
Se si verifica un problema critico per la pipeline della regione 1, ad esempio un'interruzione regionale di un prodotto, il risultato potrebbe essere implementazioni o build non riuscite. Per risolvere rapidamente il problema, puoi aggiornare l'attivatore per il repository Git e passare alla pipeline region2, che diventa quella attiva. Una volta risolto il problema nella regione1, puoi mantenere la pipeline nella regione1 in stato passivo.
I vantaggi della strategia attiva/passiva includono:
- Tempo di riposo ridotto: poiché la pipeline passiva è stata dispiattata, ma è stata ridotta, il tempo di riposo è limitato al tempo necessario per eseguire lo scale up della pipeline.
- Tolleranza configurabile per la perdita di dati: con questa strategia, la configurazione e l'elemento devono essere sincronizzati periodicamente. Tuttavia, l'importo è configurabile in base ai tuoi requisiti, il che può ridurre la complessità.
I principali svantaggi di questa strategia sono:
- Costo: con un'infrastruttura duplicata, questa strategia aumenta il costo complessivo dell'infrastruttura CI/CD.
Backup/ripristino
Con la strategia di backup/ripristino, crei la pipeline di failover solo se necessaria durante il recupero degli incidenti. Questa strategia è più appropriata per i casi d'uso con priorità inferiore. Il seguente diagramma mostra una configurazione di backup/ripristino per l'applicazione Java di esempio. La configurazione di backup duplica solo parte della pipeline CI/CD dell'applicazione in un'altra regione.
Come nell'esempio precedente, la regione1 ospita la pipeline CI/CD attiva. Invece di avere una pipeline passiva nella regione 2, questa contiene solo i backup dei dati regionali necessari, come i pacchetti Maven e le immagini container. Se ospiti i tuoi repository di origine nella regione 1, devi anche sincronizzare i dati con le località di RE.
Analogamente, se si verifica un problema critico nella pipeline della regione 1, ad esempio un'interruzione del prodotto a livello di regione, puoi ripristinare l'implementazione CI/CD nella regione 2. Se il codice dell'infrastruttura è archiviato nel repository del codice dell'infrastruttura, puoi eseguire lo script di automazione dal repository e ricreare la pipeline CI/CD nella regione 2.
Se l'interruzione del servizio è un evento su larga scala, potresti dover competere con altri clienti per le risorse cloud. Un modo per mitigare questa situazione è avere più opzioni per la località di RE. Ad esempio, se la pipeline della regione 1 si trova in us-east1,
la regione di failover può essere us-east4, us-central1 o us-west1.
I vantaggi della strategia di backup/ripristino includono:
- Costo: questa strategia comporta il costo più basso perché esegui il deployment della pipeline di backup solo durante gli scenari di RE.
I principali svantaggi di questa strategia sono:
- Tempo di riposo: questa strategia richiede più tempo per l'implementazione perché crei la pipeline di failover quando ti serve. Invece di avere una pipeline predefinita, i servizi devono essere creati e configurati durante il recupero degli incidenti. Anche il tempo di compilazione degli elementi e il tempo per recuperare le dipendenze esterne potrebbero essere notevolmente più lunghi.
Documenta il BCP e implementa le best practice
Dopo aver mappato la tua toolchain CI/CD, identificato le relative dipendenze e determinato gli obiettivi RTO e RPO per le funzioni critiche, il passaggio successivo consiste nel documentare tutte le informazioni pertinenti in un piano di continuità aziendale scritto. Quando crei il tuo piano di continuità aziendale, documenta le strategie, le procedure e le procedure per il ripristino di ogni funzione critica. Questa procedura di documentazione include la scrittura di procedure dettagliate da seguire per i dipendenti con ruoli specifici durante un'interruzione.
Dopo aver definito il piano di continuità aziendale, esegui il deployment o l'aggiornamento della suite di strumenti CI/CD utilizzando le best practice per raggiungere i target RTO e RPO. Sebbene le toolchain CI/CD possano essere molto diverse, due pattern chiave per le best practice sono comuni indipendentemente dalla toolchain: una comprensione completa delle dipendenze e l'implementazione dell'automazione.
Per quanto riguarda le dipendenze, la maggior parte dei BCP si occupa dei sistemi direttamente sotto il tuo controllo. Tuttavia, ricorda che le dipendenze esterne di secondo o terzo ordine potrebbero avere un impatto altrettanto significativo, pertanto è importante implementare best practice e misure di ridondanza anche per queste dipendenze critiche. Le librerie Java esterne nell'applicazione di esempio sono un esempio di dipendenze di terzo ordine. Se non hai un repository locale o un backup per queste librerie, potresti non riuscire a compilare l'applicazione se l'origine esterna da cui estrai le librerie è disconnessa.
In termini di automazione, l'implementazione delle best practice deve essere integrata nella strategia IaC cloud complessiva. La soluzione IaC deve utilizzare strumenti come Terraform per eseguire automaticamente il provisioning delle risorse necessarie per l'implementazione CI/CD e per configurare le procedure. Le pratiche IaC sono procedure di ripristino molto efficaci perché sono incorporate nel funzionamento quotidiano delle pipeline CI/CD. Inoltre, l'IaC favorisce l'archiviazione dei file di configurazione nel controllo del codice sorgente, che a sua volta favorisce l'adozione delle best practice per i backup.
Dopo aver implementato la toolchain in base al piano di continuità aziendale e alle best practice per dipendenze e automazione, il processo CI/CD e le strategie di recupero potrebbero cambiare. Assicurati di documentare eventuali modifiche alle strategie, ai processi e alle procedure di recupero derivanti dalla revisione del BCP e dall'implementazione delle best practice.
Testare gli scenari di errore e gestire il piano
È fondamentale esaminare, testare e aggiornare regolarmente il piano di continuità aziendale. Il test del piano di continuità aziendale e delle procedure di recupero verifica che il piano sia ancora valido e che gli obiettivi RPO e RTO documentati siano accettabili. Tuttavia, il più importante è che i test, gli aggiornamenti e la manutenzione regolari rendono l'esecuzione del piano di risposta alle emergenze parte delle normali operazioni. Con Google Cloud, puoi testare scenari di recupero a un costo minimo. Per facilitare i test, ti consigliamo di procedere come segue:
- Automatizza il provisioning dell'infrastruttura con uno strumento IaC: puoi utilizzare strumenti come Terraform per automatizzare il provisioning dell'infrastruttura CI/CD.
- Monitora e esegui il debug dei test con Cloud Logging e Cloud Monitoring: l'osservabilità di Google Cloud fornisce strumenti di logging e monitoraggio a cui puoi accedere tramite chiamate API, il che significa che puoi automatizzare il deployment di scenari di recupero reagendo alle metriche. Quando progetti i test, assicurati di disporre di un sistema di monitoraggio e di invio di avvisi adeguato che possa attivare azioni di recupero appropriate.
- Esegui i test nel piano di risposta ai disastri: ad esempio, puoi verificare se le autorizzazioni e l'accesso utente funzionano nell'ambiente di RE come nell'ambiente di produzione. Puoi eseguire test di integrazione e funzionali nel tuo ambiente di RE. Puoi anche eseguire un test in cui il percorso di accesso abituale a Google Cloud non funziona.
In Google, testiamo regolarmente il nostro piano di continuità aziendale tramite una procedura chiamata DiRT (Disaster Recovery Testing). Questi test aiutano Google a verificare gli impatti, l'automazione ed esporre i rischi non considerati. Le modifiche all'automazione e al piano di risposta alle emergenze che devono essere implementate sono un output importante di DiRT.
Best practice
In questa sezione scoprirai alcune best practice che puoi implementare per ottenere i tuoi obiettivi RTO e RPO. Queste best practice si applicano in generale al RE per CI/CD e non a strumenti specifici. Indipendentemente dall'implementazione, devi testare regolarmente il piano di risposta ai disastri per assicurarti che l'alta disponibilità, il RTO e il RPO soddisfino i tuoi requisiti. In caso di incidente o disastro, devi anche eseguire un'analisi di ciò che è successo e analizzare la procedura per poterla migliorare.
Alta disponibilità
Per ogni strumento, devi cercare di implementare le best practice per la disponibilità elevata. Seguire le best practice per l'alta disponibilità consente di adottare un approccio più proattivo per il processo CI/CD, in quanto queste pratiche rendono il processo più resiliente agli errori. Queste strategie proattive devono essere utilizzate con procedure e controlli più reattivi sia per il recupero che per il backup.
Di seguito sono riportate alcune best practice per ottenere un'alta disponibilità. Tuttavia, consulta la documentazione dettagliata di ogni strumento nel tuo CI/CD per le best practice più dettagliate:
- Servizi gestiti: l'utilizzo dei servizi gestiti trasferisce la responsabilità operativa a Google Cloud.
- Scalabilità automatica: se possibile, utilizza la scalabilità automatica. Un aspetto fondamentale della scalabilità automatica è che le istanze di lavoro vengono create in modo dinamico, quindi il recupero dei nodi in stato di errore è automatico.
- Deployment a livello globale e multiregionale: se possibile, utilizza i deployment a livello globale e multiregionale anziché il deployment a livello di regione. Ad esempio, puoi configurare Artifact Registry per l'archiviazione multi-regione.
- Dipendenze: comprendi tutte le dipendenze del tuo set di strumenti e assicurati che siano ad alta disponibilità. Ad esempio, puoi memorizzare nella cache tutte le librerie di terze parti nel registry degli elementi.
Procedure di backup
Quando implementi il DR per CI/CD, alcuni strumenti e processi sono più adatti alle strategie di backup/ripristino. Una strategia di backup completa è il primo passo per controlli reattivi efficaci. I backup ti consentono di recuperare la pipeline CI/CD con un'interruzione minima in caso di malintenzionati o scenari di emergenza.
Come punto di partenza, ti consigliamo di implementare le tre best practice riportate di seguito. Tuttavia, per best practice più dettagliate sul backup, consulta la documentazione di ogni strumento nel processo CI/CD.
- Controllo del codice sorgente: memorizza i file di configurazione e tutto ciò che codifichi, ad esempio script e criteri di automazione, nel controllo del codice sorgente. Alcuni esempi sono
cloudbuild.yamle i file YAML di Kubernetes. - Riduzione: assicurati che non esista un singolo punto di errore per quanto riguarda l'accesso ai secret come password, certificati e chiavi API. Alcuni esempi di pratiche da evitare sono: una sola persona che conosce la password o la memorizzazione della chiave API su un solo server in una determinata regione.
- Backup: verifica spesso la completezza e l'accuratezza dei backup. I servizi gestiti come Backup per GKE ti aiuteranno a semplificare la procedura di verifica.
Procedure di recupero
RE richiede anche procedure di ripristino per integrare le procedure di backup. Le tue procedure di recupero, combinate con i backup completi, determineranno la rapidità con cui potrai rispondere agli scenari di emergenza.
Gestione delle dipendenze
La pipeline CI/CD può avere molte dipendenze, che possono anche essere fonti di errori. Un elenco completo delle dipendenze deve essere identificato come descritto in precedenza in questo documento nella sezione Identificare dati e dipendenze. Tuttavia, le due fonti di dipendenze più comuni sono le seguenti:
- Elementi dell'applicazione: ad esempio pacchetti, librerie e immagini
- Sistemi esterni: ad esempio, sistemi di gestione delle richieste e di notifica
Un modo per ridurre i rischi delle dipendenze è adottare la pratica del vendoring. La rivendita di pacchetti o immagini di applicazioni è il processo di creazione e archiviazione di copie in un repository privato. Il vendoring rimuove la dipendenza da fonti esterne per questi pacchetti o immagini e può anche contribuire a impedire l'inserimento di malware nella catena di fornitura del software.
Ecco alcuni vantaggi della vendita di pacchetti o immagini di applicazioni:
- Sicurezza: il vendoring rimuove la dipendenza da origini esterne per i pacchetti o le immagini delle applicazioni, il che può contribuire a prevenire gli attacchi di inserimento di malware.
- Controllo: vendendo i propri pacchetti o le proprie immagini, le organizzazioni possono avere un maggiore controllo sull'origine di questi pacchetti e immagini.
- Conformità: il vendoring può aiutare le organizzazioni a rispettare le normative del settore, come la certificazione Cybersecurity Maturity Model.
Se il tuo team decide di utilizzare pacchetti o immagini dell'applicazione del fornitore, segui questi passaggi principali:
- Identifica i pacchetti o le immagini dell'applicazione che devono essere forniti dal fornitore.
- Crea un repository privato per archiviare i pacchetti o le immagini del fornitore.
- Scarica i pacchetti o le immagini dall'origine originale e archiviali nel repository privato.
- Verifica l'integrità dei pacchetti o delle immagini.
- Aggiorna i pacchetti o le immagini del fornitore, se necessario.
Le pipeline CI/CD spesso chiamano sistemi di terze parti per eseguire azioni come eseguire scansioni, registrare ticket o inviare notifiche. Nella maggior parte dei casi, questi sistemi di terze parti hanno le proprie strategie di RE che devono essere implementate. Tuttavia, in alcuni casi potrebbero non avere un piano di RE adatto e queste situazioni devono essere documentate chiaramente nel BCP. Devi quindi decidere se questi livelli della pipeline possono essere ignorati per motivi di disponibilità o se è accettabile causare un tempo di riposo della pipeline CI/CD.
Monitoraggio e notifiche
Il tuo CI/CD è come i sistemi di produzione delle applicazioni, quindi devi anche implementare tecniche di monitoraggio e notifica per i tuoi strumenti CI/CD. Come best practice, consigliamo di implementare dashboard e notifiche di avviso. Il repository di esempio GitHub per Cloud Monitoring contiene molti esempi di dashboard e criteri di avviso.
Puoi anche implementare livelli di monitoraggio aggiuntivi, come gli indicatori del livello di servizio (SLI) e gli obiettivi del livello di servizio (SLO). Questi livelli di monitoraggio aiutano a monitorare l'integrità e le prestazioni complessive delle pipeline CI/CD. Ad esempio, è possibile implementare gli SLO per monitorare la latenza delle fasi di compilazione e deployment. Questi SLO aiutano i team a creare e rilasciare le applicazioni con la velocità e la frequenza che preferisci.
Procedure di accesso di emergenza
Durante un disastro, potrebbe essere necessario che i team operativi agiscano al di fuori delle procedure standard e ottengano l'accesso di emergenza a sistemi e strumenti. Queste azioni di emergenza sono a volte chiamate procedure di emergenza. Come punto di partenza, ti consigliamo di implementare queste tre best practice:
- Avere un piano e una procedura di riassegnazione chiari. Un piano chiaro aiuta il team operativo a sapere quando deve utilizzare le procedure di accesso di emergenza.
- Assicurati che più persone abbiano accesso a informazioni importanti, come la configurazione e i secret.
- Sviluppare metodi di controllo automatizzati, in modo da poter monitorare quando sono state utilizzate le procedure di accesso di emergenza e chi le ha utilizzate.
Passaggi successivi
- Scopri di più sui prodotti Google Cloud utilizzati in questo documento:
- Consulta la guida alla pianificazione del ripristino di emergenza.
- Prova altre funzionalità di Google Cloud completando i nostri tutorial.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.
Collaboratori
Autori:
- Ben Good | Solutions Architect
- Xiang Shen | Solutions Architect
Altri collaboratori:
- Marco Ferrari | Cloud Solutions Architect
- Anuradha Bajpai | Solution Architect
- Rodd Zurcher | Solutions Architect