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 di distribuzione del software, CI/CD e DR.
Le pipeline CI/CD sono responsabili della creazione e del deployment di applicazioni critiche per l'azienda. Pertanto, come per l'infrastruttura delle applicazioni, il processo CI/CD richiede la pianificazione del ripristino di emergenza e della continuità aziendale. Quando si pensa alla RE e alla continuità aziendale per CI/CD, è importante comprendere ogni fase del ciclo operativo e di distribuzione del software e comprendere come funzionano insieme come un processo olistico.
Il seguente diagramma è una rappresentazione semplificata del ciclo di operazioni e sviluppo del software, che include le tre fasi riportate di seguito:
- Ciclo interno di sviluppo: codifica, prova e esegui il 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 destinazioni di deployment del ciclo operativo e di sviluppo del software.
Durante il ciclo operativo e di sviluppo del software, è necessario considerare l'impatto di una catastrofe sulla capacità dei team di operare e per la manutenzione di 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 ciascuna pipeline presenta i requisiti per la pianificazione di RE e continuità aziendale. La strategia di ripristino che scegli per una pipeline varierà in base all'RTO e all'RPO dei tuoi strumenti. Per alcune pipeline sono più critiche di altre e avranno una durata Requisiti RTO e RPO. È 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 catena di strumenti sono diversi, gli obiettivi di questo ti aiutano a identificare i single point of failure nel tuo processo CI/CD e sviluppare un BCP completo. Le sezioni seguenti spiegano come eseguire seguenti:
- Scopri cosa serve per recuperare un evento RE che interessa il tuo CI/CD e il processo di sviluppo.
- Determinare l'RTO e l'RPO per gli strumenti del tuo processo CI/CD.
- Comprendi le modalità di errore e le dipendenze del processo CI/CD.
- Scegli una strategia di recupero appropriata per gli strumenti della tua toolchain.
- Comprendere le best practice generali per l'implementazione di un piano di recupero di RE per il tuo processo CI/CD.
Informazioni sulla procedura di continuità aziendale
Creare un BCP è fondamentale per garantire che la tua organizzazione possa continuare le sue operazioni in caso di interruzioni ed emergenze. Aiuta le tue un'organizzazione torna rapidamente allo stato di normali operazioni per CI/CD e il processo di sviluppo.
Le seguenti sezioni descrivono le fasi generali che includono i passaggi che sono coinvolti nella creazione di un BCP efficace. Sebbene molti di questi passaggi si applichino in generale alla gestione del programma e al piano di ripristino dei dati dopo un disastro, 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 per questa fase includono:
- Approccio del team direttivo: assicurati che la dirigenza apicale sostenga e sostenga 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 BCP e i relativi obiettivi. Determina quali processi aziendali sono fondamentali e devono essere affrontati nel piano.
- Valutazione del rischio: identifica i potenziali rischi e minacce che potrebbero interrompere la tua attività, come calamità naturali, violazioni della cybersicurezza o interruzioni della catena.
- Analisi dell'impatto: valuta le potenziali conseguenze di questi rischi risultati delle valutazioni su operazioni aziendali, finanze, reputazione e la soddisfazione del cliente.
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 CI/CD toolchain, comprese le sue dipendenze e il suo funzionamento all'interno di DevOps. del ciclo di vita: è un componente di base fondamentale per lo sviluppo di un BCP per CI/CD e il processo di sviluppo.
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 determini che il deployment di applicazioni è più critico dell'esecuzione dei test delle unità, e dare la priorità al recupero per i processi e gli strumenti di deployment delle applicazioni.
- Dipendenze: identifica le dipendenze interne ed esterne che potrebbero influire sul recupero delle funzioni critiche. Le dipendenze sono particolarmente pertinenti per garantire il funzionamento continuo del tuo processo CI/CD attraverso della sua toolchain.
- RTO e RPO: definiscono i limiti accettabili per i tempi di inattività e i limiti di 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 ripristino per le funzioni aziendali, come il ripristino di operazioni e dati e la comunicazione con fornitori e stakeholder. Anche lo sviluppo della strategia è una parte fondamentale pianificare la continuità aziendale per il processo CI/CD, in particolare la fase e la selezione di strategie di ripristino di alto livello per le funzioni critiche.
I passaggi chiave nella fase di sviluppo della strategia includono:
- Strategie di ripristino. Sviluppa strategie per il ripristino di elementi critici funzioni. Queste strategie possono includere luoghi alternativi, lavoro da remoto, o sistemi di backup. Queste strategie sono legate ai target RTO e RPO per ogni funzione critica.
- Relazioni con i fornitori: consente di stabilire la comunicazione e di coordinamento con i principali fornitori per mantenere la supply chain in esecuzione 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 interni stakeholder esterni durante e dopo un'interruzione del servizio.
Sviluppo del piano
In questa fase, il passaggio principale consiste nel 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 scrittura di istruzioni passo passo istruzioni 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 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 il test iniziale del BCP. L'implementazione include anche l'utilizzo del piano, se per ripristinare le normali operazioni. Passaggi chiave di implementazione include:
- Test e formazione iniziali: dopo aver documentato il BPC, testalo tramite simulazioni ed esercizi per identificare le lacune e migliorare l'efficacia. Formare i dipendenti sui loro ruoli e responsabilità durante e un'interruzione del servizio.
- 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 e continuo che dovrebbe diventare una parte normale del Operazioni CI/CD. È importante rivedere, testare e aggiornare regolarmente il BCP all'interno dell'organizzazione, in modo che siano sempre pertinenti e fruibili nel caso in cui un'interruzione del servizio. I passaggi chiave della manutenzione e della revisione includono la seguenti:
- Aggiornamenti regolari: rivedi e aggiorna periodicamente il BCP in modo che rimane aggiornata ed efficace. Aggiornalo ogni volta che ci sono modifiche a dipendenti, tecnologie o 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 BCP alle normative del settore e standard.
- Consapevolezza dei dipendenti: informa costantemente i dipendenti sul BCP e i 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 che sia e dedicato al ripristino delle operazioni 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 della 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
- Identificare dati e dipendenze
- Determinazione dei target RTO e RPO
- Scegliere una strategia di alto livello per la continuità aziendale
- Documenta il BCP 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.
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 le La toolchain CI/CD e le sue dipendenze sono fondamentali per pianificare la continuità aziendale per CI/CD. La missione principale del tuo processo CI/CD è la consegna del codice in produzione per il consumo da parte dell'utente finale. Durante questo processo, molti sistemi e origini dati; conoscendo le origini dati e le dipendenze è fondamentale per sviluppare un BCP. Per iniziare a creare la tua strategia di RP, devi prima conoscere 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 in esecuzione con GKE. Il seguente diagramma mostra il primo livello di dati e i sistemi nella toolchain. Questo primo livello è sotto il tuo diretto controllo e include quanto segue:
- L'origine delle 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 è seguenti:
- Eventi di sviluppo del codice nel trigger del loop interno di sviluppo in 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 località di origine.
- Cloud Build esegue la build ed esegue la convalida necessaria, come analisi statica e test delle unità.
- Se la compilazione è riuscita, Cloud Build crea l'immagine del contenitore e la esegue push nel repository del contenitore in Artifact Registry.
- Viene attivata una pipeline Cloud Deploy, che estrae la dell'immagine container dal repository e ne esegue il deployment nell'ambiente GKE.
Per comprendere gli strumenti utilizzati nel tuo processo CI/CD, ti consigliamo di creare un diagramma che mostra il tuo processo CI/CD e gli strumenti utilizzati al suo interno, in modo simile all'esempio in questo documento. Puoi quindi utilizzare il diagramma per creare una tabella che acquisisce informazioni chiave sulla tua toolchain CI/CD, come fase del processo, lo scopo dello strumento, lo strumento stesso e i team interessate 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. In questo modo, la tabella può aiutarti a ottenere una visione d'insieme la toolchain e il suo funzionamento.
Le seguenti tabelle mappano l'esempio di un'azienda citato in precedenza a ogni 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 è mappata agli strumenti utilizzati nella fase CI di CI/CD di elaborazione:
| Integrazione continua | Origine | Strumenti utilizzati | Utenti principali | Utilizzo |
|---|---|---|---|---|
| Fase: controllo del codice sorgente |
|
|
|
|
| Fase: compilazione |
|
Sviluppatori |
|
|
| Fase: test |
|
Sviluppatori |
Esegui test delle unità e di integrazione in una piattaforma on demand coerente. |
|
| Fase: sicurezza |
|
|
Scansiona il codice per individuare 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 in termini di qualità e usabilità. |
| Fase: logging |
|
|
Conserva i log per osservabilità e 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, è acquisire eventuali dipendenze nei metadati o nelle 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 di queste due categorie: interne (primo ordine) ed esterne (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 fornisce un esempio di come le
le dipendenze si inseriscono in una toolchain. Il diagramma amplia 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 alle credenziali dell'applicazione. Quando analizzi la tua toolchain CI/CD, valuti se uno strumento può essere eseguito da solo 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
toolchain, ma le credenziali sono necessarie per l'avvio dell'applicazione
e deployment continuo. Di conseguenza, le credenziali dell'applicazione sono incluse come dipendenza
con 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 BCP per l'applicazione Java di esempio deve tenere conto di queste dipendenze
sui file deploy.yaml e cloudbuild.yaml perché ricreano
pipeline CI/CD dopo che gli strumenti sono in atto durante il processo di ripristino.
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 operare e non sono sotto il tuo controllo diretto. Risultato delle dipendenze esterne con gli strumenti e i framework di programmazione che hai selezionato. Puoi pensare le dipendenze esterne come un altro livello verso il basso rispetto alle dipendenze interne. Esempi di dipendenze esterne includono i repository npm o Maven e di monitoraggio del traffico.
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 i tuoi la tua toolchain, documenta entrambe le dipendenze esterne necessarie ai tuoi strumenti l'accesso e le procedure per la gestione delle 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. Anche se le librerie sono archiviate su un'origine esterna, puoi stabilire per scaricare e aggiornare periodicamente le librerie Java in un Maven locale un repository o Artifact Registry. 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. Questi modelli di secondo ordine possono avere le proprie dipendenze, che si possono definire come dipendenze del terzo ordine. Tieni presente che potresti dover documentare e rendere conto le dipendenze esterne di secondo e terzo ordine nel BCP, di ripristinare le operazioni durante un'interruzione.
Determina i target RTO e RPO
Dopo aver compreso il funzionamento della toolchain e delle dipendenze, definire i target RTO e RPO per i tuoi strumenti. Gli strumenti del processo CI/CD ciascuno esegue un'azione diversa che può avere un impatto diverso attività. Pertanto, è importante far corrispondere la priorità dell'attività l'RTO e l'RPO della funzione sono mirati 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. Di conseguenza, il deployment potrebbero avere obiettivi 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 l'applicazione Java, ma sono incluse qui per fornire un'esperienza esempio.
Il grafico mostra i quadranti basati sul livello di impatto su gli sviluppatori e le 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 operativo elevato: pipeline di deployment
- Impatto elevato sugli sviluppatori, impatto ridotto sulle operazioni: loop interno di sviluppo
- Impatto elevato per gli 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 negli altri quadranti hanno una priorità più bassa, il che significa che l'RTO e l'RPO obiettivi saranno più alti. 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, considera le diverse posizioni di Artifact Registry e IaC pipeline di dati 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 significativa di Artifact Registry sulla capacità di eseguire il deployment o scalare automaticamente l'applicazione, RTO e RPO target 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 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 continuità aziendale: attiva/passiva o di backup/ripristino. La strategia che scegli dipende dai tuoi requisiti e dal tuo budget. Ogni strategia presenta dei compromessi con complessità e costi, e devi valutare diversi aspetti per il tuo CI/CD e il processo di sviluppo. Le seguenti sezioni forniscono ulteriori dettagli su ciascuna strategia e i loro compromessi.
Inoltre, quando si verificano eventi che interrompono il servizio, potrebbero influire su dell'implementazione CI/CD. Devi anche considerare tutta l'infrastruttura necessaria, inclusa la rete, il calcolo e lo spazio di archiviazione. Dovresti avere un Piano di RE per questi componenti di base e testarlo regolarmente per verificarne l'efficacia.
Attivo/passivo
Con la strategia attiva/passiva (o hot standby), le applicazioni e una pipeline CI/CD passiva sono specchi. Tuttavia, la pipeline passiva non gestisce effettivamente il carico di lavoro del cliente e qualsiasi compilazione o implementazione, quindi è 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, regione1 ospita la pipeline CI/CD attiva e regione2 ha controparte passiva. Il codice è ospitato su un provider di servizi Git esterno come GitHub o GitLab. Un evento repository (come un'unione da una richiesta di pull) può attivare la pipeline CI/CD nella regione 1 per creare, testare ed eseguire il deployment 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 i seguenti:
- 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, configurabile in base alle tue esigenze, il che può ridurre complessità.
I principali svantaggi di questa strategia sono:
- Costo: con un'infrastruttura duplicata, questa strategia aumenta il costo complessivo della tua infrastruttura CI/CD.
Backup/ripristino
Con la strategia di backup/ripristino, crei la pipeline di failover solo quando necessarie durante il ripristino degli incidenti. Questa strategia è più appropriata per i casi d'uso con priorità inferiore. Il seguente diagramma mostra un 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, regione1 ospita la pipeline CI/CD attiva. Invece di avere una pipeline passiva in regione 2, regione 2 ha solo backup di necessari per la regione, ad esempio 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 DR.
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 il CI/CD nella pipeline di addestramento 2.
Se l'interruzione è un evento su larga scala, potresti competere con altri clienti per
delle tue risorse cloud. Un modo per mitigare questa situazione è avere più opzioni
per la posizione di RE. Ad esempio, se la pipeline 1 dell'area geografica 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é stai eseguendo il deployment la pipeline di backup solo durante gli scenari di RE.
Gli svantaggi di questa strategia includono i seguenti:
- Tempo di riposo: l'implementazione di questa strategia richiede più tempo in quanto e la pipeline di failover, quando ne hai bisogno. 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 BCP, documenta strategie, processi e procedure per ripristinare 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 BCP, esegui il deployment o l'aggiornamento della toolchain CI/CD utilizzando 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 rivolge ai sistemi direttamente all'interno 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. Il riquadro Java esterno 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 per creare la tua applicazione se l'origine esterna in cui esegui il pull delle librerie è disconnesso.
In termini di automazione, l'implementazione delle best practice dovrebbe essere incorporato nel tuo complesso strategia IaC cloud. 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 recupero molto efficaci perché sono incorporate nel funzionamento quotidiano delle tue pipeline CI/CD. Inoltre, IaC promuove l'archiviazione dei file di configurazione nell'origine che a sua volta promuove l'adozione delle best practice per i backup.
Dopo aver implementato la toolchain in base al BCP e alle best practice per dipendenze e automazione, il processo CI/CD e le strategie di ripristino potrebbe 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.
Testa gli scenari di errore e gestisci 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. Più alta è importante, tuttavia, test, aggiornamento e manutenzione regolari consentono di eseguire 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.
- Monitorare ed eseguire il debug dei tuoi test con Cloud Logging e Cloud Monitoring: Google Cloud Observability fornisce strumenti di logging e monitoraggio a cui puoi accedere tramite le chiamate API, il che significa che puoi automatizzare il deployment di scenari di ripristino 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 BCP: ad esempio, puoi verificare se le autorizzazioni e l'accesso degli utenti funzionano nell'ambiente RE come nell'ambiente di produzione. Puoi eseguire test di integrazione e funzionali nel tuo ambiente di ripristino dei dati. Puoi anche eseguire un test in cui di accesso 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. Modifiche alle l'automazione e il BCP che devono essere implementati 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 DR per CI/CD e non a strumenti specifici. Indipendentemente dall'implementazione, deve testare regolarmente il BCP per garantire che l'alta disponibilità, l'RTO e l'RPO ai tuoi requisiti. In caso di incidente o disastro, dovresti anche eseguire una retrospettiva e analizzare il processo per migliorarlo.
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 dovrebbero essere utilizzate con controlli e procedure reattive sia per il ripristino 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 best practice:
- Servizi gestiti: l'utilizzo di questi servizi cambia l'operatività la responsabilità nei confronti di Google Cloud.
- Scalabilità automatica: se possibile, utilizza la scalabilità automatica. Un aspetto chiave di scalabilità automatica è che le istanze worker vengono create dinamicamente, quindi il ripristino per i nodi con errori è 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 ottenere controlli reattivi. I backup ti consentono di recuperare la pipeline CI/CD con in caso di utenti malintenzionati o scenari di emergenza.
Per iniziare, ti consigliamo di implementare le tre best practice riportate di seguito. Tuttavia, per best practice più dettagliate in materia di backup, consulta la documentazione relativa ciascuno strumento nel tuo 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. Tra gli esempi possibili
cloudbuild.yamle i file YAML di Kubernetes. - Redundanza: assicurati che non esista un single point of failure per quanto riguarda l'accesso ai secret come password, certificati e chiavi API. Gli esempi di pratiche da evitare includono un solo persona che conosce la password o memorizza la chiave API su un solo server in una particolare regione.
- Backup: verifica spesso la completezza e l'accuratezza dei backup. I Managed Service come Backup per GKE contribuiranno a semplificare la procedura di verifica.
Procedure di ripristino
RE di emergenza richiede anche procedure di ripristino a complemento dei processi di backup. Il tuo le procedure di ripristino, combinate con i backup completi, determinano la velocità sei in grado di rispondere a scenari di emergenza.
Gestione delle dipendenze
La pipeline CI/CD può avere molte dipendenze, che possono anche essere origini per 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:
- Artefatti dell'applicazione: ad esempio pacchetti, librerie e immagini
- Sistemi esterni: ad esempio sistemi di gestione delle richieste di assistenza e di notifica
Un modo per mitigare i rischi delle dipendenze è adottare la pratica della fornitore. La distribuzione di pacchetti di applicazioni o immagini è il processo di creazione e archiviazione 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 dei vantaggi dei pacchetti di applicazioni o delle immagini per il fornitore sono la seguenti:
- 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: mediante il fornitore di 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 del settore, come la certificazione Cybersecurity Maturity Model.
Se il tuo team decide di fornire pacchetti di applicazioni o immagini del fornitore, segui questi passaggi:
- Identificare i pacchetti di applicazioni o le immagini 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 dalla fonte originale e archiviali in il repository privato.
- Verifica l'integrità dei pacchetti o delle immagini.
- Aggiorna i pacchetti o le immagini del fornitore in base alle tue esigenze.
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 RP che devono essere implementate. Tuttavia, in alcuni casi potrebbero non avere un piano di RP adatto e queste situazioni devono essere documentate chiaramente nel BCP. Devi quindi decidere se queste fasi della pipeline possono essere ignorate per motivi di disponibilità o se è accettabile causare un tempo di riposo della pipeline CI/CD.
Monitoraggio e notifiche
Le tue operazioni CI/CD sono come i sistemi di produzione delle applicazioni, quindi devi anche implementare tecniche di monitoraggio e notifica per gli 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 una disastro, i team operativi potrebbero intervenire al di fuori delle procedure standard e di ottenere l'accesso di emergenza a sistemi e strumenti. Queste azioni di emergenza sono a volte chiamate procedure di emergenza. Come un 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.
- Garantire che più persone abbiano accesso a informazioni fondamentali, come configurazione e segreti.
- 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 il nostro tutorial.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Centro architetture di Google Cloud.
Collaboratori
Autori:
- Ben Good | Solution Architect
- Xiang Shen | Architetto di soluzioni
Altri collaboratori:
- Marco Ferrari | Cloud Solutions Architect
- Anuradha Bajpai | Solutions Architect
- Rodd Zurcher | Architetto di soluzioni