Ce document décrit la reprise après sinistre et la planification de la continuité de l'activité dans le contexte de l'intégration et de la livraison continues (CI/CD). Il fournit également des conseils sur la manière d'identifier et d'atténuer les dépendances lorsque vous élaborez un plan de continuité d'activité (PCA) complet. Le document inclut des bonnes pratiques que vous pouvez appliquer à votre plan de reprise après sinistre, quels que soient les outils et les processus que vous utilisez. Ce document part du principe que vous connaissez les principes de base du cycle de livraison et d'exploitation des logiciels, de la CI/CD et de la DR.
Les pipelines CI/CD sont chargés de créer et de déployer vos applications critiques pour l'entreprise. Par conséquent, comme pour votre infrastructure d'application, votre processus CI/CD nécessite de planifier la reprise après sinistre et la continuité de l'activité. Lorsque vous réfléchissez à la reprise après sinistre et à la continuité d'activité pour le 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 global.
Le diagramme suivant est une vue simplifiée du cycle de développement et d'exploitation de logiciels, qui comprend les trois phases suivantes:
- Boucle interne de développement: code, test et commit
- 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 logiciel.
Tout au long du cycle de développement et d'exploitation logiciel, vous devez tenir compte de l'impact d'un sinistre sur la capacité des équipes à exploiter et à gérer des applications critiques pour l'activité. 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 entreprises disposent de nombreux pipelines CI/CD différents pour différentes applications et ensembles d'infrastructures, et chaque pipeline a des exigences uniques en termes 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 RTO et RPO plus faibles. Il est important d'identifier les pipelines critiques pour l'activité dans votre plan de reprise après sinistre. Ils doivent également recevoir plus d'attention lorsque vous implémentez les bonnes pratiques pour tester et exécuter les procédures de reprise après sinistre.
Étant donné que chaque processus CI/CD et sa chaîne d'outils sont différents, les objectifs de ce guide sont de vous aider à identifier les points de défaillance uniques dans votre processus CI/CD et à développer un plan de reprise après sinistre complet. Les sections suivantes vous aident à:
- Découvrez ce qu'il faut 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 des outils de votre processus CI/CD.
- Comprendre 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é d'activité
La création d'un BCP est essentielle pour vous assurer que votre organisation peut poursuivre ses activités en cas de perturbation et d'urgence. Il aide votre organisation à retrouver rapidement un état de fonctionnement normal pour son processus CI/CD.
Les sections suivantes décrivent les étapes générales qui incluent les étapes impliquées dans la création d'un plan de reprise après sinistre efficace. Bien que de nombreuses étapes s'appliquent de manière générale à la gestion de programme et à la reprise après sinistre, certaines sont plus pertinentes pour planifier la continuité de l'activité de votre processus CI/CD. Les étapes spécifiquement pertinentes pour la planification de la continuité de l'activité pour le 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
À cette étape initiale, les équipes techniques et commerciales travaillent ensemble pour établir les bases du processus de planification de la continuité de l'activité et de sa maintenance continue. Les principales étapes de cette étape sont les suivantes:
- Obtenir l'adhésion de la direction: assurez-vous que la direction soutient et défend le développement du plan de reprise après sinistre. Attribuez une équipe dédiée ou une personne chargée de superviser le plan.
- Allocation des ressources: allouez le budget, le personnel et les ressources nécessaires au développement et à la mise en œuvre du plan de reprise après sinistre.
- Champ d'application et objectifs: définissez le champ d'application de votre plan de reprise après sinistre 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 qui pourraient perturber votre activité, comme les catastrophes naturelles, les violations de la cybersécurité ou les interruptions de la chaîne d'approvisionnement.
- Analyse d'impact: évaluez les conséquences potentielles de ces résultats d'évaluation des risques sur vos opérations commerciales, vos finances, votre réputation et la satisfaction de vos clients.
Analyse d'impact sur l'entreprise
À ce stade, les équipes commerciales et techniques analysent l'impact commercial des perturbations sur vos clients et votre organisation, et priorisent la reprise des fonctions commerciales critiques. Ces fonctions métier sont effectué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é d'activité pour l'intégration et la livraison continues (CI/CD), en particulier les étapes d'identification des fonctions métier critiques et des dépendances d'outils. De plus, comprendre votre chaîne d'outils CI/CD, y compris ses dépendances et son fonctionnement dans le cycle de vie DevOps, est un élément de base pour développer un plan de reprise après sinistre pour votre processus CI/CD.
Voici les principales étapes de la phase d'analyse de l'impact commercial:
- Fonctions critiques: déterminez les fonctions et processus métier 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 pour les 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 utiles pour assurer le bon fonctionnement de votre processus CI/CD via sa chaîne d'outils.
- RTO et RPO: définissez les limites acceptables pour les temps d'arrêt et les limites de perte de données pour chaque fonction critique. Ces cibles de RTO et de RPO sont liées à l'importance d'une fonction métier pour la poursuite des opérations. Elles impliquent des outils spécifiques qui sont nécessaires au bon fonctionnement de la fonction métier.
Élaboration de la stratégie
À ce stade, l'équipe technique élabore des stratégies de reprise pour les fonctions commerciales critiques, telles que la restauration des opérations et des données, et la communication avec les fournisseurs et les personnes concernées. Le développement de la stratégie est également un élément clé de la planification de la continuité de l'activité 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: développez des stratégies de restauration des fonctions critiques. Ces stratégies peuvent impliquer des sites alternatifs, le télétravail ou des systèmes de sauvegarde. Ces stratégies sont liées aux cibles 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 cas de perturbation.
- Récupération des données et de l'IT: créez des plans de sauvegarde des données, de récupération des systèmes IT et de mesures de cybersécurité.
- Plan de communication: élaborez un plan de communication clair pour les personnes concernées internes et externes pendant et après une perturbation.
Élaboration du plan
À ce stade, l'étape principale consiste à documenter le plan de reprise après sinistre. L'équipe technique documente les outils, les processus, les stratégies de récupération, la logique et les procédures pour chaque fonction critique. Le développement du plan comprend également la rédaction d'instructions détaillées que les employés doivent suivre en cas de perturbation. Lors de l'implémentation et de la maintenance en cours, des modifications peuvent être apportées au plan, qui doit être traité comme un document évolutif.
Implémentation
À ce stade, vous implémentez le plan pour votre organisation à l'aide du plan de reprise après sinistre créé par l'équipe technique. L'implémentation comprend la formation des employés et les tests initiaux du plan de reprise après sinistre. L'implémentation comprend également l'utilisation du plan en cas de perturbation pour rétablir les opérations normales. Voici les principales étapes d'implémentation:
- Tests et formation initiaux: une fois le plan de continuité d'activité documenté, testez-le à l'aide de simulations et d'exercices pour identifier les lacunes et améliorer son efficacité. Former les employés sur leurs rôles et responsabilités en cas de perturbation
- Activation: en cas de perturbation, lancez le plan de reprise après sinistre conformément aux déclencheurs et procédures prédéfinis.
- Communication: tenez les personnes concernées 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. Elle représente plutôt 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 plan de reprise après sinistre au sein de votre organisation afin qu'il reste pertinent et applicable en cas de perturbation. Les principales étapes de la maintenance et de l'examen sont les suivantes:
- Mises à jour régulières: examinez et mettez à jour le plan de reprise après sinistre régulièrement afin qu'il reste à jour et efficace. Mettez-la à jour chaque fois qu'il y a des changements au niveau du personnel, de la technologie ou des processus métier.
- Leçons apprises: après chaque perturbation ou test, effectuez un débriefing pour identifier les leçons apprises et les axes d'amélioration.
- Conformité réglementaire: alignez votre plan de reprise après sinistre sur les réglementations et les normes du secteur.
- Sensibilisation des employés: sensibilisez en permanence les employés au plan de reprise après sinistre et à leur rôle dans son exécution.
Créer un processus de continuité de l'activité pour le CI/CD
Cette section fournit des consignes spécifiques pour créer un plan de reprise après sinistre axé spécifiquement sur la restauration de vos opérations d'intégration et de livraison continues (CI/CD). Le processus de planification de la continuité de l'activité pour l'intégration continue et la livraison continue commence par une compréhension approfondie de votre chaîne d'outils CI/CD et de son lien avec le cycle de vie des opérations et de la livraison de logiciels. Sur la base de cette compréhension, vous pouvez ensuite planifier la façon dont votre organisation va récupérer ses opérations CI/CD après une perturbation.
Pour créer un processus de continuité d'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é de l'activité
- Documenter votre plan de reprise après sinistre et appliquer les bonnes pratiques
- Tester les scénarios de défaillance et gérer 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 possibles d'outils peuvent sembler infinies. Toutefois, comprendre votre chaîne d'outils CI/CD et ses dépendances est essentiel à la planification de la continuité de l'activité pour le CI/CD. La mission principale de votre processus CI/CD est de fournir du code aux systèmes de production pour la consommation des 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 développer un plan de reprise après sinistre. 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 reprise après sinistre, ce document utilise l'exemple d'une application Java d'entreprise exécutée sur GKE. Le schéma suivant montre la première couche de données et de systèmes de la chaîne d'outils. Cette première couche est sous votre contrôle direct et comprend 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 des 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 à partir du dépôt de contrôle des sources.
- Cloud Build identifie toutes les dépendances nécessaires spécifiées dans les fichiers de configuration de compilation, telles que les fichiers JAR tiers du dépôt Java dans Artifact Registry. Cloud Build extrait ensuite ces dépendances à partir de leurs emplacements sources.
- Cloud Build exécute le build 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 du 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 illustrant votre processus CI/CD et les outils 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 de CI/CD, telles que la phase du processus, l'objectif de l'outil, l'outil lui-même et les équipes concernées par un échec de l'outil. Ce tableau fournit un mappage des outils de votre chaîne d'outils et identifie les outils avec des phases spécifiques du processus CI/CD. Ainsi, le tableau peut vous aider à obtenir une vue d'ensemble de votre chaîne d'outils et de son fonctionnement.
Les tableaux suivants font correspondre l'exemple d'application d'entreprise mentionné précédemment à chaque outil du diagramme. Pour fournir un exemple plus complet de ce à quoi peut ressembler un mappage de chaîne d'outils, 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 fait correspondre les outils utilisés dans la phase CI du processus CI/CD:
| Intégration continue | Source | Outils utilisés | Utilisateurs principaux | Utilisation |
|---|---|---|---|---|
| Phase: Contrôle des sources |
|
|
|
|
| Phase: Compilation |
|
Développeurs |
|
|
| Phase: test |
|
Développeurs |
Exécutez des tests unitaires et d'intégration sur une plate-forme cohérente et à 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 dans la phase de CD du processus CI/CD:
| Déploiement continu | Source | Outils utilisés | Utilisateurs principaux | Utilisation |
|---|---|---|---|---|
| Phase: Déploiement | Fichiers de configuration de 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 évaluer 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 reprise après sinistre et que votre compréhension de votre chaîne d'outils CI/CD s'améliore, vous pouvez mettre à jour votre diagramme et votre table de mappage.
Identifier les données et les dépendances
Une fois que vous avez terminé votre inventaire de base et votre carte de votre 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 implémentez votre plan de reprise après sinistre, il est essentiel que vous compreniez clairement les dépendances de votre chaîne d'outils de 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 de CI, votre magasin de gestion des clés et votre système de contrôle de code source. Vous pouvez considérer ces systèmes comme étant situés dans la couche suivante 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 étend le diagramme de la chaîne d'outils de premier niveau précédent 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 diagramme montre que pour fonctionner correctement dans l'exemple d'application Java, des outils tels que Cloud Build, Cloud Deploy et GKE ont besoin d'accéder à des dépendances autres que 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. Par conséquent, les identifiants de l'application sont 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 des sources avec le code de l'application, car ils définissent le pipeline CI/CD de cette application.
Le plan de reprise après sinistre 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 lors du 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. 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 une autre couche sous les dépendances internes. Les dépôts npm ou Maven, ainsi que les services de surveillance, sont des exemples de dépendances externes.
Bien que les dépendances externes ne soient pas sous votre contrôle, vous pouvez les intégrer à votre plan de reprise après sinistre. Le diagramme 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 sont utilisées 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 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 tout de même les inclure, ainsi que leurs procédures de récupération, dans le plan de reprise après sinistre. 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 périodiquement les bibliothèques Java dans un dépôt Maven ou un dépôt Artifact Registry local. 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 avoir 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 prendre en compte les dépendances externes de deuxième et troisième ordre dans votre plan de reprise après sinistre afin de récupérer les opérations en cas de perturbation.
Déterminer les cibles RTO et RPO
Une fois que vous avez compris votre chaîne d'outils et ses dépendances, vous définissez les cibles RTO et RPO de 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 cibles de RTO et de RPO de la fonction commerciale à son impact sur l'entreprise. Par exemple, la création de nouvelles versions d'applications via l'étape CI peut avoir moins d'impact que le déploiement d'applications via l'étape CD. Par conséquent, les outils de déploiement peuvent avoir des cibles RTO et RPO plus longues que d'autres fonctions.
Le graphique à quatre quadrants suivant est un exemple général de la façon dont vous pouvez déterminer vos cibles RTO et 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 de l'application Java, mais ils sont inclus ici pour fournir un exemple plus complet.
Le graphique présente 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: testez les sources de données
- 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 IaC
- Impact élevé sur les développeurs et les opérations: gestion du contrôle des sources (SCM), Artifact Registry
Les composants tels que la gestion du contrôle des sources et Artifact Registry, qui ont un impact important 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 faibles. Les composants des autres quadrants ont une priorité plus faible, ce qui signifie que les objectifs de RTO et de RPO seront plus élevés. En règle générale, les objectifs RTO et RPO des composants de votre chaîne d'outils doivent être définis en fonction de la quantité de données ou de configuration pouvant être tolérée par rapport au temps nécessaire pour restaurer le service pour ce composant.
Par exemple, considérez les différents emplacements d'Artifact Registry et du pipeline IaC dans le graphique. Une comparaison de ces deux outils montre qu'une panne d'Artifact Registry a un impact plus important sur les opérations commerciales qu'une panne du pipeline IaC. Étant donné qu'une panne de l'Artifact Registry a un impact significatif sur votre capacité à déployer ou à mettre à l'échelle automatique votre application, les objectifs RTO et RPO sont inférieurs par rapport aux autres outils. En revanche, le graphique montre qu'une interruption de pipeline IaC a un impact moindre sur les opérations commerciales que d'autres outils. Le pipeline IaC aura alors des objectifs RTO et RPO plus élevés, car vous pouvez utiliser d'autres méthodes pour déployer ou mettre à jour l'infrastructure en cas d'indisponibilité.
Choisissez une stratégie de haut niveau pour la continuité de l'activité
Les processus de continuité d'activité 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 de haut niveau pour la continuité de l'activité: active/passive ou sauvegarde/restauration. La stratégie que vous choisirez dépendra de vos exigences 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 facteurs pour votre processus CI/CD. Les sections suivantes fournissent plus d'informations sur chaque stratégie et leurs compromis.
De plus, lorsque des événements d'interruption de service se produisent, ils peuvent avoir un impact plus important que 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 qu'il est efficace.
Actif/Passif
Avec la stratégie active/passive (ou veille active), 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 la compilation ni le déploiement. Il est donc dans un état réduit. Cette stratégie est la plus appropriée pour les applications critiques pour l'entreprise, pour lesquelles un temps d'arrêt limité est acceptable.
Le schéma suivant montre une configuration active/passive pour l'exemple d'application Java utilisé dans ce document. Le pipeline passif duplique entièrement la chaîne d'outils d'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 dispose de son homologue passif. 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 d'extraction) peut déclencher le pipeline CI/CD dans la région 1 pour créer, tester et déployer dans l'environnement de production multirégional.
Si un problème critique se produit pour le pipeline region1, comme une panne régionale d'un produit, des déploiements ou des 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 region2, qui devient alors le pipeline actif. Une fois le problème résolu dans la région 1, vous pouvez laisser le pipeline de la région 1 en mode passif.
Voici les avantages de la stratégie active/passive:
- Temps d'arrêt faible: comme le pipeline passif a été déployé, mais est réduit, la durée d'arrêt est limitée au temps nécessaire pour augmenter la taille du pipeline.
- 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, la quantité 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 que lorsque cela est nécessaire lors de la récupération d'un incident. Cette stratégie est la plus appropriée pour les cas d'utilisation de priorité inférieure. Le schéma suivant présente 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égion1 héberge le pipeline CI/CD actif. Au lieu d'avoir un pipeline passif dans la région 2, la région 2 ne contient que des sauvegardes des données régionales nécessaires, telles que les packages Maven et les images de conteneur. 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 recompiler le pipeline CI/CD dans la région 2.
Si la panne est un événement à grande échelle, vous pouvez être en concurrence avec d'autres clients pour les ressources cloud. Pour atténuer ce problème, vous pouvez choisir plusieurs sites de DR. Par exemple, si votre pipeline region1 se trouve dans us-east1, votre région de bascule peut être us-east4, us-central1 ou us-west1.
La stratégie de sauvegarde/restauration présente les avantages suivants:
- Coût: cette stratégie est la moins coûteuse, 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 d'incident. Le temps de compilation des artefacts et le temps de récupération des dépendances externes peuvent également être considérablement plus longs.
Documenter votre plan de reprise après sinistre 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 plan de reprise après sinistre écrit. Lorsque vous créez votre plan de reprise après sinistre, documentez les stratégies, les processus et les procédures de restauration de chaque fonction critique. Ce processus de documentation comprend la rédaction de procédures par étapes que les employés occupant des rôles spécifiques doivent suivre en cas de perturbation.
Une fois votre plan de reprise après sinistre défini, vous déployez ou mettez à jour votre chaîne d'outils CI/CD en suivant les bonnes pratiques pour atteindre vos objectifs 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 communs, quelle que soit la chaîne d'outils: une compréhension complète des dépendances et l'implémentation de l'automatisation.
En ce qui concerne les dépendances, la plupart des plans de reprise après sinistre traitent des systèmes directement sous votre contrôle. Toutefois, n'oubliez pas que les dépendances externes de deuxième ou troisième ordre peuvent être tout aussi importantes. Il est donc important d'appliquer les bonnes pratiques et les mesures de redondance à ces dépendances critiques. Les bibliothèques Java externes de l'application exemple sont un exemple de dépendances de troisième ordre. Si vous ne disposez pas d'un dépôt local ni d'une sauvegarde pour ces bibliothèques, vous ne pourrez peut-être 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 IaC dans le cloud globale. 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 d'intégration continue 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 un outil de contrôle des sources, ce qui favorise à son tour l'adoption des bonnes pratiques en matière de sauvegarde.
Une fois que vous avez implémenté votre chaîne d'outils conformément à votre plan de reprise après sinistre et aux bonnes pratiques en matière de dépendances et d'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 qui résultent de l'examen du plan de reprise après sinistre et de l'implémentation des bonnes pratiques.
Tester les scénarios d'échec et gérer le plan
Il est essentiel d'examiner, de tester et de mettre à jour régulièrement votre plan de reprise après sinistre. Tester le plan de continuité d'activité et les procédures de reprise après sinistre permet de vérifier que le plan est toujours valide et que les cibles RPO et RTO documentées sont acceptables. Mais surtout, les tests, les mises à jour et la maintenance réguliers font de l'exécution du plan de reprise après sinistre une partie des opérations normales. Google Cloud vous permet de tester des scénarios de reprise à moindre coût. Pour faciliter le processus de test, nous vous recommandons de procéder comme suit:
- Automatisez le provisionnement de l'infrastructure à l'aide d'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 via des appels d'API. Vous pouvez ainsi 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 reprise après sinistre: par exemple, vous pouvez vérifier si 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 sur 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é d'activité à l'aide d'un processus appelé test de reprise après sinistre (Disaster Recovery Testing, DIRT). Ces tests aident Google à vérifier les impacts, l'automatisation et à identifier les risques non pris en compte. Les modifications apportées à l'automatisation et au plan de reprise après sinistre qui doivent être implémentées constituent un résultat important de l'analyse 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 DR 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 reprise après sinistre pour vous assurer que la haute disponibilité, le RTO et le RPO répondent à vos exigences. En cas d'incident ou de sinistre, 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é. Suivre les bonnes pratiques de haute disponibilité permet de rendre votre processus CI/CD plus proactif, car ces pratiques le rendent plus résilient aux défaillances. 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 assurer 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: dans la mesure du possible, utilisez l'autoscaling. Un aspect essentiel de l'autoscaling est que les instances de workers sont créées de manière dynamique. La récupération des nœuds défaillants est donc automatique.
- Déploiements globaux et multirégionaux: dans la mesure du possible, utilisez des déploiements globaux et multirégionaux plutôt que des 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 disponibilité élevée. Par exemple, vous pouvez mettre en cache toutes les bibliothèques tierces de votre registre d'artefacts.
Procédures de sauvegarde
Lorsque vous implémentez la reprise après sinistre pour le 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 une interruption minimale en cas de présence de pirates informatiques ou de scénarios de sinistre.
Pour commencer, vous devez implémenter les trois bonnes pratiques suivantes. Toutefois, pour connaître les 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 codifiez, 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'existe aucun 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, ne laissez qu'une seule personne connaître le mot de passe ou ne stockez la clé API que sur un seul serveur dans une région donnée.
- Sauvegardes: vérifiez régulièrement 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 reprise, 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 avoir 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 la section Identifier les données et les dépendances de ce document. Toutefois, les deux sources de dépendances les plus courantes sont les suivantes:
- Artefacts d'application: par exemple, les packages, les bibliothèques et les images
- Systèmes externes: par exemple, les systèmes de gestion des demandes et de notification
Une manière d'atténuer les risques liés aux dépendances consiste à adopter la pratique du vendoring. Le fournisseur de packages ou d'images d'application consiste à créer et à stocker des copies de ces éléments dans un dépôt privé. Le référencement élimine la dépendance à l'égard de sources externes pour ces paquets 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 la vente de packages ou d'images d'application:
- Sécurité: le fournisseur supprime la dépendance aux sources externes pour les packages ou les images d'application, ce qui peut aider à prévenir les attaques d'insertion de logiciels malveillants.
- Contrôle: en commercialisant leurs propres packages ou images, les organisations peuvent mieux contrôler la source de ces packages et images.
- Conformité: le référencement peut aider les entreprises à se conformer aux réglementations du secteur, telles que 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, procédez comme suit:
- Identifiez les packages ou images d'application qui doivent être fournis par un fournisseur.
- Créez un dépôt privé pour stocker les packages ou images tiers.
- 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 images fournis par le fournisseur 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 création 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 implémentées. 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 plan de reprise après sinistre. Vous devez ensuite décider 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 comme 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. L'exemple de dépôt 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 des indicateurs de niveau de service (SLI) et des objectifs de niveau de service (SLO). Ces niveaux de surveillance permettent de suivre l'état et les performances globaux de vos pipelines CI/CD. Par exemple, vous pouvez implémenter des SLO pour suivre la latence des étapes de compilation et de déploiement. Ces SLO aident les équipes à créer et à publier des applications au rythme et à la fréquence souhaités.
Procédures d'accès d'urgence
En cas de catastrophe, les équipes d'exploitation peuvent être amenées à prendre des mesures en dehors des procédures standards et à accéder en urgence aux systèmes et aux outils. Ces actions d'urgence sont parfois appelées procédures de secours. Pour commencer, vous devez mettre en œuvre ces trois bonnes pratiques:
- Avoir un plan et une procédure d'escalade clairs Un plan clair aide l'équipe d'exploitation à savoir quand elle doit utiliser les procédures d'accès d'urgence.
- Assurez-vous que plusieurs personnes ont accès aux informations critiques, telles que la configuration et les secrets.
- Développez des méthodes d'audit automatisées afin de pouvoir suivre les cas d'utilisation des procédures d'accès d'urgence et les personnes qui les ont utilisées.
Étape suivante
- Découvrez les produits Google Cloud utilisés dans ce document :
- Consultez le guide de planification de 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