From Code to Cloud: Building Resilience Across the DevOps Pipeline

DevOps gère le code, les pipelines, l’automatisation et les métadonnées. Lorsque ces ressources ne sont pas disponibles, les pipelines de livraison sont bloquéset les activités opérationnelles en subissent les conséquences. 

Les suppressions accidentelles, les délits d’initiés, les erreurs de configuration, les limites des API, les ransomwares et les pannes de cloud touchent même les entreprises les plus expérimentées. 

Ils ne disposent souvent pas de fonctionnalités de conservation à long terme, de protection des métadonnées, de restauration multiplateforme ni de contrôles de sécurité adaptés aux entreprises. 

En contribuant à offrir une protection unifiée et native du cloud, avec une récupération granulaire, des restaurations inter-cloud, un modèle RBAC, une traçabilité et un stockage évolutif. 

Les pannes retardent la mise en production, nuisent à la productivité, augmentent les risques liés à la conformité et portent atteinte à la réputation, ce qui rend la résilience DevOps indispensable. 

Veuillez regarder la vidéoicipour consulter la transcription horodatée

…

Bonjour à tous, bienvenue à notre session intitulée « Du code au cloud : renforcer la résilience tout au long du
« pipeline DevOps ».

Je m’appelle Aashray Agur, chef de produit senior chez Commvault.

C’est ma troisième année chez Commvault.

Je vis à Bangalore, en Inde.

En ce qui concerne mon poste, je travaille au sein de l’équipe chargée des applications SaaS, où je suis directement responsable des solutions Salesforce et
DevOps.

En termes simples, je suis chargé de cerner les besoins des clients et
de concevoir des solutions logicielles adaptées dans ce domaine.

Aujourd’hui, notre intervenant et invité est Anilkumar, d’Oikocredit.

Avant de lui laisser la parole, j’aimerais vous parler un peu d’Oikocredit.

Oikocredit est l’un des plus grands investisseurs à impact social et l’une des plus grandes coopératives au monde.

L’organisation promeut le développement durable en investissant dans l’inclusion financière,
l’agriculture et les énergies renouvelables.

Son siège social est situé aux Pays-Bas.

Et Anil est ingénieur cloud chez

Oikocredit.

Bonjour, Anil.

Ce serait formidable si tu pouvais nous parler un peu de ton poste et de l’endroit où tu travailles. Oui,
Bien sûr.

Bon, pour commencer, euh… je m’appelle Anil.

Je travaille en tant qu’ingénieur cloud chez Oikocredit ; je suis donc basé aux Pays-Bas.

Je me concentre donc sur la mise en œuvre, la conception et la maintenance des infrastructures cloud
.

Ce que j’apprécie le plus, c’est le processus d’automatisation, qui permet d’accélérer les opérations.

En résumé, je veille à ce que notre environnement cloud fonctionne de manière fluide, sécurisée et efficace.

Voici l’ordre du jour de cette session.

Nous commencerons par aborder les risques croissants dans un environnement DevOps, puis nous expliquerons brièvement
pourquoi la résilience est importante et quelles sont les limites de certaines solutions existantes.

Nous passerons ensuite à une démonstration.

Au cours des deux dernières années environ, nous avons vu certaines des entreprises les plus réputées du
secteur technologique

ont été confrontées à des problèmes inattendus au sein de leurs environnements DevOps.

Par exemple, une plateforme de collaboration de premier plan a perdu plus de 100 dépôts GitHub.

Un fournisseur mondial de services cloud a connu une erreur de configuration qui a entraîné une panne DevOps
à l’échelle d’une région.

De même, un acteur majeur du secteur automobile a vu ses projets clés annulés.

Il ne s’agissait ni de cas isolés ni de failles de sécurité.

Ils concernent des organisations disposant de ressources importantes et d’une grande maturité.

Le point essentiel est que cette liste n’est en aucun cas exhaustive.

Si l’on examine ces situations, on constate qu’elles auraient pu se produire dans n’importe quelle organisation.

Il faut donc reconnaître que les risques augmentent au sein de nos outils DevOps.

Pourquoi ne pas demander l’avis d’un expert en la matière ? Anil, cela fait maintenant un certain temps que vous gérez des environnements DevOps
.

Lorsque tu constates des incidents de ce type dans l’ensemble du secteur, comment les interprètes-tu ?

Et constates-tu que les organisations sont de plus en plus conscientes de la nécessité de protéger leurs environnements DevOps ?
?

Oui, c’est une très bonne question.

Il y a quelques années, le DevOps était principalement considéré comme un processus de travail destiné aux développeurs.

Mais aujourd’hui, les choses ont évolué et vont bien au-delà de cela.

Il est désormais considéré comme faisant partie de l’infrastructure critique de l’entreprise.

Tout le monde se concentre donc principalement sur le bon fonctionnement des systèmes de production, mais les systèmes qui
qui développent et déploient ces applications, c’est-à-dire l’environnement DevOps, sont également essentiels.

On constate donc une prise de conscience croissante à travers le monde

de la nécessité de protéger cette couche, non seulement contre les menaces externes, mais aussi contre les modifications accidentelles,
les problèmes internes, voire les pannes de la plateforme.

C’est formidable de voir que la résilience commence à être intégrée au DevOps dès le départ,
plutôt que d’être ajoutée a posteriori.

C’est tout à fait juste.

Arrêtons-nous un instant sur

Pourquoi la résilience est-elle si importante ?

Avant même d’aborder la résilience, prenons un peu de recul et clarifions ce que signifie réellement le DevOps
.

Comme vous l’avez dit tout à l’heure, à l’époque où le DevOps n’existait pas encore, le développement logiciel était assuré par deux équipes
: l’une écrivait le code et la seconde, dont la mission principale était

de veiller au bon fonctionnement de ces systèmes.

Aujourd’hui, le DevOps a

a véritablement transformé la manière dont se déroule le développement logiciel.

Il n’y a plus deux équipes distinctes.

Aujourd’hui, tout s’inscrit dans une boucle continue.

Par exemple, on commence par établir un plan.

Au cours de cette phase de planification, on réfléchit aux fonctionnalités à mettre en place, aux nouvelles solutions à 
développer, etc.

Vous pouvez utiliser un outil tel que Jira, par exemple, à cette fin.

Une fois la planification terminée, vous écrivez le code.

Vous stockez ce code dans un dépôt, sur une plateforme telle que

GitHub ou GitLab.

Une fois le code écrit, vous le compilez et publiez une version, sous forme d’artefact.

Ensuite, vous vérifiez que tout fonctionne correctement, vous déployez votre solution, puis vous assurez sa surveillance.

Une fois la surveillance mise en place, de nouvelles exigences apparaissent.

Et là encore, vous recommencez à planifier.

Vous voyez, c’est comme une boucle sans fin.

Demandez à n’importe qui ayant déjà travaillé dans le domaine du développement logiciel.

Tout le monde s’accordera à dire que cela pourrait durer indéfiniment.

Alors Anil, pourquoi pensez-vous que le DevOps est devenu si essentiel au bon fonctionnement
des organisations modernes d’aujourd’hui, notamment en matière d’agilité et d’innovation ?

Oui, je pense que cela concerne moins une organisation en particulier que l’évolution
globale de la mise en production des logiciels.

De nos jours, tout le monde met l’accent sur la rapidité et la collaboration.

Le DevOps réunit véritablement les opérations de développement et même

la sécurité, afin que les idées puissent passer rapidement et en toute fiabilité du concept à la production.

Il ne s’agit donc plus seulement d’efficacité.

Euh… l’environnement DevOps héberge désormais les éléments les plus critiques, comme le code source, le pipeline, euh
, les logiques métier, ce qui correspond en gros à la propriété intellectuelle de l’organisation et à sa

.

Le DevOps a donc pris une dimension plus stratégique.

C’est désormais grâce à lui que l’entreprise peut innover, rester résiliente et conserver un avantage concurrentiel.

Exactement.

La capacité à agir rapidement, à automatiser les processus et à favoriser la collaboration entre les équipes est devenue un avantage concurrentiel
, cela ne fait aucun doute.

Mais je pense aussi qu’en raison de cette interconnexion, de cette très forte interconnexion, un
problème survenant à un endroit aura

des répercussions en cascade sur l’ensemble de la chaîne.

Par exemple, si vous perdez votre code, tout ce qui en dépend en pâtira.

Vous savez, il y a des risques.

Voyons maintenant quels sont les risques actuels.

Nous avons déjà vu, sur notre première diapositive, quelques exemples de ce qu’ont vécu certaines entreprises
, n’est-ce pas ?

J’essaie simplement de les nommer.

Ainsi, en cas d’attaque par ransomware, vos dépôts de code risquent d’être chiffrés.

En cas d’attaques internes malveillantes, un acteur malveillant pourrait supprimer vos configurations.

En cas d’erreur humaine, cela peut se traduire, par exemple, par l’intégration par vos développeurs d’une
une multitude d’outils tiers.

Si cette intégration tourne mal, c’est tout votre système qui est compromis.

Ces risques existent donc, mais nous pouvons les maîtriser.

Alors Anil, selon vous, que se passe-t-il si ces pipelines DevOps sont perturbés, même
brièvement ?

Hum… C’est une question intéressante.

Notre pipeline DevOps est essentiellement le système qui garantit que les fonctionnalités et les mises à jour de
Nos applications internes sont déployées de manière fluide et sécurisée, conformément à nos

.

Il ne s’agit donc pas simplement de déployer du code.

C’est ce qui permet à tout de continuer à avancer : tester, intégrer et déployer les modifications
sans aucun retard.

Ainsi, si le processus est perturbé, même par un incident mineur, cela ralentirait plusieurs de nos
plusieurs équipes en même temps.

Euh… Et l’impact n’est pas uniquement technique.

Les membres de notre équipe doivent avoir l’assurance que tout fonctionne comme prévu jusqu’à présent.

Euh… Il s’agit avant tout de résoudre le problème et de remettre le tout en état de marche.

Donc, le projet…

Il ne faut pas perdre cet élan.

D’accord.

D’accord.

J’ai essayé de recenser, euh, les risques immédiats.

Par exemple, comme vous l’avez dit, si vous perdez quelque chose, euh, cela entraînera des retards dans le déploiement.

Si vous utilisez un test d’exemple, la qualité du produit en pâtira.

Et aujourd’hui, le code héberge votre propriété intellectuelle.

Aujourd’hui, le code est en quelque sorte au cœur de vos données.

Si vous l’utilisez, vous vous exposez à des risques liés à la propriété intellectuelle.

Euh…

Au-delà de l’aspect technique, quel type d’impact commercial constateriez-vous si les données
Les équipes DevOps deviendraient-elles indisponibles, par exemple dans le cadre de nos données d’entreprise ?

Oui, dans ce cas, euh, si les données DevOps venaient à être indisponibles, ne serait-ce que pendant quelques heures ou quelques jours, l’impact
Le point le plus important, euh, concernerait l’avancement du projet.

Ainsi, lorsque le système chargé de la distribution des logiciels est interrompu, cela ralentit les mises à jour et
les améliorations dont dépend l’équipe.

C’est pourquoi la résilience et la Recovery ne sont pas facultatives.

Elles sont intégrées au processus dès le début.

Il s’agit avant tout de s’assurer que la continuité fasse partie intégrante de la conception.

Ainsi, même si un problème survient, nous pouvons nous remettre rapidement sur pied et continuer à aller de l’avant.

Je veux dire, je n’aurais pas pu mieux le formuler pour compléter ce que vous avez dit.

Euh, ce n’est pas seulement le…

taux de perte de données, il faudrait également tenir compte de la perte de productivité.

Et cela pourrait également avoir des répercussions sur la réputation.

Si vous exercez votre activité dans des secteurs réglementés, vous seriez confrontés à de nombreuses lacunes en matière de conformité.

C’est pourquoi la résilience doit être intégrée dès la conception dans le DevOps, et je suis d’accord avec cette affirmation :
On n’en fera jamais assez, c’est tout.

Bon, nous avons vu que la résilience est indispensable dans le DevOps.

Parlons maintenant un peu des solutions disponibles aujourd’hui sur le marché et des
les limites de ces outils.

En ce qui concerne les solutions disponibles sur le marché, d’après ce que j’ai pu constater en tant que chef de produit
, certaines s’appuient sur des outils natifs, comme la « corbeille ».

D’autres tentent d’utiliser des scripts, parfois personnalisés, pour effectuer les sauvegardes, et il existe
… ainsi que des solutions ponctuelles.

Mais,

Celles-ci présentent de sérieuses limites.

Avant de m’exprimer en tant que chef de produit, j’aimerais vous poser une question en tant que client : pourquoi pensez-vous que
Certaines équipes continuent-elles à s’appuyer sur ces fonctionnalités natives ou ces scripts ?

Pourquoi ces solutions ne font-elles pas partie de notre offre ?

C’est une très bonne question.

Oui, je peux m’exprimer en me basant sur mon expérience.

Au départ, nous avons donc utilisé les fonctionnalités intégrées à la plateforme ainsi que d’autres outils disponibles sur
le marché.

Mais ces options ne couvrent pas, euh, l’ensemble des fonctionnalités que nous recherchons.

Elles couvrent les fonctionnalités de base, mais nécessitent beaucoup de maintenance.

Mais quand on y regarde de plus près, elles ont souvent des durées de conservation plus courtes et ne capturent
pas tout ce qui compte, comme les pipelines, les tableaux de bord et les métadonnées.

Je vois.

En fait, euh, c’est ce que j’ai constaté quand j’ai, euh, interrogé plusieurs personnes.

Euh, les poubelles ne contiennent pas forcément tout.

Même les scripts ne couvrent pas entièrement certains éléments, tels que les métadonnées.

L’un des principaux signaux d’alerte que l’on constate, par exemple lorsque vous utilisez vos scripts, concerne
la sécurité.

Vos sauvegardes restent également dans le même environnement.

Et c’est un sérieux, euh, signal d’alerte.

Euh… Si l’environnement de production tombe en panne, votre sauvegarde tombe également en panne.

Vous ne pouvez donc pas disposer d’une sauvegarde

le même environnement.

Et puis, il y a le problème de la vérifiabilité.

Lorsque vous utilisez des scripts, vous ne voyez pas ce qui a été sauvegardé ni ce qui est en cours de sauvegarde.

Enfin, euh, à l’échelle de l’entreprise.

Il existe certes des scripts et des solutions ponctuelles qui proposent les trois éléments susmentionnés,
mais ils ont du mal à s’adapter à grande échelle.

Euh… Elles peuvent sans doute gérer des centaines de dépôts, mais quand on passe à des milliers de dépôts
ou jusqu’à des téraoctets de données,

elles rencontrent des difficultés et échouent face aux limites des API.

Et c’est la raison pour laquelle ni les scripts, ni les solutions ponctuelles ne
peuvent répondre aux exigences d’une entreprise.

Et c’est précisément pour pallier ces lacunes que Commvault a été créé.

Maintenant, avant de vous expliquer en quoi ma propre solution est efficace, j’aimerais donner la parole à Anil, en tant que

Cher client, quelle a été votre principale motivation pour adopter la solution Commvault au départ ?
?

Oui, je dirais que ce sont la simplicité et la cohérence qui m’ont motivé.

Auparavant, nous devions jongler entre différents outils et politiques pour chaque environnement, ce qui
ce qui rendait la protection complexe et plus difficile à gérer.

Grâce à la solution de sauvegarde Commvault pour DevOps,

Nous disposons désormais d’une approche unifiée, d’un point d’accès unique pour visualiser, sécuriser et restaurer les données dans l’ensemble de notre environnement DevOps.

Et oui, cette cohérence a également renforcé notre sécurité.

Euh, oui, le contrôle d’accès et les politiques de conservation sont appliqués de la même manière partout, ce qui
réduit également les risques et nous aide à rester en conformité sans alourdir notre charge de travail.

Parfait, je suis d’accord.

En fait, l’une des premières choses que j’entends de la part de nos clients concerne cette vue d’ensemble unique
, ce lieu unique où l’on peut sauvegarder tous ses fichiers de travail.

Outre les points que vous avez soulignés, j’aimerais aborder rapidement deux
Ce sont des points très importants, car ils sont liés à ma diapositive précédente.

Nous avons évoqué la question de l’évolutivité : combien de solutions disponibles sur le marché ne sont pas capables de prendre en charge de grandes installations ?

Cela est dû aux limites de débit des API.

Chacune de ces plateformes — Azure DevOps, GitHub, GitHub — limite la
fréquence des sauvegardes ; je veux dire, à quelle fréquence ou combien d’API pouvez-vous utiliser ?

Une fois ces limites atteintes, vos tâches ralentissent ou échouent.

Et nous contournons ce problème grâce à la rotation automatique des jetons.

Ainsi, les sauvegardes s’exécutent en parallèle sans jamais atteindre les limites de débit.

Nous pouvons utiliser plusieurs jetons et les faire tourner de manière transparente.

Nous répartissons également nos charges de travail de manière intelligente afin que les environnements à grande échelle continuent de fonctionner
sans encombre, sans aucune intervention.

Et le point suivant que j’aimerais aborder est la restauration multiplateforme.

Comme nous l’avons déjà mentionné, des interruptions de service peuvent survenir.

Même les grands acteurs peuvent subir des pannes.

Lorsque cela se produit, pour remédier à la situation, vous pouvez transférer vos rapports depuis Azure
De DevOps vers GitHub, de GitHub vers GitLab, et dans n’importe quelle combinaison de ce type.

vous bénéficiez d’une véritable résilience et votre travail ne s’arrête jamais.

De plus, nous proposons toutes ces fonctionnalités standard, telles que des journaux d’audit détaillés
, un contrôle d’accès basé sur des règles, etc.

Et à ce stade, j’aimerais profiter de cette occasion pour annoncer que nous allons bientôt
commencer à utiliser Jira.

Nous lancerons notre programme d’accès anticipé dès le mois de décembre.

Grâce à Jira, nous sommes entrés dans une nouvelle phase de développement au sein de DevOps, et nous sommes vraiment
Ravis de cette prise en charge de Jira.

Passons maintenant à la partie suivante de notre présentation : la démonstration du produit.

Voici notre Commvault Cloud Console.

Il s’agit d’un tableau de bord unique qui vous permet de protéger pratiquement toutes vos
charges de travail.

Voici la page d’accueil de notre outil DevOps.

Je vais organiser mon exposé en deux parties.

Dans la première partie, je vais vous présenter la page d’aperçu et vous expliquer comment intégrer votre application.

Dans la deuxième partie, je me concentrerai sur la restauration.

La page de présentation vous donne un

aperçu des applications dont vous disposez et de leur taille.

Par exemple, nous n’avons pas configuré Jira ; vous ne voyez donc pas Jira ici.

Mais pour toutes celles qui ont été configurées, vous verrez la taille de leur sauvegarde et le nombre de référentiels protégés.

Cela vous donne une idée du nombre de sauvegardes effectuées, ainsi que du nombre d’instances pour lesquelles aucune
aucune sauvegarde n’a été effectuée.

Vous disposez ainsi d’un bilan de santé.

Passons maintenant rapidement à la procédure d’intégration d’une application.

Voici toutes les applications que nous avons configurées.

Euh… En résumé, c’est ce que vous avez vu sur cette… euh… page d’aperçu.

Passons maintenant à l’intégration d’une application.

Cliquez sur « Ajouter une application DevOps ».

Euh… Voici les quatre applications que nous prenons en charge.

Le processus d’intégration est assez similaire pour toutes ces plateformes.

Cliquez sur « Suivant ».

Le nom de l’application peut être, euh, n’importe quoi

vous permet de l’identifier facilement ; il peut s’agir d’un nom de votre instance Azure DevOps ou de tout autre nom de votre choix.

Il existe deux façons de procéder à l’intégration.

Si vous utilisez la configuration express, c’est Commvault qui fournit l’application.

Vous pouvez également utiliser votre propre configuration personnalisée.

Cela signifie que vous pouvez importer votre propre application et l’utiliser également avec la configuration express.

L’ajout ne prend même pas une minute.

Voyons comment cela fonctionne.

Et voilà !

Nous avons établi un contact avec cette organisation.

Passons maintenant à Access Node.

Concrètement, vous devez choisir votre région de stockage.

Nous sommes présents pratiquement partout.

Imaginons que vous soyez basé aux États-Unis : vous verrez alors la région de stockage « États-Unis » ; il en va de même en Europe et
en Asie.

Elle s’affichera automatiquement.

Configurez la région.

Ensuite, choisissez votre forfait.

Dans la section « Plan », vous pouvez essentiellement

Choisissez la fréquence à laquelle vous souhaitez effectuer vos sauvegardes.

Euh… Nous proposons déjà des forfaits de stockage, et vous pouvez également choisir la durée de conservation.

Nous proposons donc une durée de conservation illimitée.

Vous pouvez effectuer des sauvegardes au moins une fois par jour.

Et enfin, le contenu.

Voici donc tous les services que nous protégeons.

Si vous ne souhaitez pas que certains services soient protégés, vous pouvez les désélectionner.

En ce qui concerne les projets, lorsque vous sélectionnez « Tous les projets », cela signifie que tout nouveau
Tout projet ou dépôt créé au quotidien sera analysé et sauvegardé.

Si, par exemple, vous souhaitez uniquement protéger ou désélectionner certaines charges de travail, vous pouvez choisir
cette option.

L’espace de stockage étant inclus dans la licence, il est recommandé de sélectionner tous les projets.

Cliquez sur « Soumettre ».

Et voilà !

Votre instance a été créée.

Maintenant, euh, j’aimerais revenir sur l’un des points que j’ai sans cesse abordés dans ma présentation,
à savoir l’évolutivité.

Pourquoi de nombreuses solutions disponibles sur le marché ne prennent-elles pas en charge l’évolutivité ?

Il s’agit de la prise en charge de plusieurs jetons.

Aujourd’hui, nous avons déjà ajouté une application,

qui vous attribue un jeton.

Ajoutons-en maintenant d’autres.

Il s’agit d’un identifiant que j’ai déjà créé.

Si vous en voulez d’autres, cliquez ici.

Concrètement, cela signifie que si, par exemple, vous atteignez les limites de débit de l’API avec l’une d’entre elles, nous basculons
automatiquement en deuxième, puis en troisième.

De cette façon, vous pouvez ajouter autant d’applications que vous le souhaitez.

Donc, euh, chaque fois que vous atteignez les limites de débit de l’API, nous basculons et nous obtenons ce résultat.

C’est ainsi que nous gérons l’évolutivité.

Voilà, nous en avons terminé avec la partie « onboarding » de la démo.

Passons maintenant à la partie « restauration ».

Revenons à l’organisation.

Voici toutes les sauvegardes qui ont été effectuées.

Vous verrez cet horodatage.

Vous pouvez sélectionner n’importe quelle date, puis cliquer sur « Restaurer ».

Voici comment cela s’organise.

Vous pouvez cliquer sur l’organisation.

Voici tous les projets.

La hiérarchie est donc la suivante : organisation, projets et dépôts.

Vous pouvez constater qu’elle contient des centaines de projets.

Vous pouvez accéder à n’importe quel projet et consulter les dépôts qu’il contient.

Voici tous les dépôts existants.

Maintenant, si vous souhaitez, par exemple, effectuer une restauration.

Cliquez sur le bouton « Restaurer ».

Exactement.

Nous proposons désormais un niveau de granularité encore plus poussé.

Imaginons, par exemple, que vous souhaitiez uniquement restaurer des objets.

Il vous suffit de les désélectionner.

Ou bien vous souhaitez simplement restaurer les dépôts.

Vous pouvez désélectionner les autres services.

C’est ainsi que nous gérons la granularité.

De la même manière, il va de soi que l’on puisse y manger sur place.

Mais nous proposons également la restauration hors site, voire sur disque.

C’est pour vous permettre d’être prêt en cas de sinistre.

Passons maintenant à la restauration hors site.

J’ai également évoqué un facteur important, n’est-ce pas ?

Imaginons que vos plateformes puissent elles aussi connaître des pannes.

Dans ce cas, vous souhaiterez peut-être transférer vos rapports vers d’autres plateformes.

Par exemple, Azure DevOps ou GitHub.

Et c’est nous qui nous en chargeons.

Vous pouvez par exemple choisir n’importe laquelle des applications configurées lors de l’installation.

Et voici la procédure à suivre.

Vous voyez, vous cliquez sur « Soumettre ».

Euh… Ces rapports seraient réintégrés de manière transparente dans votre application.

GitHub, et voilà, ça conclut donc la… oh.

Pour conclure cette discussion, qu’avons-nous observé ?

Regardons la réalité en face : les incidents cybernétiques ne relèvent pas de la théorie.

Nous avons vu des entreprises en faire l’expérience tous les deux jours. Les risques auxquels elles s’exposent sont donc très clairs : les outils natifs et les scripts « à faire soi-même » ont leurs
les limites et les solutions ponctuelles

ne peuvent pas gérer l’échelle.

Compter sur elles ne permettra donc pas d’assurer votre cyber-résilience.

Nous avons également abordé la question des risques.

Avez-vous examiné les pertes de productivité, l’atteinte à la réputation, la perte de confiance des clients ?
et d’autres risques potentiels.

La solution : vous devez disposer d’une solution de niveau entreprise telle que Commvault pour faire face à ces
prendre des risques et être prêt.

Je voudrais donc conclure en m’adressant aux organisations

qui commencent tout juste à réfléchir à la protection de leurs environnements DevOps : quel conseil
leur donneriez-vous ?

Oui, je commencerais par traiter les données DevOps comme n’importe quelle autre donnée critique pour l’entreprise.

Une autre idée fausse courante consiste à croire que les outils natifs ou les scripts rapides suffisent, mais
ces derniers ne couvrent souvent que la Recovery de base.

Ils ne sont pas conçus pour garantir la sécurité à long terme, l’évolutivité, ni même la conformité.

Le deuxième point que je souhaite aborder, c’est de privilégier la simplicité.

En effet, plus la stratégie de protection est fragmentée, plus il devient difficile de garantir
la cohérence et la sécurité.

Hum… Nous devrions donc adopter une approche unifiée alliant visibilité, automatisation et même des contrôles d’accès rigoureux
.

Cela fait une énorme différence dans les opérations informatiques quotidiennes.

C’est un excellent conseil.

J’apprécie vraiment votre point de vue.

Avant de vous quitter, utilisez ces codes QR pour télécharger notre fiche de présentation sur les solutions DevOps, vous inscrire
Participez à notre atelier sur la cyber-résilience, évaluez votre niveau de Readiness face aux cybermenaces et découvrez-en davantage

sur nos programmes d’accès anticipé.

Merci de votre attention.