Alors on va passer à la news que Guillaume a subtilisé sous mon petit nez,
parce qu'il était plus rapide que moi pour l'écrire dans les notes de l'émission.
Et on va parler de mon grand ami, Google Cloud Platform, n'est-ce pas Guillaume ?
Tout à fait.
Donc je vais expliquer un petit peu l'histoire de cette news.
Je ne sais plus certainement quand, ça remonte à peu près un mois si je ne me tourne pas.
GCP a fait une erreur de configuration.
Les opérateurs de ce cloud Google a fait une erreur de configuration.
Et tout d'un coup, tout l'agrégat de ce client qui s'appelle Unisuper,
qui géré les pensions de retraite de plus de 600 000 Australians,
s'est vu complètement son agrégat supprimé.
Ces machines ont disparu, les données qui étaient dessus ont disparu.
Il s'est retrouvé que avec les autres ressources GCP qu'il avait à côté,
et les autres fournis sortières qu'il utilisait ou les données qu'il avait en interne.
Et il a dû faire avec.
Donc ce qui s'est passé concrètement, pourquoi on en est arrivé là ?
En fait, ils utilisaient un service qui s'appelle le GCVE,
comme Google Cloud VMware Engine, le moteur pour VMware de Google Cloud.
En fait, Google Cloud managent des clusters VMware.
Il est capable de déberger pour le client
une infrastructure de virtualisation VMware directement de cette façon-là.
Et ce client Unisuper faisait ça, utilisé ce service-là.
Et quand ils ont fait créer ce service,
parce que comme il y avait un agrégat qui était quand même très très volumineux,
c'est manuellement les opérateurs de Google qui l'ont fait pour eux,
ils n'ont pas juste cliqué dans un formulaire pour créer leur service.
Et donc quand l'opérateur a fait ça, il a mis un champ vide.
Il a laissé un champ vide en créant cette infrastructure.
Et il savait que si le champ était vide,
comme il n'y avait pas de contrôle spécifique fait là-dessus,
ça mettait une date d'expiration à un an, à 365 jours,
après la création de cet élément-là.
Et donc du jour au lendemain, comme ça, pile un an plus tard,
le cluster a disparu.
Il n'y a pas eu de notification de l'utilisateur,
parce que la demande de suppression n'est pas venue de l'utilisateur.
C'était un comportement non prévu dans ce service managé par Google.
Donc qu'est-ce qui s'est passé ensuite ?
Eh bien le client a bien sûr ouvert un ticket de support chez Google,
a notifié du problème et a essayé de tout faire pour récupérer ces données,
et éventuellement le service qu'il y a avec.
Donc ils ont travaillé maintenant la main
entre les opérateurs de Google et le client pour essayer de tout restaurer.
Ils avaient quelques soft guards sur des buckets Google à côté,
des stockage-objets dans les services Google à côté.
Ils ont pu utiliser ces soft guards-là pour restaurer une partie.
Ils avaient aussi des soft guards en interne sur des fournisseurs tiers.
Et donc ils ont dû travailler plusieurs jours entiers
pour essayer de restaurer tout ça,
parce qu'il fallait déjà cibler d'où venait le problème, le corriger.
Suite à ça, en interne Google a changé ces procédures
pour la création des GCVE, justement,
pour faire en sorte que ça ne puisse plus arriver ces choses-là.
Donc il y a plus d'opérations manuelles par les opérateurs,
tout se fait à 100% en automatisé,
donc il n'y a pas de possibilité d'avoir ce champ vide en question.
Et ils ont fait un audit de tous les GCVE,
tous les GCVE qui étaient existants
pour voir si il n'y en avait pas d'autres qui étaient dans le même cas.
Et voilà, donc au bout d'une semaine,
ils ont réussi à restaurer 100% de leur service,
mais au prix de beaucoup de temps et beaucoup d'argent perdu à ce moment-là.
Donc je voulais profiter de cette news au final
pour dire que créer un plan de reprise d'activité
c'est vraiment primordial,
donc faire en sorte de créer des procédures établies, précises,
pour dire comment restaurer nos services,
comment revenir en état quand on a un accident de ce type-là,
quand on perd un coup de tour nos serveurs,
comment on fait pour restaurer les services quelque part.
C'est quelque chose de primordial,
faire des sauvegardes,
faire aussi régulièrement des vérifications des sauvegardes,
donc aller essayer de restaurer les sauvegardes,
parce que c'est bien de les faire,
mais si elles sont inutilisables, elles ne servent pas grand chose.
Donc faire vraiment toutes ces choses-là,
toujours penser que du jour au lendemain, ça peut disparaître.
C'est pas parce qu'on est chez un fournisseur
qu'il y a une certaine garantie de service
qu'on peut se reposer dessus les yeux fermés.
Voilà ce que je voulais dire.
Je vous laisse la parole.
Bon, je l'attrape.
Moi, ça me fait plaisir,
parce que ça prouve bien que
personne n'est infaillible,
même pas Google.
Et bon, j'espère que notre cher Unis Hyper
a retrouvé ces données.
Ce que tu dis, c'est essentiel.
En fait, c'est aussi pour ça que je voulais parler de ça.
C'est que quand on utilise un cloud
qui soit étranger ou pas,
il faut absolument
extraire les données
et les sauvegarder
en dehors du data center
et en dehors du fournisseur.
C'est un truc que
nous avons fait,
c'est que tu dois faire
si tu manges des infrastructures.
Tu ne dois pas te reposer
sur les sauvegardes
que te propose le fournisseur.
Les sauvegardes que te propose le fournisseur
sont là pour assurer son service.
Elles ne sont pas là pour assurer tes données.
Toi, ton travail,
c'est d'assurer tes données,
donc d'extraire ou de faire des backups
tous les jours
si possible, voire plus, si tu peux,
et de les extraire complètement
du data center
et de l'entreprise.
Je dis du data center et de l'entreprise
parce qu'on ne sait jamais
aujourd'hui, ton fournisseur cloud
tout va bien avec lui,
mais demain il peut mettre la clé sous la porte,
il peut faire partie d'un pays qui entre en guerre,
il peut
décider du jour au lendemain
de mettre fin à ton contrat
et puis de couper les accès.
Donc, il faut bien choisir
un autre fournisseur d'accès
et tu peux même, comme nous,
dupliquer tes données
à ces deux fournisseurs différents.
En tout cas, tu as ce regard,
c'est une double
comment dire
une double sécurité.
C'est vraiment important
et essentiel de faire ça
et ne jamais te dire
que, ok,
ton fournisseur,
c'est Google, Azure, Amazon Web Services
qui ne va pas perdre tes données
par du principe que
n'importe qui peut perdre tes données
parce que c'est trop facile
de cliquer sur un bouton
d'avoir une autre config, comme on l'a vu,
ou une erreur humaine
parce qu'il y a plein d'humains partout.
Donc, prenez responsabilité
et puis, extrais tes données,
c'est important.
Nida,
est-ce que tu veux apporter
quelque chose
ou commenter la news ?
Je vais faire les deux.
Diveaux de la news,
je vais tirer sur l'ambulance
au VH
puisque c'est un très bon exemple
qu'on avait que beaucoup de Français
d'entreprises françaises ont vécu
et qu'on a pris
leur détruitment que le cloud
c'est physique
et qu'on a
des risques de perte de data.
Moi, ça m'est arrivé
dans un job de perdre
des buckets S3 chez AWS
et dans les contrats
c'est clairement dit
qu'il n'y a pas de contrats de base.
La plupart des fournisseurs
de cloud, surtout américains,
n'offrent pas de sauvegarde.
Donc, c'est à toi de t'assurer
de tes arrières.
Les gens
les admins
ont perdu cette habitude
du on-promise
où on a vraiment le côté physique
et on est un peu plus sensibilisé
et malheureusement, ces incidents
là sont
heureusement pas fréquents
mais quand ils arrivent, ils font très très très mal
et ce qui a sauvé
cette entreprise
c'était un fond de pension de retraite
australien, si je me trompe pas
Oui, c'est ça
Ce qui les a sauvés, c'est d'avoir
eu des backups externalisés
et ça, voilà
c'est une très très bonne
stratégie, c'est
dans les backups
on a la fameuse stratégie
qui est le 3 2 1
qui est pour moi
la norme
de base
donc, 3 2 1, qu'est-ce que c'est ?
C'est 3 sauvegarde
sur 2 médias
différents
donc ça peut être disque dur
un hébergeur cloud des bandes magnétiques
et
une sauvegarde externe
ça, c'est la stratégie de base
on a d'autres stratégies
qui sont
par exemple
la 3 2 1
1 0
donc, vous reprenez
3 sauvegarde sur 2 supports de sauvegarde
différents
externalisés
une sauvegarde
offline
donc c'est à dire, voilà qui ne peut pas être
détruite par un malware
et le 0 correspond
à ce qu'il n'y ait
aucune erreur sur les backups
donc là, on est vraiment sur un truc
un peu plus plano et il y a des systèmes
on est plus sur
du 5 sauvegarde
sur
3 supports différents
et sur
2 sites différents si
externalisés, là on dit voilà
mais la base c'est
3 2 1 et après
c'est 3 2 1 1 0
ou 1
ça peut, suivant la criticité
et
c'est un gros gros taf
tester les backups
c'est très très long parce qu'il faut
ça prend du temps
et les backups
faut penser à la rétention
comment
fonctionnent en termes de backups
si c'est de l'incrémentale
ou de la différentielle
ou de la complète
à quel moment on restore
parce que si vous faites que des différenciels et des incrémentales
sur 3 ans
la restauration vous allez pleurer
avec des risques d'erreur très importants
je vois René qui est en train de faire la grimace
peut-être que
peut-être que tu pourrais
conseiller à un autre auditrice ou auditeur
que si il fait celui du différentiel
il pourrait faire une foule
donc une complète au moins toutes les semaines
c'est la base
toutes les semaines
toutes les semaines
c'est bien c'est ce qu'on fait chez joueur
c'est toutes les semaines et après
il faut avoir une bête
l'idéal c'est d'avoir un backup mensuel
l'idéal
après il y a la théorie
et puis il y a la pratique
on ne vit pas en théorie
c'est des systèmes à froid
surtout pour tout ce qui est base de données
pour être nickel
et il ne faut pas oublier
qu'au niveau légal
en France
surtout sur la partie comptabilité
vous devez les garder 10 ans
et
il y a beaucoup de boîtes
on passe à côté
et le souci des backups
c'est que ça prend énormément de volumétrie
ça peut coûter très vite, très cher
surtout quand on est
sur du cloud
se dire qu'on doit avoir
ou en multicloud
ça veut dire qu'il faut avoir
un autre fournisseur pour externaliser les backups
et là on arrive sur des stratégies
très complexes
surtout si on fait la restauration
complète
en mode
disaster
en mode vraiment désastre
on fait
comment dire on fait
une restauration blanche on va dire
mais dans les conditions réelles
et tester
les checklists
du PRA ou du PCA
donc plan de
reprise d'activité ou plan de continuité
d'activité
et voilà c'est
un taf de malade et malheureusement
les équipes informatiques
n'ont pas les ressources humaines
suffisantes et les ressources financières suffisantes aussi
voilà
il n'y a rien d'autre à dire
la tornée
après ce que t'as dit
j'ai plein d'enjoues à dire de plus
je vais peut-être insister
sur le fait du the soft guard of line
ce que t'as dit parce qu'effectivement
aujourd'hui on n'est pas à l'abri du maloir
qui est bientôt
tout chiffré et ça peut être embêtant
tout ce qu'est embêtant
et puis voilà ce que tu disais
effectivement faire pas se reposer
que sur l'incrémentale, avoir des foules réguliers
ouais ça me parait
ouais c'est effectivement
parfois à couteux mais
parfois il faut
mieux être parano et peut-être en faire un peu plus
au niveau de la soft guard que perdre
l'entreprise parfois
voilà
ouais ça peut être couteux, après il existe des solutions
comme le stockage objet
à froid ou d'autres trucs
et nous typiquement
on envisage de plus en plus
à s'acheter un NAS tout simplement
pour externaliser
une troisième soft guard chez nous
dans nos locaux
moi je vais peut-être
raconter une histoire
donc ça date d'il y a plusieurs années
au plus de moi je suis commencé l'informatique
avec le bug de l'an 2000
donc ça va je peux vous raconter des histoires
donc en fait
j'étais exploitant
pour une boîte
qui fait plein de choses
et notamment là de mes travaux
c'était
de gérer les soft guards
donc il y avait des serveurs
donc les serveurs bureautiques je pense
qui étaient dans les locaux
de là où je travaillais
c'était un grand bâtiment
de bureaux et tout
et tous les jours je devais
aller vérifier que la soft guard
se soit bien faite, extraire la bande magnétique
qui était faite chaque nuit
la remplacer par une nouvelle bande
voilà Nida est en train de nous montrer
pour toi
si tu es sur youtube et bah si tu es
sur le podcast v'avoir l'émission
sur youtube on a une belle bande magnétique
et je devais donc sortir cette bande magnétique
la mettre dans une pochette
et la mettre au courrier
pour qu'elle parte
sur un autre site externalisé
donc on parlait de
soft guard hors ligne externalisé
c'est typiquement ce cas là
et c'est vrai qu'avec le cloud on a oublié
de faire ça
et c'est peut-être pas une bonne chose
je sais pas
en tout cas la soft guard sur bande
c'est toujours important pour faire de l'archivage
à très long terme
alors oui Nida nous montre en plus
tu peux peut-être expliquer ce que c'est Nida
alors moi je sais mais ceux qui ont manipulé
des disquettes le savent mais bon vas-y
je profite
je fais des gilets-bondes à côté de moi
pour toi qui est sur le podcast
absolument que tu ailles voir la vidéo youtube
cette fois l'occasion d'aller voir
mais il faut que tu vois ça
donc ça c'est
une cartouche LTO
ça c'est une cartouche de 800
méga
si je me trompe pas
non 800 giga c'est du LTO 4
donc vous voyez
la bande
on n'y a pas accès en direct
et
pour ceux qui ont connu les disquettes
ou les cassettes audio ou les vhs
vous avez ce petit bitonio
qui permet
à la
qui permet
d'éviter qu'on écrive sur la bande
ça ça empêche les écritures
par une adverteur
et puis si j'aime vous demander
à quoi se faire le code bar c'est pour les robots
de sauvegarde
et petite information
ceux qui font par exemple qui utilisent
AWS glaciers donc
stockage objet
à froid
c'est sauvegardé sur ce type de cartouche
ce qui explique
le temps que met
Amazon Web Services ou d'autres
parce que je pense que l'ovh
fonctionne aussi sur un truc proche
à sortir la sauvegarde
c'est parce que c'est sauvegardé sur bande
et puis classé dans des robots donc c'était un petit clapet
des trompeurs qui fait que dans le lecteur
il y a certainement
mécaniquement quelque chose qui peut s'enfoncer
ou pas dans la cartouche et qui peut dire
ok j'ai le droit d'écrire ou pas
c'est super important
et j'aimerais finir par un truc
qui pour moi est essentiel
moi qui ai fait beaucoup d'exploit et beaucoup de prodigues
qui continuent à en faire pour moi
la sauvegarde c'est
plus important que la supervision
la centralisation des logs
si tu mets en place une application
bon le premier truc
c'est le déploiement continue
le deuxième truc c'est la sauvegarde
c'est avant même de penser
supervision et tout pense sauvegarde parce que la
sauvegarde
c'est les données de tes clients
c'est ce qui est vital
pour ton
pour ton entreprise
aujourd'hui il ne viendrait pas à l'idée de développer
une application sans le guide, sans sauvegarder ton code
dans le guide c'est pareil pour les données
il faut les sauvegarder puis après une fois que t'as mis
en place la sauvegarde, la restauration
tu peux passer à la supervision mais ça sert à rien de mettre la supervision
si t'as pas de sauvegarde en fait parce que de toute façon
tes clients ils vont te prévenir ah ça marche pas
et puis c'est pas si grave, par contre ah j'ai perdu
les données monsieur le client
tchao et bah en fait touristes
déjà faire fermer la boîte de ton client
puis potentiellement
d'en perdre parce que ça va se savoir très vite
je pense que vous en pensez tous les 3
mais pour moi c'est vraiment la
brique essentielle avant même toutes les autres briques
qu'on a l'habitude de voir
j'ai juste une petite anecdote que j'ai entendu il y a pas très longtemps
sur une boîte qui a travaillé dans le cycle
et qui apparemment
ils ont migré un ERP
et le fournisseur a merdé
il a perdu les données
et je crois que c'est arrivé il y a plusieurs
données et la boîte a mis plus d'un an
à se remettre de cette perte de données
elle est pas morte
mais ça a été extrêmement compliqué
pour eux parce que quand c'est arrivé
manifestement
ils avaient un gros volume
de commande du coup ils ont eu plein de problèmes
pour pas retrouver quelques commandes
à qui elles devaient aller etc
les clients
ont perdu confiance
bref ça a été un énorme impact
et bon ils s'en sentent quand même sorti
mais voilà ça a vraiment
plombé la boîte
merci René pour cette anecdote
un peu plombante du coup
et donc
on va passer à la suite
alors si tu aimes ce podcast
et que tu veux le sauvegarder
pour la pérennité, tu veux qu'il continue
encore longtemps, le meilleur moyen
c'est de nous soutenir avec un don
pour nous aider à payer tous les outils
qui permettent l'enregistrement du podcast
ou héberger la communauté
donc tu peux faire un don
sur Libérapac et la plateforme de don que j'ai choisi
tu trouveras le lien en description
ou alors tu peux aller sur soutenir.com
pour un compagnon TiréDeVops pour les faire
c'est hyper simple
Sous-titres par SousTitre