Questo documento descrive il recupero di emergenza (RE) e la pianificazione della continuità aziendale nel contesto dell'integrazione continua e della distribuzione continua (CI/CD). Fornisce inoltre indicazioni su come identificare e mitigare le dipendenze quando sviluppi un piano di continuità aziendale (BCP) completo. Il documento include best practice che puoi applicare al tuo piano di continuità operativa, indipendentemente dagli strumenti e dai processi che utilizzi. Il documento presuppone che tu conosca le basi 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 l'infrastruttura dell'applicazione, il processo CI/CD richiede una pianificazione per RE e la continuità aziendale. Quando pensi al RE e alla continuità operativa per CI/CD, è importante comprendere ogni fase del ciclo di distribuzione e operazioni del software e capire come funzionano insieme come processo olistico.
Il seguente diagramma è una visualizzazione semplificata del ciclo di sviluppo e operazioni del software, che include le seguenti tre fasi:
- Ciclo interno di sviluppo: codifica, prova e commit
- Integrazione continua: build, 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 sviluppo e operazioni del software.
Durante il ciclo di sviluppo e operazioni del software, devi considerare l'impatto di un disastro sulla capacità dei team di operare e gestire le applicazioni mission critical. In questo modo, potrai determinare il Recovery Time Objective (RTO) e il Recovery Point Objective (RPO) per gli strumenti nella tua toolchain CI/CD.
Inoltre, la maggior parte delle organizzazioni dispone di molte pipeline CI/CD diverse per diverse applicazioni e insiemi di infrastrutture e ogni pipeline ha requisiti unici peREza e la pianificazione della continuità aziendale. La strategia di recupero che scegli per una pipeline varia in base all'RTO e all'RPO dei tuoi strumenti. Ad esempio, alcune pipeline sono più critiche di altre e avranno requisiti RTO e RPO inferiori. È importante identificare le pipeline business-critical nel tuo BCP, che devono ricevere maggiore attenzione quando implementi le best practice per testare ed eseguire le procedure di ripristino.
Poiché ogni processo CI/CD e la relativa toolchain sono diversi, gli obiettivi di questa guida sono aiutarti a identificare i singoli punti di errore nel processo CI/CD e sviluppare un piano di continuità operativa completo. Le sezioni seguenti ti aiutano a:
- Comprendi cosa serve per eseguire il ripristino da un evento di RE che influisce sul processo CI/CD.
- Determina l'RTO e l'RPO per gli strumenti nel processo CI/CD.
- Comprendere le modalità di errore e le dipendenze del processo CI/CD.
- Scegli una strategia di recupero appropriata per gli strumenti nella tua toolchain.
- Comprendere le best practice generali per l'implementazione di un piano di ripristino di emergenza per il processo CI/CD.
Informazioni sulla procedura di continuità operativa
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 normali operazioni per il processo CI/CD.
Le sezioni seguenti descrivono le fasi di alto livello che includono i passaggi coinvolti nella creazione di un piano di continuità operativa efficace. Sebbene molti di questi passaggi si applichino in generale alla gestione dei programmi 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 di questo documento.
Inizio e pianificazione
In questa fase iniziale, i team tecnici e aziendali collaborano per stabilire le basi per il processo di pianificazione della continuità aziendale e la sua manutenzione continua. I passaggi chiave di questa fase includono:
- Consenso della leadership: assicurati che il senior 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 sviluppare e implementare il piano di continuità operativa.
- Scopo e obiettivi: definisci lo scopo del tuo BCP e i suoi obiettivi. Determina quali processi aziendali sono critici 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 sicurezza informatica 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.
Business impact analysis
In questa fase, i team aziendali e tecnici analizzano l'impatto aziendale delle interruzioni per i tuoi clienti e la tua organizzazione e danno la priorità al ripristino delle funzioni aziendali critiche. Queste funzioni aziendali vengono eseguite da strumenti diversi durante le varie fasi di un processo di build e deployment.
L'analisi dell'impatto sull'attività è una fase importante del processo di pianificazione della continuità operativa per CI/CD, in particolare i passaggi per identificare le funzioni aziendali critiche e le dipendenze dagli strumenti. Inoltre, la comprensione della toolchain CI/CD, incluse le sue dipendenze e il suo funzionamento all'interno del ciclo di vita DevOps, è un elemento fondamentale per lo sviluppo di un BCP per il processo CI/CD.
I passaggi chiave della fase di analisi dell'impatto sull'attività includono:
- Funzioni critiche: determina le funzioni e i processi aziendali chiave a cui deve essere data la priorità per il recupero. Ad esempio, se determini che il deployment delle applicazioni è più critico dell'esecuzione di test unitari, dai la priorità al ripristino per i processi e gli strumenti di deployment delle applicazioni.
- Dipendenze: identifica le dipendenze interne ed esterne che potrebbero influire sul recupero delle tue funzioni critiche. Le dipendenze sono particolarmente importanti per garantire il funzionamento continuo del processo CI/CD tramite la sua toolchain.
- RTO e RPO: definisci limiti accettabili per i limiti di downtime e perdita di dati per ogni funzione critica. Questi target RTO e RPO sono collegati all'importanza di una funzione aziendale per la continuità delle operazioni e coinvolgono strumenti specifici necessari per il corretto funzionamento 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 una parte fondamentale della pianificazione della continuità aziendale per il processo CI/CD, in particolare il passaggio di selezione delle strategie di ripristino di alto livello per le funzioni critiche.
I passaggi chiave della 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.
- Rapporti con fornitori e fornitori: stabilisci piani di comunicazione e coordinamento con fornitori e fornitori chiave per mantenere la catena di fornitura in funzione durante le interruzioni.
- Recupero di dati e IT: crea piani per il backup dei dati, il recupero del sistema IT e misure di sicurezza informatica.
- 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 BCP. Il team tecnico documenta gli strumenti, i processi, le strategie di ripristino, la logica e le procedure per ogni funzione critica. Lo sviluppo del piano include anche la stesura di istruzioni passo passo che i dipendenti devono seguire durante un'interruzione. Durante l'implementazione e la manutenzione continua, potrebbe essere necessario apportare modifiche al piano, che deve essere trattato come 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 il test iniziale del BCP. L'implementazione include anche l'utilizzo del piano in caso di interruzione per ripristinare le normali operazioni. I passaggi chiave per l'implementazione 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 responsabilità durante un'interruzione.
- Attivazione: quando si verifica un'interruzione, avvia il BCP in base agli attivatori e alle procedure predefiniti.
- Comunicazione: tieni informate le parti interessate sulla situazione e sulle iniziative di recupero.
Manutenzione e revisione
Questa fase non è un processo definito che si verifica una sola volta, ma rappresenta uno sforzo continuo e costante che dovrebbe diventare una parte normale delle tue operazioni CI/CD. È importante rivedere, testare e aggiornare regolarmente il BCP all'interno dell'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 BCP in modo che rimanga attuale ed efficace. Aggiornalo ogni volta che si verificano cambiamenti nel personale, nella tecnologia o nei processi aziendali.
- Lezioni apprese: dopo ogni interruzione o test, esegui un debriefing per identificare le lezioni apprese e le aree di miglioramento.
- Conformità normativa: allinea il tuo piano di continuità operativa alle normative e agli standard di settore.
- Consapevolezza dei dipendenti: istruire continuamente i dipendenti sul BCP e sui loro ruoli nella sua esecuzione.
Crea un processo di continuità aziendale per CI/CD
Questa sezione fornisce linee guida specifiche per la creazione di un BCP incentrato in modo specifico sul ripristino delle operazioni CI/CD. Il processo di pianificazione della continuità operativa per CI/CD inizia con una comprensione approfondita della toolchain CI/CD e del modo in cui si integra nel ciclo di vita di distribuzione e operazioni del software. Con questa comprensione come base, puoi quindi pianificare il modo in cui la tua organizzazione ripristinerà le operazioni CI/CD in seguito a un'interruzione.
Per creare un processo di business continuity solido per il tuo processo CI/CD, devi seguire i seguenti passaggi principali:
- Informazioni sulla toolchain
- Identificare dati e dipendenze
- Determinare gli RTO e RPO target
- Scegli una strategia di alto livello per la continuità aziendale
- Documentare il piano di continuità operativa e implementare le best practice
- Scenari di test non riusciti e manutenzione del piano
Le sezioni seguenti forniscono maggiori dettagli su ciascuno di questi passaggi.
Comprendere la toolchain
Le toolchain CI/CD sono composte da molti strumenti individuali diversi e le possibili combinazioni di strumenti possono sembrare infinite. Tuttavia, comprendere la 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 codice ai sistemi di produzione per il consumo degli utenti finali. Durante questo processo, vengono utilizzati molti sistemi e origini dati diversi; conoscere queste origini dati e dipendenze è fondamentale per sviluppare un BCP. Per iniziare a creare la tua strategia di RE, devi prima comprendere i diversi strumenti coinvolti nel processo CI/CD.
Per aiutarti a capire come valutare la tua toolchain e sviluppare il tuo BCP, questo documento utilizza l'esempio di un'applicazione Java aziendale eseguita su GKE. Il seguente diagramma mostra il primo livello di dati e sistemi nella toolchain. Questo primo livello è sotto il tuo controllo diretto e include:
- L'origine delle tue applicazioni
- Strumenti nella piattaforma CI/CD, come Cloud Build o Cloud Deploy
- Interconnessioni di base dei diversi strumenti
Come mostrato nel diagramma, il flusso principale dell'applicazione di esempio è il seguente:
- Gli eventi di sviluppo del codice nel trigger del 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 dipendenze necessarie specificate nei file di configurazione della build, ad esempio i file JAR di terze parti dal repository Java in Artifact Registry. Cloud Build estrae quindi queste dipendenze dalle loro posizioni di origine.
- Cloud Build esegue la build ed esegue la convalida necessaria, come l'analisi statica e il test delle unità.
- Se la build ha esito positivo, Cloud Build crea l'immagine container e ne esegue il push nel repository di container in Artifact Registry.
- Viene attivata una pipeline di Cloud Deploy, che estrae l'immagine container dal repository e la esegue il deployment 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 acquisisca le informazioni chiave sulla toolchain CI/CD, ad esempio la fase del processo, lo scopo dello strumento, lo strumento stesso e i team interessati da un errore dello strumento. Questa tabella fornisce una mappatura degli strumenti nella tua toolchain e identifica gli strumenti con fasi specifiche del processo CI/CD. Pertanto, la tabella può aiutarti a ottenere una visione d'insieme della tua toolchain e del suo funzionamento.
Le tabelle seguenti mappano l'esempio menzionato in precedenza di un'applicazione aziendale a ogni strumento nel diagramma. Per fornire un esempio più completo di come potrebbe apparire una mappatura della toolchain, queste tabelle includono anche altri strumenti non menzionati nel diagramma, come strumenti di sicurezza o di test.
La prima tabella corrisponde agli strumenti utilizzati nella fase CI del processo CI/CD:
| Integrazione continua | Origine | Strumenti utilizzati | Utenti principali | Utilizzo |
|---|---|---|---|---|
| Fase: controllo del codice sorgente |
|
|
|
|
| Fase: build |
|
Sviluppatori |
|
|
| Fase: test |
|
Sviluppatori |
Esegui test delle unità e di integrazione in una piattaforma coerente e on demand. |
|
| Fase: sicurezza |
|
|
Scansiona il codice per verificare se ci sono problemi di sicurezza. |
La seconda tabella si concentra sugli strumenti utilizzati nella fase 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 qualità e 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 BCP e la tua comprensione della toolchain CI/CD aumenta, puoi aggiornare il diagramma e la tabella di mappatura.
Identifica dati e dipendenze
Dopo aver completato l'inventario di base e la mappatura della toolchain CI/CD, il passaggio successivo consiste nell'acquisire eventuali dipendenze da metadati o configurazioni. Quando implementi il tuo BCP, è fondamentale che tu abbia una chiara comprensione delle dipendenze all'interno della 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 sistemi utilizzati dalla toolchain e che controlli direttamente. Anche le dipendenze interne vengono selezionate dai tuoi team. Questi sistemi includono lo strumento CI, l'archivio di gestione delle chiavi e il sistema di controllo del codice sorgente. Puoi considerare questi sistemi come il livello successivo della toolchain.
Ad esempio, il seguente diagramma mostra un esempio di come le dipendenze interne
si inseriscono in una toolchain. Il diagramma si basa sul precedente diagramma della toolchain di primo livello per l'applicazione Java di esempio per 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 toolchain come cloudbuild.yaml,deploy.yaml e 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.
Considera 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 durante
il deployment. Pertanto, le credenziali dell'applicazione sono incluse come dipendenza per
GKE. È anche importante includere i file deploy.yaml e
cloudbuild.yaml come dipendenze, anche se sono archiviati nel controllo
del codice sorgente con il codice dell'applicazione, perché definiscono la pipeline CI/CD per
quell'applicazione.
Il BCP per l'applicazione Java di esempio deve tenere conto di queste dipendenze
dai file deploy.yaml e cloudbuild.yaml perché ricreano la
pipeline CI/CD dopo che gli strumenti sono stati installati durante la procedura di ripristino.
Inoltre, se queste dipendenze vengono compromesse, la funzionalità complessiva della pipeline ne risentirà anche se gli strumenti stessi sono ancora operativi.
Dipendenze esterne
Le dipendenze esterne sono sistemi esterni da cui dipende la tua toolchain per funzionare e non sono sotto il tuo controllo diretto. Le dipendenze esterne derivano dagli strumenti e dai framework di programmazione che hai selezionato. Puoi considerare le dipendenze esterne come un livello inferiore rispetto a quelle interne. Esempi di dipendenze esterne includono repository npm o Maven e servizi di monitoraggio.
Sebbene le dipendenze esterne siano al di fuori del tuo controllo, puoi incorporarle nel tuo piano di continuità operativa. Il seguente diagramma aggiorna l'applicazione Java di esempio includendo dipendenze esterne oltre a quelle interne: librerie Java in Maven Central e 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 la gestione delle interruzioni delle dipendenze.
Nell'applicazione Java di esempio, le librerie Java e le immagini Docker non possono essere controllate direttamente, ma puoi comunque includerle e le relative procedure di ripristino nel BCP. Ad esempio, considera le librerie Java in Maven. Sebbene le librerie siano archiviate su un'origine esterna, puoi stabilire un processo per scaricare e aggiornare periodicamente le librerie Java in un repository Maven locale o in Artifact Registry. In questo modo, la procedura di recupero non deve fare affidamento sulla disponibilità della sorgente di terze parti.
Inoltre, è importante capire che le dipendenze esterne possono avere più di un livello. Ad esempio, puoi considerare i sistemi utilizzati dalle dipendenze interne come dipendenze di secondo ordine. Queste dipendenze di secondo ordine potrebbero avere le proprie dipendenze, che puoi considerare come dipendenze di terzo ordine. Tieni presente che potrebbe essere necessario documentare e contabilizzare le dipendenze esterne di secondo e terzo ordine nel tuo BCP per recuperare le operazioni durante un'interruzione.
Determinare gli obiettivi RTO e RPO
Dopo aver compreso la toolchain e le dipendenze, definisci gli obiettivi RTO e RPO per i tuoi strumenti. Gli strumenti nel processo CI/CD eseguono ciascuno un'azione diversa che può avere un impatto diverso sull'attività. Pertanto, è importante abbinare la priorità degli obiettivi RTO e RPO della funzione aziendale al suo impatto sull'attività. Ad esempio, la creazione di nuove versioni delle 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 RTO e RPO più lunghi rispetto ad altre funzioni.
Il seguente grafico a quattro quadranti è un esempio generale di come potresti determinare gli obiettivi 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 esempio 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 basso sulle operazioni: origini dati di test
- 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, impatto elevato sulle operazioni: gestione del controllo della sorgente (SCM), Artifact Registry
Componenti come la gestione del controllo del codice sorgente e Artifact Registry, che hanno un impatto elevato su sviluppatori e operazioni, hanno il maggiore impatto sull'attività. Questi componenti devono avere gli obiettivi RTO e RPO più bassi. I componenti negli 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 alla perdita di configurazione che può essere tollerata rispetto al tempo necessario per ripristinare il servizio per quel componente.
Ad esempio, considera 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 in modo significativo sulla tua capacità di eseguire il deployment o la scalabilità automatica dell'applicazione, avrebbe target RTO e RPO inferiori rispetto ad altri strumenti. Al contrario, il grafico mostra che l'interruzione di una 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 aggiornare l'infrastruttura durante un'interruzione.
Scegliere una strategia di alto livello per la continuità operativa
I processi di continuità aziendale per le applicazioni di produzione spesso si basano su una delle tre strategie di ripristino di emergenza comuni. Tuttavia, per CI/CD, puoi scegliere tra due strategie di alto livello per la business continuity: attivo/passivo o backup/ripristino. La strategia che scegli dipende dai tuoi requisiti e dal tuo budget. Ogni strategia presenta compromessi in termini di complessità e costi e devi tenere in considerazione diversi aspetti 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 influire su più elementi della tua implementazione CI/CD. Devi anche considerare tutta l'infrastruttura di cui hai bisogno, inclusi rete, computing e archiviazione. Devi disporre di un piano di RE per questi componenti di base e testarlo regolarmente per assicurarti che sia efficace.
Attivo/passivo
Con la strategia attivo/passivo (o standby caldo), le applicazioni e la pipeline CI/CD passiva sono identiche. Tuttavia, la pipeline passiva non gestisce il workload del cliente e qualsiasi build o deployment, quindi si trova in uno stato ridotto. Questa strategia è più adatta per applicazioni business-critical in cui è tollerabile un breve periodo di inattività.
Il seguente diagramma mostra una configurazione attivo/passivo 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, region1 ospita la pipeline CI/CD attiva e region2 ha la controparte passiva. Il codice è ospitato su un provider di servizi Git esterno, come GitHub o GitLab. Un evento del repository (come l'unione da una richiesta di pull) può attivare la pipeline CI/CD nella regione 1 per creare, testare ed eseguire il deployment nell'ambiente di produzione multiregionale.
Se si verifica un problema critico per la pipeline region1, ad esempio un'interruzione a livello regionale di un prodotto, il risultato potrebbe essere un deployment non riuscito o build senza esito positivo. Per risolvere rapidamente il problema, puoi aggiornare il trigger per il repository Git e passare alla pipeline region2, che diventerà quella attiva. Una volta risolto il problema nella regione 1, puoi mantenere la pipeline nella regione 1 come passiva.
I vantaggi della strategia attiva/passiva includono:
- Tempi di inattività ridotti: poiché la pipeline passiva è stata implementata ma è ridimensionata, il tempo di inattività è limitato al tempo necessario per scalare la pipeline.
- Tolleranza configurabile per la perdita di dati: con questa strategia, la configurazione e l'artefatto devono essere sincronizzati periodicamente. Tuttavia, l'importo è configurabile in base ai tuoi requisiti, il che può ridurre la complessità.
Gli svantaggi di questa strategia includono:
- Costo: con l'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 quando è necessario durante il ripristino dell'incidente. Questa strategia è più adatta ai casi d'uso a priorità più bassa. 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, region1 ospita la pipeline CI/CD attiva. Anziché avere una pipeline passiva nella regione 2, quest'ultima contiene solo backup dei dati regionali necessari, come i pacchetti Maven e le immagini container. Se ospiti i repository di origine nella regione 1, devi anche sincronizzare i dati con le tue posizionREza.
Allo stesso modo, se si verifica un problema critico nella pipeline region1, ad esempio un'interruzione del prodotto a livello regionale, puoi ripristinare l'implementazione CI/CD in region2. Se il codice dell'infrastruttura è archiviato nel repository del codice dell'infrastruttura, puoi eseguire lo script di automazione dal repository e ricompilare la pipeline CI/CD nella regione 2.
Se l'interruzione è un evento su larga scala, potresti competere con altri clienti per le risorse cloud. Un modo per mitigare questa situazione è avere più opzioni
per la località diRER. Ad esempio, se la pipeline region1 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é implementi la pipeline di backup solo durante gli scenariRER.
Gli svantaggi di questa strategia includono:
- Tempo di inattività: questa strategia richiede più tempo per l'implementazione perché crei la pipeline di failover quando ne hai bisogno. Anziché disporre di una pipeline predefinita, i servizi devono essere creati e configurati durante il ripristino dell'incidente. Anche il tempo di compilazione dell'artefatto e il tempo per recuperare le dipendenze esterne potrebbero essere notevolmente più lunghi.
Documenta il tuo piano di continuità operativa e implementa le best practice
Dopo aver mappato la 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 BCP scritto. Quando crei il tuo BCP, documenta le strategie, i processi e le procedure per ripristinare ogni funzione critica. Questo processo di documentazione include la scrittura di procedure passo passo che i dipendenti con ruoli specifici devono seguire durante un'interruzione.
Dopo aver definito il BCP, implementa o aggiorna la toolchain CI/CD utilizzando le best practice per raggiungere gli obiettivi 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 direttamente dei sistemi sotto il tuo controllo. Tuttavia, ricorda che le dipendenze esterne di secondo o terzo ordine potrebbero avere lo stesso impatto, quindi è 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 disponi di un repository locale o di un backup per queste librerie, potresti non riuscire a creare l'applicazione se l'origine esterna da cui estrai le librerie è disconnessa.
In termini di automazione, l'implementazione delle best practice deve essere incorporata nella tua strategia IaC cloud complessiva. La soluzione IaC deve utilizzare strumenti come Terraform per eseguire automaticamente il provisioning delle risorse necessarie dell'implementazione CI/CD e per configurare i processi. Le pratiche IaC sono procedure di ripristino molto efficaci perché sono incorporate nel funzionamento quotidiano delle pipeline CI/CD. Inoltre, IaC promuove l'archiviazione dei file di configurazione nel controllo del codice sorgente, il che a sua volta promuove l'adozione delle best practice per i backup.
Dopo aver implementato la toolchain in base al tuo piano di continuità operativa e alle best practice per dipendenze e automazione, il processo CI/CD e le strategie di ripristino potrebbero cambiare. Assicurati di documentare eventuali modifiche a strategie, processi e procedure di recupero derivanti dalla revisione del BCP e dall'implementazione delle best practice.
Scenari di test non riusciti e manutenzione del piano
È fondamentale rivedere, testare e aggiornare regolarmente il tuo BCP in modo continuo. Il test delle procedure di BCP e di ripristino verifica che il piano sia ancora valido e che gli obiettivi RPO e RTO documentati siano accettabili. Ancora più importante, tuttavia, test, aggiornamenti e manutenzione regolari rendono l'esecuzione del BCP parte delle normali operazioni. Utilizzando Google Cloud, puoi testare scenari di ripristino a costi minimi. 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 ed esegui il debug dei test con Cloud Logging e Cloud Monitoring: Google Cloud Observability fornisce strumenti di logging e monitoraggio a cui puoi accedere tramite chiamate API, il che significa che puoi automatizzare il deployment di scenari di ripristino reagendo alle metriche. Quando progetti i test, assicurati di aver implementato un monitoraggio e avvisi appropriati che possano attivare azioni di recupero adeguate.
- Esegui i test nel tuo BCP: 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 ambienteRER. Puoi anche eseguire un test in cui il tuo percorso di accesso abituale a Google Cloud non funziona.
In Google, testiamo regolarmente il nostro piano di continuità aziendale attraverso una procedura chiamata DiRT (Disaster Recovery Testing). Questo test aiuta Google a verificare gli impatti, l'automazione ed esporre i rischi non contabilizzati. Le modifiche all'automazione e al piano di continuità operativa che devono essere implementate sono un risultato importante di DiRT.
Best practice
In questa sezione, scoprirai alcune best practice che puoi implementare per raggiungere i tuoi obiettivi di 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 tuo piano di continuità operativa per assicurarti che alta disponibilità, RTO e RPO soddisfino i tuoi requisiti. In caso di incidente o disastro, devi anche fare un'analisi retrospettiva e analizzare la procedura per poterla migliorare.
Alta disponibilità
Per ogni strumento, devi impegnarti a implementare le best practice per l'alta disponibilità. Seguire le best practice per l'alta disponibilità rende il processo CI/CD più proattivo, perché queste pratiche lo rendono più resiliente agli errori. Queste strategie proattive devono essere utilizzate con controlli e procedure più reattivi per il recupero e il backup.
Di seguito sono riportate alcune best practice per ottenere un'elevata disponibilità. Tuttavia, consulta la documentazione dettagliata di ogni strumento nella tua CI/CD per 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 worker vengono create in modo dinamico, quindi il recupero dei nodi non riusciti è automatico.
- Deployment globali e multiregionali: ove possibile, utilizza deployment globali e multiregionali anziché deployment regionali. Ad esempio, puoi configurare Artifact Registry per l'archiviazione multiregionale.
- Dipendenze: comprendi tutte le dipendenze dei tuoi strumenti e assicurati che siano ad alta disponibilità. Ad esempio, puoi memorizzare nella cache tutte le librerie di terze parti nel registro degli artefatti.
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, dovresti implementare le tre best practice seguenti. Tuttavia, per best practice di backup più dettagliate, consulta la documentazione di ogni strumento nel processo CI/CD.
- Controllo del codice sorgente: memorizza i file di configurazione e qualsiasi elemento che codifichi, ad esempio script e policy di automazione, nel controllo del codice sorgente. Gli esempi includono
cloudbuild.yamle file YAML di Kubernetes. - Ridondanza: assicurati che non ci sia un singolo punto di errore per quanto riguarda l'accesso ai secret come password, certificati e chiavi API. Esempi di pratiche da evitare includono la conoscenza della password da parte di una sola persona o l'archiviazione della chiave API su un solo server in una determinata regione.
- Backup: verifica frequentemente la completezza e l'accuratezza dei tuoi 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 i processi di backup. Le tue procedure di ripristino, combinate con backup completi, determineranno la rapidità con cui potrai rispondere agli scenari di emergenza.
Gestione delle dipendenze
La tua 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 origini di dipendenze più comuni sono le seguenti:
- Artefatti dell'applicazione: ad esempio, pacchetti, librerie e immagini
- Sistemi esterni: ad esempio, sistemi di gestione dei ticket e di notifica
Un modo per mitigare i rischi delle dipendenze è adottare la pratica del vendoring. Il vendoring 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.
Alcuni vantaggi dei pacchetti o delle immagini delle applicazioni di terze parti includono:
- Sicurezza: il vendoring rimuove la dipendenza da origini esterne per pacchetti o immagini dell'applicazione, il che può contribuire a prevenire attacchi di inserimento di malware.
- Controllo: se forniscono i propri pacchetti o 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 di settore, come la certificazione Cybersecurity Maturity Model.
Se il tuo team decide di utilizzare pacchetti o immagini di applicazioni fornitore, segui questi passaggi principali:
- Identifica i pacchetti di applicazioni o le immagini che devono essere venduti.
- Crea un repository privato per archiviare i pacchetti o le immagini venduti.
- Scarica i pacchetti o le immagini dalla fonte originale e archiviali nel repository privato.
- Verifica l'integrità dei pacchetti o delle immagini.
- Aggiorna i pacchetti o le immagini forniti in base alle esigenze.
Le pipeline CI/CD spesso chiamano sistemi di terze parti per eseguire azioni come l'esecuzione di scansioni, la registrazione di ticket o l'invio di notifiche. Nella maggior parte dei casi, questi sistemi di terze parti hanno le proprie strategie di RE da implementare. Tuttavia, in alcuni casi potrebbero non disporre di un piano di RE adeguato e queste istanze devono essere documentate chiaramente nel BCP. Devi quindi decidere se queste fasi della pipeline possono essere saltate per motivi di disponibilità o se è accettabile causare tempi di inattività per la pipeline CI/CD.
Monitoraggio e notifiche
La CI/CD è come i sistemi di produzione delle applicazioni, quindi devi anche implementare tecniche di monitoraggio e notifica per gli strumenti CI/CD. Come best practice, ti 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 del servizio (SLI) e gli obiettivi del livello del servizio (SLO). Questi livelli di monitoraggio consentono di monitorare l'integrità e le prestazioni complessive delle pipeline CI/CD. Ad esempio, è possibile implementare gli SLO per monitorare la latenza delle fasi di build e deployment. Questi SLO aiutano i team a creare e rilasciare applicazioni alla velocità e con la frequenza che preferisci.
Procedure di accesso di emergenza
Durante un disastro, potrebbe essere necessario che i team operativi intervengano 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, devi 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 critiche, come configurazione e secret.
- Sviluppa metodi di controllo automatizzati per poter monitorare quando e da chi sono state utilizzate le procedure di accesso di emergenza.
Passaggi successivi
- Scopri di più sui prodotti Google Cloud utilizzati in questo documento:
- Consulta la Guida alla pianificazione del disaster recovery.
- Prova altre funzionalità di Google Cloud completando i nostri tutorial.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.
Collaboratori
Autori:
- Ben Good | Solutions Architect
- Xiang Shen | Solutions Architect
Altri collaboratori:
- Marco Ferrari | Cloud Solutions Architect
- Anuradha Bajpai | Solutions Architect
- Rodd Zurcher | Solutions Architect