Ce document décrit la reprise après sinistre et la planification de la continuité des activités dans le contexte de l'intégration et de la livraison continues (CI/CD). Il fournit également des conseils sur la façon d'identifier et d'atténuer les dépendances lorsque vous élaborez un plan de continuité d'activité (PCA) complet. Ce document inclut des bonnes pratiques que vous pouvez appliquer à votre plan de continuité d'activité, quels que soient les outils et les processus que vous utilisez. Dans ce document, nous partons du principe que vous maîtrisez les bases du cycle de livraison et d'exploitation des logiciels, de CI/CD et de DR.
Les pipelines CI/CD sont responsables de la création et du déploiement de vos applications stratégiques. Ainsi, comme votre infrastructure d'application, votre processus CI/CD nécessite une planification de la reprise après sinistre et de la continuité des activités. Lorsque vous réfléchissez à la reprise après sinistre et à la continuité des activités pour la CI/CD, il est important de comprendre chaque phase du cycle de livraison et d'exploitation des logiciels, et de comprendre comment elles fonctionnent ensemble en tant que processus holistique.
Le diagramme suivant est une vue simplifiée du cycle de développement et d'exploitation des logiciels, qui comprend les trois phases suivantes :
- Boucle interne de développement : coder, essayer et valider
- Intégration continue : compilation, test et sécurité
- Livraison continue : promotion, déploiement, rollback et métriques
Ce diagramme montre également que Google Kubernetes Engine (GKE), Cloud Run et Google Distributed Cloud sont des cibles de déploiement possibles du cycle de développement et d'exploitation des logiciels.
Tout au long du cycle de développement et d'exploitation des logiciels, vous devez tenir compte de l'impact d'un sinistre sur la capacité des équipes à exploiter et à maintenir les applications critiques. Cela vous aidera à déterminer l'objectif de temps de récupération (RTO) et l'objectif de point de récupération (RPO) pour les outils de votre chaîne d'outils CI/CD.
De plus, la plupart des organisations disposent de nombreux pipelines CI/CD différents pour différentes applications et ensembles d'infrastructures. Chaque pipeline a des exigences uniques en matière de reprise après sinistre et de planification de la continuité des activités. La stratégie de récupération que vous choisissez pour un pipeline varie en fonction du RTO et du RPO de vos outils. Par exemple, certains pipelines sont plus critiques que d'autres et auront des exigences de RTO et de RPO plus faibles. Il est important d'identifier les pipelines critiques pour l'activité dans votre plan de continuité des activités. Ils doivent également faire l'objet d'une attention particulière lorsque vous mettez en œuvre les bonnes pratiques pour tester et exécuter les procédures de récupération.
Étant donné que chaque processus CI/CD et sa chaîne d'outils sont différents, l'objectif de ce guide est de vous aider à identifier les points de défaillance uniques dans votre processus CI/CD et à élaborer un plan de continuité d'activité complet. Les sections suivantes vous aident à effectuer les opérations suivantes :
- Comprendre ce qu'il faut faire pour se remettre d'un événement de reprise après sinistre qui affecte votre processus CI/CD.
- Déterminez le RTO et le RPO pour les outils de votre processus CI/CD.
- Comprenez les modes de défaillance et les dépendances de votre processus CI/CD.
- Choisissez une stratégie de récupération appropriée pour les outils de votre chaîne d'outils.
- Découvrez les bonnes pratiques générales pour implémenter un plan de reprise après sinistre pour votre processus CI/CD.
Comprendre le processus de continuité de l'activité
Il est essentiel d'élaborer un PCA pour vous assurer que votre organisation peut poursuivre ses activités en cas de perturbations et d'urgences. Il aide votre organisation à revenir rapidement à un état de fonctionnement normal pour son processus CI/CD.
Les sections suivantes décrivent les étapes générales à suivre pour créer un plan de continuité d'activité efficace. Bien que la plupart de ces étapes s'appliquent de manière générale à la gestion des programmes et à la reprise après sinistre, certaines sont plus pertinentes pour la planification de la continuité des activités de votre processus CI/CD. Les étapes qui sont spécifiquement pertinentes pour la planification de la continuité des activités pour CI/CD sont mises en évidence dans les sections suivantes. Elles constituent également la base des conseils fournis dans le reste de ce document.
Lancement et planification
Lors de cette phase initiale, les équipes techniques et commerciales travaillent ensemble pour établir les bases du processus de planification de la continuité des activités et de sa maintenance continue. Voici les principales étapes de cette phase :
- Adhésion de la direction : assurez-vous que la direction soutient et défend l'élaboration du PCA. Attribuez la supervision du plan à une équipe ou à une personne dédiée.
- Allocation des ressources : allouez le budget, le personnel et les ressources nécessaires au développement et à la mise en œuvre du plan de continuité des activités.
- Périmètre et objectifs : définissez le périmètre de votre PCA et ses objectifs. Déterminez les processus métier critiques qui doivent être abordés dans le plan.
- Évaluation des risques : identifiez les risques et menaces potentiels susceptibles de perturber votre activité, comme les catastrophes naturelles, les failles de cybersécurité ou les interruptions de la chaîne d'approvisionnement.
- Analyse d'impact : évaluez les conséquences potentielles des résultats de cette évaluation des risques sur vos opérations commerciales, vos finances, votre réputation et la satisfaction de vos clients.
Analyse de l'impact sur l'activité
À cette étape, les équipes commerciales et techniques analysent l'impact des perturbations sur vos clients et votre organisation, et donnent la priorité à la récupération des fonctions commerciales critiques. Ces fonctions métier sont exécutées par différents outils au cours des différentes phases d'un processus de compilation et de déploiement.
L'analyse de l'impact commercial est une étape importante du processus de planification de la continuité des opérations pour la CI/CD, en particulier les étapes d'identification des fonctions métier critiques et des dépendances des outils. De plus, comprendre votre chaîne d'outils CI/CD, y compris ses dépendances et son fonctionnement dans votre cycle de vie DevOps, est un élément de base pour développer un PCA pour votre processus CI/CD.
Voici les principales étapes de l'analyse de l'impact commercial :
- Fonctions critiques : identifiez les fonctions et processus commerciaux clés qui doivent être prioritaires pour la reprise. Par exemple, si vous déterminez que le déploiement d'applications est plus critique que l'exécution de tests unitaires, vous devez donner la priorité à la récupération des processus et outils de déploiement d'applications.
- Dépendances : identifiez les dépendances internes et externes qui pourraient affecter la récupération de vos fonctions critiques. Les dépendances sont particulièrement importantes pour assurer le bon fonctionnement de votre processus CI/CD via sa chaîne d'outils.
- RTO et RPO : définissez des limites acceptables pour les temps d'arrêt et les pertes de données pour chaque fonction critique. Ces cibles de DMIA et de PDMA sont liées à l'importance d'une fonction métier pour la continuité des opérations. Elles impliquent des outils spécifiques nécessaires au bon fonctionnement de la fonction métier.
Développement de la stratégie
À cette étape, l'équipe technique élabore des stratégies de récupération pour les fonctions commerciales critiques, comme la restauration des opérations et des données, et la communication avec les fournisseurs et les parties prenantes. Le développement d'une stratégie est également un élément clé de la planification de la continuité des activités pour votre processus CI/CD, en particulier l'étape de sélection des stratégies de reprise de haut niveau pour les fonctions critiques.
Voici les principales étapes de la phase de développement de la stratégie :
- Stratégies de récupération : élaborez des stratégies pour restaurer les fonctions critiques. Ces stratégies peuvent impliquer d'autres lieux, le télétravail ou des systèmes de sauvegarde. Ces stratégies sont liées aux objectifs de RTO et de RPO pour chaque fonction critique.
- Relations avec les fournisseurs : établissez des plans de communication et de coordination avec les principaux fournisseurs pour maintenir la chaîne d'approvisionnement en activité en cas de perturbations.
- Récupération des données et de l'informatique : créez des plans de sauvegarde des données, de récupération des systèmes informatiques et de mesures de cybersécurité.
- Plan de communication : élaborez un plan de communication clair pour les parties prenantes internes et externes pendant et après une interruption.
Élaboration du plan
À cette étape, la principale tâche consiste à documenter le plan de continuité des activités. L'équipe technique documente les outils, les processus, les stratégies de récupération, la justification et les procédures pour chaque fonction critique. L'élaboration d'un plan consiste également à rédiger des instructions détaillées que les employés doivent suivre en cas d'interruption. Lors de l'implémentation et de la maintenance continue, des modifications peuvent être nécessaires. Le plan doit donc être considéré comme un document évolutif.
Implémentation
À cette étape, vous mettez en œuvre le plan pour votre organisation à l'aide du BCP créé par l'équipe technique. L'implémentation inclut la formation des employés et les tests initiaux du PCA. L'implémentation inclut également l'utilisation du plan en cas de perturbation pour rétablir les opérations régulières. Voici les principales étapes d'implémentation :
- Tests et formation initiaux : une fois le BPC documenté, testez-le à l'aide de simulations et d'exercices pour identifier les lacunes et améliorer son efficacité. Formez vos employés à leurs rôles et responsabilités en cas d'interruption.
- Activation : en cas de perturbation, lancez le plan de continuité des activités en fonction des déclencheurs et des procédures prédéfinis.
- Communication : tenez les parties prenantes informées de la situation et des efforts de reprise.
Maintenance et examen
Cette étape n'est pas un processus défini qui ne se produit qu'une seule fois. Au contraire, elle représente un effort continu qui doit devenir une partie normale de vos opérations CI/CD. Il est important d'examiner, de tester et de mettre à jour régulièrement le PCA au sein de votre organisation afin qu'il reste pertinent et exploitable en cas de perturbation. Voici les principales étapes de la maintenance et de l'examen :
- Mises à jour régulières : examinez et mettez à jour le plan de continuité des activités régulièrement pour qu'il reste à jour et efficace. Mettez-le à jour chaque fois que le personnel, la technologie ou les processus métier changent.
- Leçons apprises : après chaque interruption ou test, organisez une réunion de débriefing pour identifier les leçons apprises et les points à améliorer.
- Conformité réglementaire : alignez votre PCA sur les réglementations et les normes du secteur.
- Sensibilisation des employés : informez en permanence les employés sur le plan de continuité des activités et sur leur rôle dans son exécution.
Élaborer un processus de continuité de l'activité pour CI/CD
Cette section fournit des consignes spécifiques pour créer un plan de continuité des activités axé sur la restauration de vos opérations CI/CD. La planification de la continuité de l'activité pour la CI/CD commence par une compréhension approfondie de votre chaîne d'outils CI/CD et de la façon dont elle s'intègre au cycle de vie de la livraison et des opérations logicielles. Une fois que vous avez compris cela, vous pouvez planifier la façon dont votre organisation récupérera ses opérations CI/CD après une interruption.
Pour créer un processus de continuité de l'activité robuste pour votre processus CI/CD, vous devez suivre les étapes principales suivantes :
- Comprendre la chaîne d'outils
- Identifier les données et les dépendances
- Déterminer les cibles RTO et RPO
- Choisir une stratégie de haut niveau pour la continuité des opérations
- Documentez votre plan de continuité des activités et mettez en œuvre les bonnes pratiques.
- Tester les scénarios d'échec et maintenir le plan
Les sections suivantes fournissent plus d'informations sur chacune de ces étapes.
Comprendre la chaîne d'outils
Les chaînes d'outils CI/CD sont composées de nombreux outils individuels différents, et les combinaisons d'outils possibles peuvent sembler infinies. Toutefois, comprendre votre chaîne d'outils CI/CD et ses dépendances est essentiel pour planifier la continuité de l'activité pour la CI/CD. La mission principale de votre processus CI/CD est de fournir du code aux systèmes de production pour la consommation par les utilisateurs finaux. Tout au long de ce processus, de nombreux systèmes et sources de données différents sont utilisés. Il est essentiel de connaître ces sources de données et ces dépendances pour élaborer un PCA. Pour commencer à créer votre stratégie de reprise après sinistre, vous devez d'abord comprendre les différents outils impliqués dans votre processus CI/CD.
Pour vous aider à comprendre comment évaluer votre propre chaîne d'outils et développer votre plan de continuité d'activité, ce document utilise l'exemple d'une application Java d'entreprise qui s'exécute sur GKE. Le schéma suivant montre la première couche de données et de systèmes dans la chaîne d'outils. Cette première couche serait sous votre contrôle direct et inclurait les éléments suivants :
- Source de vos applications
- Outils de votre plate-forme CI/CD, tels que Cloud Build ou Cloud Deploy
- Interconnexions de base entre les différents outils
Comme le montre le schéma, le flux principal de l'application exemple est le suivant :
- Les événements de développement de code dans la boucle interne de développement déclenchent Cloud Build.
- Cloud Build extrait le code source de l'application du dépôt de gestion de code source.
- Cloud Build identifie toutes les dépendances nécessaires spécifiées dans les fichiers de configuration de compilation, comme les fichiers JAR tiers du dépôt Java dans Artifact Registry. Cloud Build extrait ensuite ces dépendances de leurs emplacements sources.
- Cloud Build exécute la compilation et effectue les validations nécessaires, telles que l'analyse statique et les tests unitaires.
- Si la compilation réussit, Cloud Build crée l'image de conteneur et la transfère vers le dépôt de conteneurs dans Artifact Registry.
- Un pipeline Cloud Deploy est déclenché. Il extrait l'image de conteneur du dépôt et la déploie dans un environnement GKE.
Pour comprendre les outils utilisés dans votre processus CI/CD, nous vous suggérons de créer un diagramme qui illustre votre processus CI/CD et les outils qui y sont utilisés, comme dans l'exemple de ce document. Vous pouvez ensuite utiliser votre diagramme pour créer un tableau qui capture les informations clés sur votre chaîne d'outils CI/CD, telles que la phase du processus, l'objectif de l'outil, l'outil lui-même et les équipes concernées par une défaillance de l'outil. Ce tableau fournit un mappage des outils de votre chaîne d'outils et identifie ceux qui sont associés à des phases spécifiques du processus CI/CD. Le tableau peut donc vous aider à obtenir une vue d'ensemble de votre chaîne d'outils et de son fonctionnement.
Les tableaux suivants mettent en correspondance l'exemple d'application d'entreprise mentionné précédemment avec chaque outil du diagramme. Pour fournir un exemple plus complet de ce à quoi un mappage de chaîne d'outils peut ressembler, ces tableaux incluent également d'autres outils qui ne sont pas mentionnés dans le diagramme, tels que des outils de sécurité ou de test.
Le premier tableau correspond aux outils utilisés dans la phase d'intégration continue du processus CI/CD :
| Intégration continue | Source | Outils utilisés | Utilisateurs principaux | Utilisation |
|---|---|---|---|---|
| Phase : Contrôle des sources |
|
|
|
|
| Phase : Compiler |
|
Développeurs |
|
|
| Phase : Test |
|
Développeurs |
Exécutez des tests unitaires et d'intégration dans une plate-forme cohérente à la demande. |
|
| Phase : Sécurité |
|
|
Analysez le code pour détecter les problèmes de sécurité. |
Le deuxième tableau se concentre sur les outils utilisés lors de la phase de CD du processus CI/CD :
| Déploiement continu | Source | Outils utilisés | Utilisateurs principaux | Utilisation |
|---|---|---|---|---|
| Phase : Déploiement | Fichiers de configuration du déploiement |
|
Automatisez les déploiements pour promouvoir, approuver et gérer le trafic sur une plate-forme sécurisée et cohérente. |
|
| Phase : Test |
|
|
Développeurs |
Testez l'intégration et les performances pour vérifier la qualité et la facilité d'utilisation. |
| Phase : Journalisation |
|
|
Conservez les journaux pour l'observabilité et le dépannage. |
|
| Phase : Surveillance | Surveillance des fichiers de configuration, y compris les éléments suivants :
|
|
|
À mesure que vous continuez à travailler sur votre plan de continuité d'activité et que vous comprenez mieux votre chaîne d'outils CI/CD, vous pouvez mettre à jour votre diagramme et votre tableau de mappage.
Identifier les données et les dépendances
Une fois que vous avez terminé votre inventaire de base et votre cartographie de la chaîne d'outils CI/CD, l'étape suivante consiste à capturer toutes les dépendances sur les métadonnées ou les configurations. Lorsque vous mettez en œuvre votre plan de continuité d'activité, il est essentiel de bien comprendre les dépendances au sein de votre chaîne d'outils CI/CD. Les dépendances appartiennent généralement à l'une des deux catégories suivantes : dépendances internes (de premier ordre) et dépendances externes (de deuxième ou troisième ordre).
Dépendances internes
Les dépendances internes sont des systèmes utilisés par votre chaîne d'outils et que vous contrôlez directement. Les dépendances internes sont également sélectionnées par vos équipes. Ces systèmes incluent votre outil d'intégration continue, votre magasin de gestion des clés et votre système de contrôle du code source. Vous pouvez considérer ces systèmes comme se trouvant au niveau inférieur de la chaîne d'outils elle-même.
Par exemple, le schéma suivant montre comment les dépendances internes s'intègrent à une chaîne d'outils. Le diagramme développe le diagramme précédent de la chaîne d'outils de première couche pour l'exemple d'application Java afin d'inclure également les dépendances internes de la chaîne d'outils : les identifiants de l'application, le fichier deploy.yaml et le fichier cloudbuild.yaml.
Le schéma montre que, pour fonctionner correctement dans l'exemple d'application Java, des outils tels que Cloud Build, Cloud Deploy et GKE doivent avoir accès aux dépendances non liées à la chaîne d'outils,comme cloudbuild.yaml, deploy.yaml et les identifiants de l'application. Lorsque vous analysez votre propre chaîne d'outils CI/CD, vous évaluez si un outil peut s'exécuter seul ou s'il doit appeler une autre ressource.
Examinez les dépendances internes documentées pour l'exemple d'application Java.
Les identifiants sont stockés dans Secret Manager, qui ne fait pas partie de la chaîne d'outils, mais ils sont nécessaires pour que l'application démarre lors du déploiement. Les identifiants de l'application sont donc inclus en tant que dépendance pour GKE. Il est également important d'inclure les fichiers deploy.yaml et cloudbuild.yaml en tant que dépendances, même s'ils sont stockés dans le contrôle du code source avec le code de l'application, car ils définissent le pipeline CI/CD pour cette application.
Le BCP de l'exemple d'application Java doit tenir compte de ces dépendances sur les fichiers deploy.yaml et cloudbuild.yaml, car ils recréent le pipeline CI/CD une fois les outils en place pendant le processus de récupération.
De plus, si ces dépendances sont compromises, le fonctionnement global du pipeline sera affecté, même si les outils eux-mêmes sont toujours opérationnels.
Dépendances externes
Les dépendances externes sont des systèmes externes sur lesquels votre chaîne d'outils s'appuie pour fonctionner, et vous n'avez pas de contrôle direct sur eux. Les dépendances externes résultent des outils et des frameworks de programmation que vous avez sélectionnés. Vous pouvez considérer les dépendances externes comme un niveau inférieur aux dépendances internes. Les dépôts npm ou Maven et les services de surveillance sont des exemples de dépendances externes.
Bien que les dépendances externes soient hors de votre contrôle, vous pouvez les intégrer à votre plan de continuité des activités. Le schéma suivant met à jour l'exemple d'application Java en incluant des dépendances externes en plus des dépendances internes : les bibliothèques Java dans Maven Central et les images Docker dans Docker Hub. Les bibliothèques Java sont utilisées par Artifact Registry, et les images Docker par Cloud Build.
Le diagramme montre que les dépendances externes peuvent être importantes pour votre processus CI/CD : Cloud Build et GKE s'appuient tous deux sur deux services externes (Maven et Docker) pour fonctionner correctement. Lorsque vous évaluez votre propre chaîne d'outils, documentez à la fois les dépendances externes auxquelles vos outils doivent accéder et les procédures de gestion des pannes de dépendances.
Dans l'exemple d'application Java, les bibliothèques Java et les images Docker ne peuvent pas être contrôlées directement, mais vous pouvez toujours les inclure, ainsi que leurs procédures de récupération, dans le PCA. Prenons l'exemple des bibliothèques Java dans Maven. Bien que les bibliothèques soient stockées sur une source externe, vous pouvez établir un processus pour télécharger et actualiser régulièrement les bibliothèques Java dans un dépôt Maven local ou Artifact Registry. Ainsi, votre processus de récupération n'a pas besoin de dépendre de la disponibilité de la source tierce.
De plus, il est important de comprendre que les dépendances externes peuvent comporter plusieurs couches. Par exemple, vous pouvez considérer les systèmes utilisés par vos dépendances internes comme des dépendances de second ordre. Ces dépendances de second ordre peuvent avoir leurs propres dépendances, que vous pouvez considérer comme des dépendances de troisième ordre. Sachez que vous devrez peut-être documenter et comptabiliser les dépendances externes de deuxième et troisième ordre dans votre plan de continuité des activités afin de pouvoir reprendre vos opérations en cas d'interruption.
Déterminer les cibles RTO et RPO
Une fois que vous avez compris votre chaîne d'outils et vos dépendances, vous définissez les cibles RTO et RPO pour vos outils. Les outils du processus CI/CD effectuent chacun une action différente qui peut avoir un impact différent sur l'entreprise. Il est donc important de faire correspondre la priorité des objectifs RTO et RPO de la fonction métier à son impact sur l'activité. Par exemple, la création de nouvelles versions d'applications lors de l'étape d'intégration continue peut avoir moins d'impact que le déploiement d'applications lors de l'étape de déploiement continu. Les outils de déploiement peuvent donc avoir des objectifs de RTO et de RPO plus longs que les autres fonctions.
Le graphique à quatre quadrants suivant est un exemple général de la façon dont vous pouvez déterminer vos objectifs de RTO et de RPO pour chaque composant de la chaîne d'outils CI/CD. La chaîne d'outils mappée dans ce graphique inclut des outils tels qu'un pipeline IaC et des sources de données de test. Les outils n'ont pas été mentionnés dans les diagrammes précédents pour l'application Java, mais ils sont inclus ici pour fournir un exemple plus complet.
Le graphique affiche des quadrants basés sur le niveau d'impact sur les développeurs et les opérations. Dans le graphique, les composants sont positionnés comme suit :
- Impact modéré sur les développeurs, faible impact sur les opérations : sources de données de test
- Impact modéré sur les développeurs, impact modéré sur les opérations : Cloud Key Management Service, Cloud KMS
- Impact modéré sur les développeurs, impact élevé sur les opérations : pipeline de déploiement
- Impact élevé sur les développeurs, faible impact sur les opérations : boucle interne de développement
- Impact élevé sur les développeurs, impact modéré sur les opérations : pipeline CI, pipeline Infrastructure as Code (IaC)
- Impact élevé sur les développeurs, impact élevé sur les opérations : gestion du contrôle du code source (SCM), Artifact Registry
Les composants tels que la gestion du contrôle du code source et Artifact Registry, qui ont un impact élevé sur les développeurs et les opérations, ont le plus d'impact sur l'entreprise. Ces composants doivent avoir les objectifs de RTO et de RPO les plus bas. Les composants des autres quadrants ont une priorité inférieure, ce qui signifie que les objectifs de RTO et de RPO seront plus élevés. En général, les objectifs RTO et RPO pour les composants de votre chaîne d'outils doivent être définis en fonction de la quantité de données ou de configuration dont la perte peut être tolérée par rapport au temps nécessaire pour restaurer le service pour ce composant.
Par exemple, examinez les différents emplacements d'Artifact Registry et du pipeline IaC dans le graphique. Une comparaison de ces deux outils montre qu'une indisponibilité d'Artifact Registry a un impact plus important sur les opérations commerciales qu'une indisponibilité du pipeline IaC. Étant donné qu'une indisponibilité d'Artifact Registry a un impact important sur votre capacité à déployer ou à autoscaler votre application, elle aura des cibles RTO et RPO plus basses que les autres outils. En revanche, le graphique montre qu'une indisponibilité du pipeline IaC a un impact moindre sur les opérations commerciales que d'autres outils. Le pipeline IaC aurait alors des objectifs de RTO et de RPO plus élevés, car vous pouvez utiliser d'autres méthodes pour déployer ou mettre à jour l'infrastructure en cas d'indisponibilité.
Choisir une stratégie de haut niveau pour la continuité des opérations
Les processus de continuité des activités pour les applications de production reposent souvent sur l'une des trois stratégies de reprise après sinistre courantes. Toutefois, pour la CI/CD, vous pouvez choisir entre deux stratégies générales de continuité d'activité : active/passive ou sauvegarde/restauration. La stratégie que vous choisirez dépendra de vos besoins et de votre budget. Chaque stratégie présente des compromis en termes de complexité et de coût, et vous devez tenir compte de différents éléments pour votre processus CI/CD. Les sections suivantes fournissent plus de détails sur chaque stratégie et leurs compromis.
De plus, lorsque des événements d'interruption de service se produisent, ils peuvent avoir un impact au-delà de votre implémentation CI/CD. Vous devez également tenir compte de toute l'infrastructure dont vous avez besoin, y compris le réseau, le calcul et le stockage. Vous devez disposer d'un plan de reprise après sinistre pour ces composants de base et le tester régulièrement pour vous assurer de son efficacité.
Actif/Passif
Avec la stratégie actif/passif (ou veille passive), vos applications et le pipeline CI/CD passif sont des miroirs. Toutefois, le pipeline passif ne gère pas réellement la charge de travail du client, ni les compilations ou les déploiements. Il est donc dans un état réduit. Cette stratégie est plus adaptée aux applications stratégiques pour lesquelles un petit temps d'arrêt est tolérable.
Le schéma suivant illustre une configuration actif/passif pour l'exemple d'application Java utilisé dans ce document. Le pipeline passif duplique entièrement la chaîne d'outils de l'application dans une autre région.
Dans cet exemple, la région 1 héberge le pipeline CI/CD actif et la région 2 héberge le pipeline passif correspondant. Le code est hébergé sur un fournisseur de services Git externe, tel que GitHub ou GitLab. Un événement de dépôt (comme une fusion à partir d'une demande d'extraction) peut déclencher le pipeline CI/CD dans la région 1 pour compiler, tester et déployer dans l'environnement de production multirégional.
Si un problème critique se produit pour le pipeline de la région 1, comme une panne régionale d'un produit, les déploiements ou les compilations peuvent échouer. Pour résoudre rapidement le problème, vous pouvez mettre à jour le déclencheur du dépôt Git et passer au pipeline de la région 2, qui devient alors le pipeline actif. Une fois le problème résolu dans la région 1, vous pouvez conserver le pipeline dans la région 1 en tant que pipeline passif.
Voici quelques avantages de la stratégie actif/passif :
- Temps d'arrêt réduit : comme le pipeline passif a été déployé, mais qu'il a été réduit, le temps d'arrêt est limité au temps nécessaire pour le mettre à l'échelle.
- Tolérance configurable pour la perte de données : avec cette stratégie, la configuration et l'artefact doivent être synchronisés périodiquement. Toutefois, le montant est configurable en fonction de vos besoins, ce qui peut réduire la complexité.
Les inconvénients de cette stratégie sont les suivants :
- Coût : avec une infrastructure dupliquée, cette stratégie augmente le coût global de votre infrastructure CI/CD.
Sauvegarde/Restauration
Avec la stratégie de sauvegarde/restauration, vous ne créez votre pipeline de basculement qu'en cas de besoin lors de la récupération d'un incident. Cette stratégie est plus adaptée aux cas d'utilisation de priorité inférieure. Le schéma suivant illustre une configuration de sauvegarde/restauration pour l'exemple d'application Java. La configuration de sauvegarde ne duplique qu'une partie du pipeline CI/CD de l'application dans une autre région.
Comme dans l'exemple précédent, la région 1 héberge le pipeline CI/CD actif. Au lieu d'avoir un pipeline passif dans la région 2, celle-ci ne dispose que de sauvegardes des données régionales nécessaires, telles que les packages Maven et les images de conteneurs. Si vous hébergez vos dépôts sources dans la région 1, vous devez également synchroniser les données avec vos emplacements de reprise après sinistre.
De même, si un problème critique se produit dans le pipeline de la région 1, comme une panne régionale du produit, vous pouvez restaurer votre implémentation CI/CD dans la région 2. Si le code d'infrastructure est stocké dans le dépôt de code d'infrastructure, vous pouvez exécuter votre script d'automatisation à partir du dépôt et reconstruire le pipeline CI/CD dans la région 2.
Si la panne est un événement à grande échelle, vous risquez d'être en concurrence avec d'autres clients pour les ressources cloud. Pour atténuer cette situation, vous pouvez proposer plusieurs options pour le site de reprise après sinistre. Par exemple, si votre pipeline region1 se trouve dans us-east1, votre région de reprise après sinistre peut être us-east4, us-central1 ou us-west1.
Voici quelques avantages de la stratégie de sauvegarde/restauration :
- Coût : cette stratégie entraîne le coût le plus faible, car vous ne déployez le pipeline de sauvegarde que lors de scénarios de reprise après sinistre.
Les inconvénients de cette stratégie sont les suivants :
- Temps d'arrêt : cette stratégie prend plus de temps à implémenter, car vous créez le pipeline de basculement lorsque vous en avez besoin. Au lieu d'avoir un pipeline prédéfini, les services doivent être créés et configurés lors de la récupération après un incident. Le temps de compilation des artefacts et le temps nécessaire pour récupérer les dépendances externes peuvent également être beaucoup plus longs.
Documenter votre plan de continuité d'activité et mettre en œuvre les bonnes pratiques
Après avoir cartographié votre chaîne d'outils CI/CD, identifié ses dépendances et déterminé les cibles de RTO et de RPO pour les fonctions critiques, l'étape suivante consiste à documenter toutes les informations pertinentes dans un PCA écrit. Lorsque vous créez votre plan de continuité des activités, documentez les stratégies, les processus et les procédures de restauration de chaque fonction critique. Ce processus de documentation consiste à rédiger des procédures détaillées que les employés occupant des rôles spécifiques doivent suivre en cas d'interruption.
Une fois votre plan de continuité des activités défini, vous déployez ou mettez à jour votre chaîne d'outils CI/CD en utilisant les bonnes pratiques pour atteindre vos cibles RTO et RPO. Bien que les chaînes d'outils CI/CD puissent être très différentes, deux modèles clés de bonnes pratiques sont courants, quelle que soit la chaîne d'outils : une compréhension globale des dépendances et l'implémentation de l'automatisation.
En ce qui concerne les dépendances, la plupart des PCA concernent les systèmes directement sous votre contrôle. Toutefois, n'oubliez pas que les dépendances externes de deuxième ou troisième ordre peuvent avoir un impact tout aussi important. Il est donc important de mettre en œuvre des bonnes pratiques et des mesures de redondance pour ces dépendances critiques également. Les bibliothèques Java externes de l'exemple d'application sont un exemple de dépendances de troisième ordre. Si vous ne disposez pas d'un dépôt ni d'une sauvegarde locaux pour ces bibliothèques, il est possible que vous ne puissiez pas compiler votre application si la source externe à partir de laquelle vous extrayez les bibliothèques est déconnectée.
En termes d'automatisation, l'implémentation des bonnes pratiques doit être intégrée à votre stratégie globale d'IaC dans le cloud. Votre solution IaC doit utiliser des outils tels que Terraform pour provisionner automatiquement les ressources nécessaires à votre implémentation CI/CD et configurer les processus. Les pratiques IaC sont des procédures de reprise très efficaces, car elles sont intégrées au fonctionnement quotidien de vos pipelines CI/CD. De plus, l'IaC favorise le stockage de vos fichiers de configuration dans le contrôle des sources, ce qui favorise l'adoption des bonnes pratiques en matière de sauvegarde.
Une fois que vous avez implémenté votre toolchain en fonction de votre plan de continuité d'activité et des bonnes pratiques pour les dépendances et l'automatisation, votre processus CI/CD et vos stratégies de récupération peuvent changer. Veillez à documenter toute modification apportée aux stratégies, processus et procédures de récupération suite à l'examen du plan de continuité des activités et à l'implémentation des bonnes pratiques.
Tester les scénarios d'échec et mettre à jour le plan
Il est essentiel d'examiner, de tester et de mettre à jour régulièrement votre plan de continuité d'activité. Tester le plan de continuité d'activité et les procédures de récupération permet de vérifier que le plan est toujours valide et que les objectifs de temps de récupération et de point de reprise documentés sont acceptables. Toutefois, le plus important est que les tests, les mises à jour et la maintenance réguliers permettent d'intégrer l'exécution du BCP aux opérations normales. Google Cloudvous permet de tester des scénarios de reprise à un coût minimal. Pour faciliter vos tests, nous vous recommandons de procéder comme suit :
- Automatisez le provisionnement de l'infrastructure avec un outil IaC : vous pouvez utiliser des outils tels que Terraform pour automatiser le provisionnement de l'infrastructure CI/CD.
- Surveillez et déboguez vos tests avec Cloud Logging et Cloud Monitoring : Google Cloud Observability fournit des outils de journalisation et de surveillance auxquels vous pouvez accéder par le biais d'appels d'API. Cela signifie que vous pouvez automatiser le déploiement de scénarios de reprise en réaction aux métriques. Lorsque vous créez des tests, assurez-vous de disposer d'une surveillance et d'alertes adaptées pouvant déclencher les actions de reprise appropriées.
- Effectuez les tests dans votre plan de continuité des activités : par exemple, vous pouvez vérifier que les autorisations et les accès utilisateur fonctionnent dans l'environnement de reprise après sinistre comme dans l'environnement de production. Vous pouvez effectuer des tests d'intégration et fonctionnels dans votre environnement de reprise après sinistre. Vous pouvez également effectuer un test dans lequel votre chemin d'accès habituel à Google Cloud ne fonctionne pas.
Chez Google, nous testons régulièrement notre plan de continuité des activités à l'aide d'un processus appelé DiRT (Disaster Recovery Testing). Ces tests aident Google à vérifier les impacts et l'automatisation, et à identifier les risques non comptabilisés. Les modifications à apporter à l'automatisation et au plan de continuité d'activité sont un résultat important de DiRT.
Bonnes pratiques
Dans cette section, vous découvrirez quelques bonnes pratiques que vous pouvez mettre en œuvre pour atteindre vos objectifs de RTO et de RPO. Ces bonnes pratiques s'appliquent de manière générale à la reprise après sinistre pour la CI/CD, et non à des outils spécifiques. Quelle que soit votre implémentation, vous devez tester régulièrement votre plan de continuité d'activité pour vous assurer que la haute disponibilité, le délai de récupération et le point de récupération répondent à vos exigences. En cas d'incident ou de catastrophe, vous devez également effectuer une rétrospective et analyser votre processus afin de l'améliorer.
Haute disponibilité
Pour chaque outil, vous devez vous efforcer d'implémenter les bonnes pratiques de haute disponibilité. En suivant les bonnes pratiques de haute disponibilité, vous adoptez une approche plus proactive pour votre processus CI/CD, car ces pratiques le rendent plus résilient aux échecs. Ces stratégies proactives doivent être utilisées avec des contrôles et des procédures plus réactifs pour la récupération et la sauvegarde.
Voici quelques bonnes pratiques pour atteindre une haute disponibilité. Toutefois, consultez la documentation détaillée de chaque outil de votre CI/CD pour obtenir des bonnes pratiques plus détaillées :
- Services gérés : l'utilisation de services gérés transfère la responsabilité opérationnelle à Google Cloud.
- Autoscaling : utilisez l'autoscaling lorsque cela est possible. Un aspect essentiel de l'autoscaling est que les instances de nœuds de calcul sont créées de manière dynamique. La récupération des nœuds défaillants est donc automatique.
- Déploiements mondiaux et multirégionaux : dans la mesure du possible, utilisez des déploiements mondiaux et multirégionaux au lieu de déploiements régionaux. Par exemple, vous pouvez configurer Artifact Registry pour le stockage multirégional.
- Dépendances : comprenez toutes les dépendances de vos outils et assurez-vous qu'elles sont à haute disponibilité. Par exemple, vous pouvez mettre en cache toutes les bibliothèques tierces dans votre registre d'artefacts.
Procédures de sauvegarde
Lorsque vous implémentez la reprise après sinistre pour la CI/CD, certains outils et processus sont plus adaptés aux stratégies de sauvegarde/restauration. Une stratégie de sauvegarde complète est la première étape vers des contrôles réactifs efficaces. Les sauvegardes vous permettent de récupérer votre pipeline CI/CD avec un minimum d'interruption en cas d'acteurs malveillants ou de scénarios de sinistre.
Pour commencer, vous devez mettre en œuvre les trois bonnes pratiques suivantes. Toutefois, pour obtenir des bonnes pratiques de sauvegarde plus détaillées, consultez la documentation de chaque outil de votre processus CI/CD.
- Gestion de code source : stockez les fichiers de configuration et tout ce que vous codez, comme les scripts d'automatisation et les règles, dans la gestion de code source. Par exemple, les fichiers YAML
cloudbuild.yamlet Kubernetes. - Redondance : assurez-vous qu'il n'y a pas de point de défaillance unique concernant l'accès aux secrets tels que les mots de passe, les certificats et les clés API. Par exemple, évitez de laisser une seule personne connaître le mot de passe ou de stocker la clé API sur un seul serveur dans une région spécifique.
- Sauvegardes : vérifiez fréquemment l'exhaustivité et l'exactitude de vos sauvegardes. Les services gérés tels que Sauvegarde pour GKE vous aideront à simplifier votre processus de validation.
Procédures de récupération
La reprise après sinistre nécessite également des procédures de récupération pour compléter les processus de sauvegarde. Vos procédures de récupération, combinées à des sauvegardes complètes, détermineront la rapidité avec laquelle vous pourrez répondre aux scénarios de sinistre.
Gestion des dépendances
Votre pipeline CI/CD peut comporter de nombreuses dépendances, qui peuvent également être des sources d'échecs. Une liste complète des dépendances doit être identifiée comme décrit précédemment dans ce document, dans Identifier les données et les dépendances. Toutefois, les deux sources de dépendances les plus courantes sont les suivantes :
- Artefacts d'application : par exemple, packages, bibliothèques et images
- Systèmes externes : par exemple, les systèmes de suivi des demandes et de notification
Pour atténuer les risques liés aux dépendances, vous pouvez adopter la pratique du vendoring. Le vendoring de packages ou d'images d'application consiste à créer et à stocker des copies de ceux-ci dans un dépôt privé. L'intégration supprime la dépendance aux sources externes pour ces packages ou images, et peut également aider à empêcher l'insertion de logiciels malveillants dans la chaîne d'approvisionnement logicielle.
Voici quelques-uns des avantages de l'intégration de packages ou d'images d'application :
- Sécurité : le vendoring supprime la dépendance aux sources externes pour les packages ou images d'application, ce qui peut aider à prévenir les attaques d'insertion de logiciels malveillants.
- Contrôle : en fournissant leurs propres packages ou images, les organisations peuvent mieux contrôler leur source.
- Conformité : l'externalisation peut aider les entreprises à se conformer aux réglementations du secteur, comme la certification du modèle de maturité de la cybersécurité.
Si votre équipe décide de faire appel à un fournisseur pour les packages ou les images d'application, suivez ces étapes principales :
- Identifiez les packages ou les images d'application qui doivent être fournis.
- Créez un dépôt privé pour stocker les packages ou images fournis.
- Téléchargez les packages ou les images à partir de la source d'origine et stockez-les dans le dépôt privé.
- Vérifiez l'intégrité des packages ou des images.
- Mettez à jour les packages ou les images vendus si nécessaire.
Les pipelines CI/CD appellent souvent des systèmes tiers pour effectuer des actions telles que l'exécution d'analyses, la journalisation de tickets ou l'envoi de notifications. Dans la plupart des cas, ces systèmes tiers disposent de leurs propres stratégies de reprise après sinistre qui doivent être mises en œuvre. Toutefois, dans certains cas, il est possible qu'ils ne disposent pas d'un plan de reprise après sinistre approprié. Ces cas doivent être clairement documentés dans le BCP. Vous devez ensuite déterminer si ces étapes du pipeline peuvent être ignorées pour des raisons de disponibilité ou s'il est acceptable de provoquer un temps d'arrêt pour le pipeline CI/CD.
Surveillance et notifications
Votre CI/CD est identique à vos systèmes de production d'applications. Vous devez donc également implémenter des techniques de surveillance et de notification pour vos outils CI/CD. Nous vous recommandons d'implémenter des tableaux de bord et des notifications d'alerte. Le dépôt d'exemples GitHub pour Cloud Monitoring contient de nombreux exemples de tableaux de bord et de règles d'alerte.
Vous pouvez également implémenter des niveaux de surveillance supplémentaires, tels que les indicateurs de niveau de service (SLI) et les objectifs de niveau de service (SLO). Ces niveaux de surveillance vous aident à suivre l'état général et les performances de vos pipelines CI/CD. Par exemple, des SLO peuvent être implémentés pour suivre la latence des étapes de compilation et de déploiement. Ces SLO aident les équipes à créer et à déployer des applications à la vitesse et à la fréquence souhaitées.
Procédures d'accès d'urgence
En cas de sinistre, il peut être nécessaire pour les équipes opérationnelles de prendre des mesures en dehors des procédures standards et d'obtenir un accès d'urgence aux systèmes et outils. Ces actions d'urgence sont parfois appelées procédures Break Glass. Pour commencer, vous devez mettre en œuvre ces trois bonnes pratiques :
- Disposez d'un plan et d'une procédure d'escalade clairs. Un plan clair aide l'équipe des opérations à savoir quand elle doit utiliser les procédures d'accès d'urgence.
- Assurez-vous que plusieurs personnes ont accès aux informations critiques, comme la configuration et les secrets.
- Développez des méthodes d'audit automatisées pour pouvoir suivre quand et par qui les procédures d'accès d'urgence ont été utilisées.
Étapes suivantes
- En savoir plus sur les produits Google Cloud utilisés dans ce document :
- Consultez le guide de planification de la reprise après sinistre.
- Essayez d'autres fonctionnalités Google Cloud en suivant nos tutoriels.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.
Contributeurs
Auteurs :
- Ben Good | Architecte de solutions
- Xiang Shen | Architecte de solutions
Autres contributeurs :
- Marco Ferrari | Architecte de solutions cloud
- Anuradha Bajpai | Architecte de solutions
- Rodd Zurcher | Architecte de solutions