En mars 2021, c'était la panique sur internet.
Il y avait des millions de sites qui sont tombés.
Il n'y avait plus rien.
Personne ne savait ce qui se passait.
Puis, on apprend qu'une zone complète d'un data center d'OVH a brûlé dans un incendie.
Là, c'est la panique. On voit de partout des gens se plaindre, y compris sur les groupes Facebook, de start-upers,
dont une grande majorité sont en PS.
Ça, je vous le passe. Sur Twitter, c'est la folie.
Bref, j'en avais déjà parlé dans une vidéo que je vous mets en description
ou en fiche d'information si vous êtes sur YouTube.
Mais aujourd'hui, ce dont on va parler, c'est de la robustesse des infrastructures.
Ce n'est pas toujours un sujet préoc sérieux, mais on se peut se demander pourquoi.
Bienvenue sur Radio DevOps, la balade aux diffusions des compagnons du DevOps.
Si c'est la première fois que tu nous écoutes, abonne-toi pour ne pas rater les futurs épisodes.
C'est parti !
Bonjour à toi, chers compagnons.
Et tu l'auras compris avec la trop.
Aujourd'hui, on va parler de robustesse des infrastructures avec Damir.
Bonsoir, Damir.
Bonsoir, bonjour.
Avec Nicolas.
Bonsoir, Nicolas.
Bonsoir, il faut que ça crame.
Et avec Erwan. Bonsoir, Erwan.
Bonsoir.
Et apparemment, vos chats ont disparu de l'écran.
Mais en tout cas, on va pouvoir comprendre.
On va commencer en parlant de PRA, PCA, etc.
Tous ces cycles un peu bizarres qu'on voit arriver un peu de partout.
Et on va commencer par le premier.
On va parler du PRA, qui a envie de me le définir un petit peu pour nos chers auditeurs et auditrices.
Allez, du coup, le PRA, globalement, c'est ce cas, sûrement, utilisé au VH quand il y a eu ce petit incendie.
Globalement, le PRA, pour plan de reprise d'activité,
c'est quelque chose qui est prévu.
Normalement, c'est une procédure et une marche à suivre pour remettre en marche tout un système.
Donc, imaginons, soit vous n'avez pas eu de plan de continuité d'activité,
donc ça, on en parlera après ou pas d'autres dispos, pas de choses comme ça.
En tout cas, vous avez tout votre système, qui est hors ligne ou hors service.
Le but du PRA, c'est de vous dire, step by step, comment on fait pour reprendre d'activité.
Notamment, restaurer des sauvegardes et des choses comme ça.
Donc, c'est quelque chose qui doit être très carré, qui est important de tester.
Pour une raison très simple, c'est que généralement, quand on applique un PRA,
c'est rarement la joie et on est rarement dans un moment où on a un zéro stress et tout se passe bien
et on peut se dire, c'est pas grave, j'ai le temps.
Généralement, c'est un peu la panique.
Donc, c'est très important.
En tout cas, il y a une procédure définie, une marche à suivre qui soit lisible et compréhensive par tous.
Notamment, sur la communication, si on y pense pas, mais communiqué sur ce qui est en cours et sur les télé.
C'est quelque chose d'important pour gérer la pression notamment.
Tout à fait.
Et souvent, avec le PRA, tu l'as dit, on parle de PCA.
Est-ce que l'un de vous veut définir un petit peu le PCA ?
Je sens qu'il y a de la volonté là.
On va se battre.
Donc, le PCA, c'est défini comme le plan de continuité d'activité.
Donc, c'est un plan un petit peu plus haut niveau que le PRA.
Et donc, ça définit vraiment comment redémarrer l'activité le plus rapidement possible
avec le minimum de perte de données.
Donc, quand on définit ce PCA, on va vraiment réfléchir à tous les impacts de quel incident
va pouvoir avoir lieu, comment on va pouvoir récupérer les données et ainsi de suite.
Donc, ça va légèrement plus loin que le PRA.
Et donc, je pense que le dernier, c'est pour R1.
Et quand on parle de PRA PCA, souvent, on va définir ce qu'on appelle des SLA pour nos clients.
Et R1, est-ce que tu peux nous dire ce que c'est qu'un SLA ?
C'est le service level agreement.
Et globalement, c'est un document qui décrit la qualité de service qu'on fournit.
Et souvent, c'est associé à un pourcentage qui est en fait le pourcentage sur une période
de données où on estime qu'on s'engage à ce que le service soit up.
Et le pourcentage qui est le plus haut connu dans des services les plus extrêmes chez Google, etc.,
c'est le fameux 95, donc 99% du temps, le service.
Et le provider s'engage à ce que son service soit up dans le temps.
Donc, il y a tout un tas de sites qui vous permet de savoir combien de temps ça correspond sur un an.
Et du coup, pour pouvoir écrire vos propres engagements par rapport aux services que vous vous maintenez.
Pour pouvoir être sûr que vous vous engagez sur la bonne durée de temps.
Je rajoute un petit truc là-dessus.
Si jamais vous étiez plusieurs briques, plusieurs services qui ont des SLA,
la SLA qui va définir la SLA de votre service est bien sûr toujours la SLA la plus faible de votre chaîne critique.
C'est important de le définir quand même et de ne pas rentrer dans le jeu de se dire
« bah j'ai ce service, il a 7 briques à la SLA de 99,999, donc c'est bon.
Alors que derrière, vous avez un autre service qui est vital qui a une SLA de 98,
parce que ça arrive un raisonnement trop souvent.
Merci Damir.
On a d'autres petits sigles à étudier.
On a le RPO et le PDMA.
Qui veut bien nous définir le RPO et le PDMA ?
Après, je vois qu'on a un joli schéma que je vous mettrai en description.
Je peux le faire.
C'est un sujet que j'aime bien.
Donc RPO pour Recovery Point Objective ou PDMA, Père de données maximum admissible,
ça définit la capacité de reprise sur la sauvegarde de la ressource.
Donc en gros, c'est quand est-ce que ça crame ?
Donc si ça crame à 12h et que ma sauvegarde a commencé à 11h,
donc c'est les données de 11h que je vais récupérer, je vais perdre une heure.
Par contre, si c'est la sauvegarde qui a eu cette nuit,
je risque de perdre jusqu'à 24h,
puisque si ça crame à 23h, la sauvegarde a lieu à 11h, je vais perdre 23h de données.
Donc ça, c'est le RPO.
Et après, on a le RTO Recovery Time Objective.
J'ai plus le pendant en français,
mais ça va définir aussi combien de temps on va mettre pour restaurer les données.
Donc entre le moment où ça a cramé et où on a récupéré le service opérationnel,
c'est à partir de quand les données restaurées sont disponibles.
Donc il faut bien avoir en tête ces deux données-là,
surtout quand on va vouloir définir des SLE,
parce que globalement on va aussi dire qu'on accepte de perdre tant de temps sur les données.
Donc après, on va se dire, ouais, les données, c'est important, c'est pas important,
globalement, pour donner un exemple, c'est quand une banque, perdre une seule donnée,
c'est hyper critique, parce que c'est un échange bancaire.
Par contre, Facebook, on perd 10 minutes d'activité,
franchement, est-ce que c'est vraiment grave de perdre 10 vidéos de chaton
et 10 000 personnes qui ont publié ce qu'ils avaient à manger.
Donc c'est bien définir avec le business
qu'est-ce qu'il y a la critique de la perte de données,
d'une information sur combien de temps et ainsi de suite.
Merci, et je vous mets le super schéma
de la décomposition du mécanisme de reprise en fonction de tout ça,
dans les liens en description, et si on peut le mettre à la vidéo YouTube,
et bien on le mettra.
Bon, c'est bien beau, Zoussa, mais finalement à quoi ça sert,
parce qu'on en entend presque jamais parler,
est-ce que ça sert vraiment à faire quelque chose ?
J'aime bien dire que c'est comme la documentation,
en fait, ça sert à rien quand on n'utilise pas,
et le jour où on a besoin, ça sert beaucoup.
Donc effectivement, c'est quelque chose dont on n'entend pas souvent parler,
pour plusieurs raisons, probablement,
c'est quelque chose qui n'est pas forcément vital au bon fonction de l'application,
dans le sens où, pour la définition de votre application,
que votre application soit terminée,
si vous n'avez pas de PRA ou pas de PCA,
pas toutes ces choses-là,
ça va pas se voir au premier coup d'oeil,
il faut un peu analyser les dossiers d'archile,
pour voir si c'est manquant ou pas.
Donc des fois, ça passe au travers des mailles du filet,
comme je le disais,
encore une fois, comme plein de sujets,
comme la documentation, comme les tests.
Donc malheureusement, ça passe un peu au travers des mailles du filet,
pourtant c'est quelque chose qui est important.
Comme je le disais, quand vous avez une perte de services,
et que votre site de votre entreprise,
et que c'est un site qui fournit un service,
on parle par exemple de cette OVH,
où il y a des sites commerçants,
on pourrait parler aussi d'un site comme Doc to Libre,
un site comme Amazon,
qui pourrait pas prendre des commandes.
En fait, ce qu'il faut bien comprendre,
c'est que ça, c'est juste des pertes business,
donc c'est une perte d'argent direct et indirect,
parce que ça atteint aussi l'image de l'entreprise.
Donc pour le coup,
c'est très important,
d'en ces moments-là,
pouvoir ne pas paniquer,
pour avoir un programme clair pour revenir en route,
c'est un peu revenir à flot,
c'est un peu ce que je disais tout à l'heure.
Donc globalement, oui,
c'est un peu comme beaucoup de choses,
si je ferais un parallèle très osé,
je dirais que c'est un peu comme l'arme nucléaire.
C'est quelque chose qui est intéressant d'avoir,
mais qu'on espère ne jamais utiliser,
parce qu'on sait que le jour où on utilisera,
ça n'a pas forcément la joie, mais c'est important qu'il soit là.
Pour le coup,
mais c'est aussi quelque chose qui a un coût assez important
pour le coup en fonction du niveau de ce qu'on veut aussi.
Il faut un peu s'adapter au niveau-là.
C'est quelque chose qui est pas forcément simple
à mettre en place.
Et ce coût, il faut l'adapter aussi à nos besoins.
Si vous êtes un site vitrine
d'un photographe dans une petite ville de France,
vous avez moins d'importance,
moins d'importance, entre guillemets,
à avoir un bon PRA,
que si vous êtes un site comme Amazon, par exemple.
Donc, c'est un peu comme un site de France,


mais je vous raconterai aussi
que le PRA,
je pensais en anglais
qu'il y avait des RP,
le PRA,
ça crée aussi
de la valeur pour la boîte,
parce que moi, je vois dans l'entreprise
dans laquelle je travaille,
c'est souvent
des procédures
qui nous sont demandés
de la part de nos clients.
Ils veulent savoir si on est en mesure de pouvoir réagir, etc.
Donc, même si
dans bien souvent des cas,
je pense que le PRA,
c'est une doc et peut-être quelques scripts, etc.
Mais le fait
d'avoir ça,
ça peut peut-être
déclencher des deals, ou en tout cas,
rassurer le client.
Et en tout cas,
là où je travaille, chez tout le monde,
le fait d'avoir fait l'effort
sur cet exercice,
ça a créé aussi
pas mal de confiance en interne.
Justement, quand il y a eu le problème chez OTH,
on avait une petite partie
sur le data center
qui a cramé.
Ça a été un non sujet.
Dès que la strata a été lancée,
il savait ce qu'il fallait faire,
il savait ce qu'il fallait lancer,
et ça a été très vite réglé.
Et ça, ça a quand même
une valeur tangible,
auprès des clients et en interne
pour rassurer tout le monde.
J'ai une petite question, je ne me rappelle plus
à ce que les PRA et tout ça
s'est compris dans
les certifications de l'épisode 27.
J'ai un doute.
Ce qui me semble que oui, mais j'ai un gros doute.
J'imagine que
pareil, je ne sais pas,
mais j'imagine que c'est dedans.
Ça me paraît trop
mandatorie par rapport à la qualité
de service et tout pour ne pas
en avoir.
Ou en tout cas, avoir une doc
existée.
Je ne connais pas suffisamment
le sujet, mais je pense que ça dépend
du périmètre de ta certification
et du niveau de risque
que tu veux couvrir.
Et un truc
que j'aime bien rappeler, parce que j'ai travaillé
pendant une bonne dizaine d'années chez Orange,
et quand on parlait de PRA,
c'était une plateforme à part qui était prête
à recueillir l'activité
de prod.
J'aime bien rappeler systématiquement
qu'un PRA, c'est vraiment un plan.
Ça peut être
un truc sur un bout de papier.
Quand j'ai travaillé
dans ma première start-up, mon patron
m'a demandé de préparer ça.
Il m'en a parlé
dans le TER.
On l'a fait dans le TER
et je lui ai montré le plan.
Je ne sais plus pourquoi, mais il y a une fois,
ça m'est arrivé, j'en ai eu besoin.
Pas par rapport à l'incident
d'OVH, parce que
j'avais fait la bonne analyse de risque dont
on va parler tout à l'heure.
Par contre,
ça m'est arrivé une fois de perdre toutes mes VMs.
Et heureusement que j'avais préparé ça,
parce que mon plan était prêt et j'ai juste eu
à appliquer ce que j'avais mis en place.
La dernière chose,
c'est que j'ai un de mes clients qui est en train
de m'en parler, parce que effectivement,
ces autres clients,
ces clients à lui, lui demandent.
Donc, je suis en train de lui préparer
un vrai
pra avec une plateforme et un plan.
Mais ce que je lui ai vendu,
c'est le fait qu'on allait tester le
pra régulièrement, mais on n'allait pas
juste tester une migration à blanc.
C'est tous les mois, on basculerait
d'une plateforme sur l'autre.
Comme ça, on est certain que ça bascule
automatiquement.
Et je ne sais plus qui parler
de confiance, c'est étroit AirOne.
Il y a peut-être autre chose.
C'est une fois que vous avez votre pra,
vous pouvez aussi un petit peu votre prime
de l'assurance, parce que si vous avez un pra,
ça aura moins d'impact sur un désastre
et vous pouvez peut-être négocier
avec votre assureur de réduire
ce que vous coûte
votre assurance.
Et
dernière chose,
il y a certaines boîtes qui vont
pousser le vie, ça,
détruire des ressources au hasard.
Donc, on appelle ça du chaos monkey.
Netflix est très bon pour ça.
Et en fait, ils vont détruire
des morceaux de l'infrastructure
complètement au hasard.
Et si l'infrastructure est pas résiliente,
eh bien, il corrige le problème.
Si l'infrastructure est pas résiliente,
ça a coupé la vidéo d'un client.

et petite rôle au passage,
c'est si vous voulez du chaos monkey,
vous pouvez rester chez OVH,
il y a du chaos monkey à ce service qui est gratuit,
parce que régulièrement, le réseau de tongs,
donc, il faut avoir des infrastructures
sur résilientes.
Pour le coup, pour rebondir là-dessus, il y avait un billet qui était assez intéressant
de Causicloud, qui expliquait justement
qu'ils étaient chez OVH et que les gens
disaient, mais vous êtes pas un peu embêtés,
parce qu'OVH, on va pas se mentir et pas réputer
notamment pour sa stabilité, et le fait qu'ils aient
quand même pas mal d'incidents.
Et justement, ils expliquaient que ça les forçait
à être parfait de leur côté au niveau de la gestion
et la redondance des choses-là, et que du coup,
en fait, c'était comme tu dis, un chaos monkey
en permanence. Je mettrai
des liens aussi
dans la description
avec des articles
et des vidéos
qui vous expliqueraient un peu plus
sur cette partie, on va dire aujourd'hui,
qui est montante et des outils, notamment
pour faire du chaos monkey en entreprise.
Alors pour la petite histoire,
c'est
Benjamin André et Sébastien Blézot
qui ont fait l'article de blog,
puisque Benjamin était mon patron à l'époque
et c'est lui qui m'avait demandé de mettre en place un bras,
donc on l'a fait dans le RER
et Sébastien Blézot a écrit
l'article
parce qu'on avait déjà prévu
au moment où on allait monter la plateforme,
parce que j'y étais, et je savais
qu'OVH était pas suffisamment fiable
et qu'il fallait avoir une infrastructure résiliente.
Donc, j'avais mis des machines à Strasbourg,
j'en avais mis à Gravelin, j'en avais mis à Roubaix
et en priant pour qu'il n'y ait pas
d'eau data center qui tourne en même temps.
Spoiler, c'est arrivé
une fois où Strasbourg
et Gravelin et Roubaix étaient les trois
dans le noir en même temps.
Bon, on passera
sur la partie de comment faire des PRA tout à l'heure
mais j'aimerais bien qu'on continue
un petit peu et à parler des idées reçues
parce que
se poser la question de la quoi ça sert c'est bien
mais finalement pourquoi est-ce que
il n'y a pas plus de monde qui font des PRA
parce que je sais que
quand le data center a brûlé
et qu'OVH a dit
mettez en place vos PRA, il y a plein de gens qui ont dit
PRA, qu'est-ce que c'est, c'est quoi, qu'est-ce qu'on fait.
Donc, pourquoi est-ce qu'il n'y a pas plus de gens
qui en mettent en place ?
C'est quoi les idées reçues, les freins qui nous empêchent
de le faire ?
Parce que ça coûte de l'argent
ça coûte du temps
les projets sont toujours à la rage
donc on n'a déjà pas le temps
de mettre en place la dernière fonctionnalité
donc faire des choses
pour faire en sorte que
si jamais un jour ça crame
globalement on s'en fout
jusqu'au jour où ça crame
et finalement ça revient prioritaire
et dans la boîte c'est tellement
prioritaire qu'on va vraiment
faire ça sur du long terme.
Donc malheureusement
il faut que le chasse retomber une fois dans l'eau
pour qu'il ait pas envie d'y retourner.
Je pense que c'est un peu le principal problème
c'est qu'on se dit, voilà ça, il y a peu de chance
que ça arrive, il n'y a pas de chance que ça arrive
donc du coup
on va pas mettre quelque chose en place, que c'est
quelque chose qui est cher, comme on le disait
mettre un PRA ou un PCA
tout et chose là, c'est quelque chose qui a un coût
qui demande du temps et souvent vu que ça crée
pas de valeur directe comme beaucoup
de choses on se dit on peut gagner peut-être un peu d'argent
sur en prenant un risque.
Prends le risque, des fois je ne dis pas
dans certains cas il ne faut pas oublier que
avoir un PRA et un PCA
très poussé ça ne sert à rien
ça n'a pas forcément une balance
qui soit positive
donc du coup ça se défend aussi comme approche
mais c'est un vrai
problème quand on se base entre guillemets
totalement sur la chance pour des choses qui soient critiques
Alors, à tempérer un petit peu
et c'est pour ça que j'aime bien rappeler qu'un PRA
ça reste juste un plan
c'est le premier PRA de Cozy Cloud
il a été écrit sur un bout de papier
en 10 minutes
Justement, en parlant de plan
est-ce que si on fait un plan
quelques scripts etc et qu'on les pose
dans un coin, est-ce que ça suffit
ou est-ce qu'il faut faire plus que ça, à votre avis ?
Il faut faire plus
parce qu'il faut
tester régulièrement
ce qui a été écrit
ou en tout cas
à défaut de le tester vraiment
et au moins le challenger
régulièrement
se repasser devant et se dire
on ne parle pas de ce nouveau service
qu'on a rajouté il y a quelques temps
ou des choses comme ça
et je vais taire le nom des entreprises
mais j'ai en tête des boîtes
ou justement
c'est en testant
certains plans de reprise
qui sont aperçus que
ah bah merde, on a totalement oublié
de rajouter tel ou tel brick
sur l'infra de Spare
qui est censé reprendre l'activité
bamin
en fait ça marche pas pour autant
et pourtant ça a coûté
des sous etc
donc il faut pas que ça soit le jour J
qu'on teste le truc
il faut être préparé avant
mais comme tout le monde l'a répété
avant
ça coûte du pognon
de prendre ce temps de tester
et de re-challenger
de repasser dessus
t'as utilisé un terme
infras de Spare, je suis pas sûr que tout le monde
connaisse ça, est-ce que tu peux le définir s'il te plaît
globalement
c'est la traduction
de Spare c'est de réserve
en fait, de secours
c'est une infra de secours
qui en gros n'est jamais vraiment
utilisé
et qui s'active au moment
où votre infra principal
tombe et vraiment casse
on pourrait imaginer par exemple
que vous doublez votre infra
mais de façon totalement passive
donc l'infra de Spare
ne prend jamais de trafic
le jour où l'infra principal est chaos
entre guillemets vous changez le DNS
du point d'entrée
et puis hop ça re- marche
comme avant
et donc du coup souvent quand vous présentez ça
des financiers de votre boîte
ils disent mais attends tu vas doubler ton infrastructure
pour un truc qui va jamais être utilisé
t'es sérieux
donc c'est
l'idéal de pouvoir
faire ce genre de choses mais par contre
enfin c'est l'idéal, je veux dire parce que c'est facile
on a tout à dispo et on a très peu de choses
à changer en cas de problème
mais en vrai
financièrement c'est très très très cher
donc c'est toujours
un peu ce qui est évoqué d'Amir sur le curseur
de est-ce que
le prix vaut
vraiment le coût
par rapport au chance que ça arrive
etc.
c'est ça c'est ça, c'est ça que tu as besoin
par rapport à ton business
quel point ton business est
potentiellement critique pour le coût
mais en fait puisque tout le monde est chez Amazon
et que Amazon ne tombe jamais en panne
tout le monde le sait est-ce que ça sert vraiment
à quelque chose imprat
alors Amazon sont les premiers
à dire et c'est pour le coup
ils le disent dans les formations en bien grand
ils te disent tout peut casser compris chez nous
et ils l'assument totalement et ils disent bah
ce qu'on fait c'est pas un métier
d'absolutisme en mode
on fait quelque chose ça marchera tout le temps
il y a de l'aléatoire et des choses qu'on ne peut pas prévoir
par définition dans nos métiers
et nous on s'assure en fait de vous fournir
tous les moyens pour que vous
facilement vous puissiez
faire des
des plans, appliquer des plans d'action
complexe
ou des choses pour pouvoir basculer
sur d'autres régions et d'autres zones
en cas de problème mais derrière ça reste
quand même un engagement de vous et dans aucun cas
où vous allez être sur une infrastructure
et vous serez en mode
bah du coup je suis un phony circle out
à part s'il fait vraiment du passe
vous lui filer juste l'application
autrement quand vous êtes en une infrastructure
c'est pas parce que vous êtes un phony circle out
que c'est totalement son ressort
ça a à vous de le designer d'une bonne manière aussi
merci beaucoup
cette précision j'attendais que tu la fasses
parce qu'en effet on entend souvent
ce genre de choses
vas-y Nicolas
je vais rebondir un petit peu là dessus
je me suis rendu compte justement
au moment de cette incendie où j'ai voulu
renforcer mes infrastructures
qu'il y avait un gros problème de culture
par rapport à ça en France
parce que tous les grands
cloud public donc
ovh, scaleway et les autres
en fait n'ont pas de zones
donc une zone c'est quoi ?
c'est au sein d'une seule région
avec des réseaux suffisamment rapides
pour l'échange de données
on a des zones totalement séparées
donc c'est en gros un data center
qui est totalement isolé de ces deux copains
avec du réseau
de l'électricité
des salles etc
donc si on a un data center qui brûle
on a
les deux autres qui continuent à fonctionner
de manière totalement autonome
mais c'est aussi les groupes proies des clines
gérer un data center c'est vraiment compliqué
et quand on veut réduire les coûts
on va mutualiser des choses
entre data center
et c'est un petit peu le problème d'ovh
à Strasbourg c'est que la partie
énergie était mutualisée entre
plusieurs data centers donc même si on a qu'un seul
qui crame il y a tout qui tombe
donc c'est quand même assez problématique
et en fait
on rentrera peut-être un petit peu plus dans le détail
tout à l'heure mais globalement pour faire une
infrastructure résiliente
il faut 3 data centers
totalement indépendants
sinon on risque d'avoir des problèmes
et en France j'ai fait le tour
de tous les grands providers
au mieux on a 2 data centers
au sein de la même
région en étangentie
c'est à dire la France
là dessus je serai un petit coup de gueule
c'est vrai qu'il y a un des gros soucis d'ovh
c'est que la dénomination des data center
notamment chez ovh chez d'autres cloud providers
européens en général
est très mal faite et là dessus
autant je suis d'accord que Amazon
c'est Amazon, c'est américain etc
pour le coup eux ils ont une vision très claire
des choses tu sais qu'à une avabilité zone
c'est un data center à un endroit
que c'est à temps d'espace d'un autre data center
qui est une autre avabilité zone
et que tout ça c'est regroupé par région
ils ont une hiérarchie et une nomination qui est très complète
et qui est pour le coup ultra compréhensible
alors que pour beaucoup de cloud providers
notamment français c'est un gros bordel
là ovh on a eu le cas notamment
où les régions
par rapport aux idées de région
c'était du Strasbourg mais c'était des idées différents
donc on se disait potentiellement
c'est des data centers différents donc ils sont isolés
ce qui n'était pas le cas et ça c'est un vrai
problème de visibilité et qu'en aujourd'hui
on travaille à rendre des infrastructures
résilientes et etc
on a besoin d'être au clair là dessus
parce que c'est la base de tout
même si on fait plus de hardware
au sens on raccue très rarement
la plupart d'entre nous
on ne va plus dans les data centers pour hacker
des serveurs on a besoin d'encore une vision claire
de ce qu'elle a dessus
je voulais juste rajouter un tout petit truc
par rapport à ce que Damir disait
sur Amazon qui expliquait que ça pouvait casser
en fait Amazon
comme tous les services de genre là
ils ont des slés qu'on a évoqué
plus tôt et donc du coup
dans les slés
c'est pas 100%
officiellement quand vous allez chez eux
si vous regardez ça
vous savez que ça peut casser
c'est bon de se le rappeler en effet
parce que dans la conscience
collectif le cloud
c'est automatiquement 100%
mais non c'est pas le cas donc faites votre travail
faites des pares, des PCA
Nicolas un dernier mot avant qu'on passe à la suite
oui le coup de gueule
sur OVH que je vais compléter un petit peu
c'est pas parce qu'on a Gravelin 1
et Gravelin 2 que c'est des hyperviseurs différents
donc
des fois on peut avoir
deux régions différentes OpenStack
et les 2 VM sur le même hyperviseur
donc quand j'ai appris ça
j'ai fait des bons partout mais du style horrifié
et par rapport à Amazon
c'est pareil on se dit
oh bâtard c'est trop bien
c'est haut de dispo machin, regardez bien
les cases à cocher, c'est par défaut
une base de données RDS par exemple
vous avez plus ou moins de sauvegarde
mais en général c'est disponible
que sur une seule zone
donc si vous voulez que ça soit haut de dispo
faut cocher la case multi zone
si vous voulez que ça soit vraiment haut de dispo
vous cochez la case multi régions
oui c'est pas le même prix pour la voirmille en place
c'est ce que je vais dire
et bizarrement ça coûte beaucoup plus cher d'un seul coup
justement puisqu'on en est
à parler de cloud etc
on peut se demander du coup
pourquoi tout le monde le fait pas
et pourquoi tout le monde le fait pas
il y a un truc que vous l'avez dit
si on est haut de dispo
si on a pensé notre infrastructure pour être haut de dispo
finalement on n'a pas besoin de faire un PRA
non ?
non c'est un data center
qui brûle ça arrive pas
donc effectivement
pas besoin de bras
je sais pas y a des armes incendies dans le data center
donc ça peut pas brûler
moi c'est toujours pareil
ça dépend du niveau qu'on veut
il y a un moment
c'est quand même bien d'en avoir un
parce qu'on n'est jamais à l'abri qui se passe quelque chose
il y a un risque dans lequel on n'a pas parlé
mais qui à mon sens aujourd'hui est très important
c'est des risques notamment des crypto locoires
moi imaginez vous aujourd'hui
votre infra se fait avoir
et pour une raison X ou Y
vous avez un crypto minor
qui a verrouillé tous vos serveurs
vous avez boire plusieurs sites géographiques
vous avez intérêt à savoir où sont vos sauvegarde
qui sont isolés
comment les restaurer et comment repartir de zéro
parce que si vous décidez des machines qui sont encore infectées
ça va se reproduire
donc pour le coup c'est un risque auquel on parle pas
mais qui est de plus en plus vrai aujourd'hui
et qui montre l'importance de tous ces plans
parce que encore une fois comme on le disait
j'insiste beaucoup là dessus mais parce que j'ai déjà vécu des situations
et on ne se sent vraiment à ce moment-là
c'est des situations de crise
où on n'a pas envie de réfléchir à
est-ce que je dois la renoncer ça d'abord
ou ça d'abord
et comme Zéro1 faut tester
parce que si en plus de la panique
vous êtes dans la découverte de
à merde ce service là il fallait de backup aussi
à merde ce service là en fait mon backup il est pas consistant
ça va être une horreur
vous allez vivre un enfer
on a oublié de sauvegarder la basquie cloque
ah bah oui forcément
c'est pas drôle
bon bah maintenant qu'on sait qu'il faut en faire
dans tous les cas
comment est-ce qu'on fait finalement
comment est-ce qu'on soit un père
Nicolas tu nous as dit ça peut commencer
par un petit plan est-ce que justement
tu peux nous dire par où on commence
quand on a vraiment jamais fait ça
globalement on va essayer
d'imaginer le scénario le pire
c'est à dire qu'on a vraiment tout perdu
alors le tout perdu
ça c'est tout est relatif
est-ce que tout le data center a cramé
moi j'étais parti du postulat
que toutes mes installations
étaient complètement vierges
donc je récupère des machines
qui sont vierges de toute installation
donc déjà c'est
referens sort de pouvoir récupérer ces machines
donc est-ce que c'est du dédié du cloud et ainsi de suite
une fois que t'as ta VM
tu refais tourner ton système
de gestion de configuration
puis après tu redescend tes backups dessus
et normalement t'as récupéré
ton service
c'est facile à dire comme ça
parce que le plan
est écrit en 2 minutes
j'en ai
je l'ai évoqué en 30 secondes
vous avez le plan
et ça y est de faire la même chose chez vous
vous vous rendrez compte que c'est un petit peu plus compliqué que ça
est-ce que
ça doit tourner à 100% comme
comme la production habituelle
ou est-ce qu'on peut avoir un mode
dégradé genre on roule sur 3 roues
etc
je crois que Damir t'as des pistes
là dessus sur le mode dégradé
oui c'est vrai comme vous le savez
il y a une question de
coup entre guillemets
et parfois la solution c'est de se dire
on accepte que notre service
ne sera pas disponible à 100%
qui sera plus lent
ou notamment la mise en place de file d'attente
je prends cet exemple là parce qu'on a eu le cas
notamment avec Dr.Lib qui a subi un gros pic
il ne faut pas oublier que si vous avez
un moment où vous savez que
pour une raison x ou y
vous avez une situation
vous pouvez être en face d'une situation
en tout cas où vous ne serez plus capable
d'assumer le service totalement
vaut mieux se dire je mets en place
soit une file d'attente soit un mécanisme
pour ralentir certaines fonctionnalités
ou les désactiver temporairement
plutôt qu'afficher une passe 500 aléatoire
aux personnes en fait ça sera toujours
plus agréable pour vous et aussi pour votre business
en fait les gens vont avoir un impact de moins grand
je préfère demain vouloir me connecter un site
avoir une page qui me dit désolé on a un souci
il faut attendre une minute
qui annonce la couleur plutôt qu'un site qui a un répondant 500
ou j'ai aucune info
je vais devoir aller potentiellement
sur Twitter ou autre pour avoir
qui a gueulé en premier en tagant la marque
et la marque qui a dit désolé on a un problème technique
sans donner plus de visu
moi personnellement je préfère ça et je pense que c'est une bonne vision
aussi à avoir de se dire
assumer tous nos services on peut pas mais
assumer une partie on peut peut-être une partie
la partie vitale qui doit avoir quelque chose de au moins les ressources statiques
et pouvoir
derrière en fait offrir au client
une expérience qui soit
quand même possible même si dégradé
et dans le dégradé quand tu prenais l'exemple
de Dr.Lib c'est je peux pas prendre de nouveaux rendez-vous
mais je peux au moins afficher le planning
chez le médecin et savoir quand est-ce
ce moment rendez-vous
alors du coup ça me fait penser que
si on est en mode dégradé ça marche beaucoup mieux
si on a des infrastructures qui sont assez simples
en tout cas c'est plus facile
à mettre en place et quand on commence
à mettre en place des infrastructures
donc là d'où chez un provider pas Claude
on prend des VM etc
bah penser toujours
commencer par une infrastructure simple
maîtriser là, faites votre PRA etc et puis petit à petit
rajouter des briques petit à petit
tout le monde fait pas comme ça
eh ben écoute non
parce que moi j'ai eu des clients qui voulaient
par exemple
j'avais un client qui voulait absolument
déployer dans OpenShift
et il me disait
bon bah on veut déployer en blue green
et à l'époque
Argo CD n'existait pas
donc il a fallu tout penser
pour déployer en blue green
je lui ai dit mais tu es sûr que tu veux pas déployer en Valor
au début et tout on n'a même pas encore lancé le projet
là on n'a même pas, non non je veux du blue green
ok bon bah ok
et après il me dit
à moi et demi après mais c'est pas fini
je fais bah non c'est pas fini tu veux du blue green
on sait pas faire, il faut bien tout penser
bon bah voilà c'est
non mais c'est oui penser simple
et faites évoluer c'est à dire
vaut mieux avoir un truc qui marche
qui marche à te vaut mieux avoir un skate
que espérer avoir un vélo
en tout cas
c'est ma philosophie maintenant
est-ce qu'on me touche
c'est le même provider quand on veut faire
un PRA ou est-ce qu'on a d'autres solutions
tout dans le même data center
dans le même provider
sur le même switch histoire de
bien optimiser tout ça
non pour le coup oui c'est ça que je peux paraître
évident mais on essaye
si jamais vous faites travailler sur du cloud
vous essayez d'avoir de
prévoir un deuxième provider
si c'est vraiment important ou au moins prévoir
une deuxième zone géographique en tout cas
même si ça c'est assez limite on a bien vu avec oVh
où le
la pays et le panneau de contrôle avaient aussi
quelques difficultés suite au problème là
mais c'est mieux de prévoir et c'est pareil
si jamais vous faites de l'infrastructure
data center ou d'infrastructure physique
je prends l'exemple très con
si vous faites un raid avec 15 disks
avec 5 disks
prenez pas les mêmes modèles et la même série
de disks en fait parce que
si il y a un défaut de fabrication et c'est déjà arrivé
tellement de fois et qui pètent au bout
de je sais pas moi de
2 ans ils vont tous péter en même temps
et votre raid vous aurez un raid mais le raid
c'est pas une sauvegarde et vous aurez plus de data
quoi ça sera fini donc c'est des choses
qui peuvent pas être basiques mais c'est bien de les rappeler aussi
essayez de multiplier les
providers à chaque endroit
je vais t'empérer un petit peu là-dessus
c'est justement là où on peut taper
dans le coup c'est
si t'as un provider open stack
y'a un provider AWS
pour donner donons que j'utilise régulièrement
les apis sont totalement
différentes la manière de provisionner
tes infrastructures sont radicalement différentes
donc c'est là où ça peut coûter
très cher alors que si
tu fais de l'open stack
tu peux au mieux avoir
2 régions différentes
globalement ça marchait plutôt bien
chez OVH même quand ça a cramé
je crois
et sinon bah des providers
open stack y en a partout
comme quoi utiliser des standards
du marché c'est bien aussi
je sais plus quel fournisseur
en France c'est compatible open stack
mais je crois qu'on en a quelques-uns
on avait Claude Watte
feu Claude Watte et aujourd'hui on a Hopla Claude
par contre je vous le dit
pour avoir fait une migration
Cloudwat OpenStack, Cloudwat OVH, l'OpenStack d'OVH il n'est pas 100% compatible avec la
solution Open Source, ils ont un réseau propriétaire, le réseau sur lequel
j'arrête pas de pester à chaque fois. Donc même dans ce cas là, si on est chez OVH,
il y a des briques quand même qu'il faut adapter, mais on en a quelques-uns et on a aussi des fournisseurs
OpenStack qui ne sont pas vraiment publiques, c'est à dire il faut aller les voir et puis
nous montrent des OpenStacks où il est cher pour nous. C'est pour ça qu'il y a une grande
importance comme je disais de voir par rapport au coup parce que si vous voulez
multiplier provider globalement ça va avoir une approche multi-cloud et c'est vrai que ça
comme le dit Nicolas, c'est quelque chose qui est très vite très cher, très chronophage et qui
demande une grosse vision et vraiment d'avoir des dépenses et une vision qui va dans ce sens là.
Donc c'est une situation extrême qui vous permettra d'être très résilient, par contre
d'un point d'arri, ça vous demande un gros investissement.
Et typiquement si vous voulez faire du multi-cloud, posez-vous vraiment la question de comment vous
voulez démarrer votre projet. Par exemple si vous êtes chez Google, vous avez du Firebase,
Firebase c'est pas disponible chez d'autres fournisseurs. Donc si Google est totalement
indispensable, votre application sera totalement indispensable. Si vous faites du post-grèche
QL, la probabilité d'avoir pu obtien fournisseurs qui fait post-grèche QL sur la planète est très
faible et dans le pire des cas vous pouvez le faire vous-même. Mais ça vous impose de choisir
un truc qui est peut-être moins optimisé par rapport à votre besoin initial. Ça va pas
faire plaisir aux développeurs parce que c'est pas hype mais au moins ça marche. Et surtout
quand vous prenez un standard du marché comme post-grèche, le jour où vous avez besoin de
récupérer chez vous, vous pourrez. Nicolas, tu voulais nous parler de l'analyse de risques
tout à l'heure. Est-ce que tu peux nous en dire deux mots ? Oui parce que c'est ce
qui va nous permettre de bien définir ce qu'on va vouloir mettre ou pas dans nos bras. Donc
une analyse de risques globalement c'est quoi ? C'est notre risque, c'est la probabilité
d'une occurrence multipliée par le coup que ça peut avoir. Alors c'est une analyse
vraiment simpliste mais globalement on va se dire la probabilité que je fasse un RM-RF
sur mon serveur, c'est quand même relativement élevé. Le coup c'est quoi ? Ça dépend de
ce que je vais supprimer sur mon serveur et qu'est-ce que je vais pouvoir mettre comme
contre mesure ? Je fais des sauvegarde. C'est la version hyper simple, hyper rapide. Et après
à l'autre extrême, c'est qu'est-ce qui peut m'arriver ? J'ai mon data center qui crame complètement
et la pays de mon provider a cramé avec. Donc du coup mon provider est devenu totalement inaccessible,
et il va falloir que déployeur. Donc la contre mesure c'est quoi ? C'est que je fais deux installations
totalement séparées avec des providers totalement indépendants et les sources qui sont
dupliquées, les données qui sont répliquées et ainsi de suite. Du coup maintenant qu'on a ça,
on peut définir son PRA et l'écrire et je vois qu'on a pas mal de choses dans nos notes de
l'émission pour préparer ça. Et notamment commencer par se poser la question de la supervision.
Qui veut nous en parler un petit peu de la supervision pour préparer le PRA ?
Moi je veux bien démarrer le sujet. C'est que avant de se lancer, enfin à faire des choses complexes
sur comment je vais reprendre mon activité etc., il faut être en mesure de pouvoir donner de l'information,
enfin être en mesure de récupérer de l'information pour pouvoir dire si l'activité se passe bien.
Et donc du coup ça passe par tout ce qui est supervision, monitoring et le suivi d'activité
en général. Il me semble qu'on a fait un épisode il y a longtemps sur le sujet. Mais c'est la première
chose à faire, c'est donc d'être hyper carré là dessus parce que si vous n'êtes pas en mesure de
dire que tout est cassé ou pas ou si c'est juste une partie etc., et d'avoir ce genre d'information
de façon très très actuelle, fiable et d'avoir donc des alertes là dessus. En fait tant que vous
n'avez pas ça, vous n'allez jamais savoir quand est-ce qu'il va falloir lancer votre PRA.
Bon après j'imagine que si tous vos clients vous appellent vous allez peut-être vous douter de
quelque chose. Mais justement pour éviter d'avoir ça et être proactif sur le truc,
ça passe par une brique de monitoring et de suivi d'activité. Je ne sais pas ce que vous en pensez.
Damir ? Ah non je suis plutôt d'accord. On soit le monitoring et l'observe habité dans ces moments
là. C'est quand même chose d'ultra critique déjà pour identifier bien où est la panne entre
guillemets ou sur quel secteur etc. et pouvoir y réagir convenablement. C'est la première chose
à avoir. C'est alors la bonne information au bon moment pour pouvoir analyser en fait dans
quelle situation on est parce que c'est pas possible d'avoir une réaction qui soit précise et
efficace si on n'a pas les bonnes informations pour le coup. Etant votre analyse de risque pensez
aussi au cas où votre serveur de monitoring crame en même temps que votre infrastructure. Donc
il faut monitorer votre monitoring. C'est ce que j'allais dire en fait le mieux c'est de ne pas
mettre la supervision au même endroit que l'infrastructure. Chose que tout le monde fait
pratiquement pour être plus près mais il faudrait le sortir en fait. Après on peut avoir plusieurs
niveaux de supervision. On peut avoir la supervision de toutes les données et on peut
avoir juste une supervision de statut de nos services qui soit déporté par exemple. Non non
je voulais dire c'est je me souviens qu'on avait abordé ce sujet dans le précédent podcast donc
il faudra mettre le lien sur les réseaux mais parce que justement utile il y a plein de
services les plus connus c'est genre Pingdom ou StatueCake qui justement permettent d'avoir
cette taille tiers pour valider que depuis l'extérieur votre service est ok ou pas par exemple.
Ouais on va terminer les missions par les pages de statut justement Nicolas.
Et comme vous en êtes à payer un service comme Pingdom pour vérifier que ça marche de l'extérieur
rajouter le monitoring de votre serveur Zavix, PromETU, ses compagnies pour être sûrs qui
sont toujours fonctionnelles parce que si vous n'avez pas d'alarmes c'est pas forcément que tout va
bien. Mais pas avoir d'alerte et aussi un signe à prendre en compte.
Qu'est ce que comment on fait pour est ce qu'on doit tout mettre dans son PRA,
est ce qu'on doit mettre tous les environnements, est ce qu'il y a des services dont on peut se
passer, comment on fait pour sélectionner des services qu'on va mettre dans son PRA ?
Dépendre ce qu'on veut j'ai envie de dire moi j'aurais de temps après c'est très personnel pour
le coup je dis pas que c'est une bonne pratique, une mauvaise pratique ou autre.
Pour moi le chose qui est primordial c'est de définir ce qui est pour ce qui ramène de l'argent
dans le business donc du coup l'applicatif ou le service une fois qu'on s'est occupé de ça après
c'est à voir s'il y a vraiment besoin d'aller à autre chose, à voir selon les risques et
des choses là c'est quand même relativement rare je pense d'avoir besoin en fait de récupérer des
environnementes tests de devs et des choses comme ça qui peuvent se permettre d'être, je dis après
que c'est relativement rare après des panthours pareil un dataille de la boîte mais pour moi le
primordial en tout cas c'est la production après le reste c'est à voir en fonction vraiment qu'à
par cas des besoins et des choses comme ça. En fait je faisais l'amou c'est justement parce
qu'en faisant ton analyse de risque tu vas définir de quoi tu veux te prémunir et si on prend
encore une fois le cas extrême le datacenter complet à brûler si tu fais tes mises à jour
d'applicatif en faisant un geek push geek pool restart t'as pas besoin d'avoir ton environnement
de test dev etc. Si tu as un pipeline ou quand tu fais ton geek push ça le déploie dans un environnement
test, intégration, test, tactique, tactique et ainsi de suite et que tout se fait en automatique le jour
où ton infrastructure de prod va cramer avec tout le reste tu remontes ta prod tu te rends compte
qu'il y a un léger petit truc à corriger et qu'il faut aller mettre ça sur le serveur,
personne n'a accès en ssh ou truc parce que c'est du contenu en deux coeurs et ainsi de suite
du coup il va falloir que tu puisses utiliser ton pipeline donc soit tu prévois le fait de pouvoir
faire un geek push et puis publier directement en prod en se cuisant toutes les étapes,
ce qui peut être dangereux mais il faut pouvoir le débrayer quoi soit il faut que tu puisses avoir
une solution pour publier tes environnements de pipeline en même temps que ton environnement
de prod. C'est pour ça que je disais en fait il faut voir au cas par cas quoi si c'est lié à ça ou pas
donc pour le coup et puis on s'est lié c'est bien c'est important après moi j'aurais quand même
temps dans la mesure du possible faut aussi voir si jamais vraiment ça prend quand même un temps
de faire tout ça ça peut aussi ne pas être déconnant justement comme tu disais de se dire on a une
procédure aussi de backup qui permet de se cuisent les tests et déployer au moins une fois sans les tests
pour qu'on se que d'autres buts c'est quand même de minimiser le downtime quoi donc pour moi
c'est les tests et les choses comme ça faut essayer de s'en passer au moins temps pour avoir
pour déployer une première version quitte encore une fois ce que soit dégradé et après revenir à la
normale. C'est ce que je décrivais tout à l'heure mon client qui veut un bras et qu'on le fasse en
multicloud etc. Typiquement il a des environnements de démo et de staging qui sont pas forcément
super important par contre c'est l'environnement qu'ils appellent test pour eux et qui leur permet
de tester un déploiement, une nouvelle fonctionnalité et ainsi de suite pour eux c'est vraiment critique
et c'est la première étape du pipeline donc en gros pour ce client là je lui conseillerais de
déployer l'environnement de test et l'environnement de prod et de pouvoir squiser ses pipeline
intermédiaires. Du coup si je comprends bien il faut qu'on défie sa scénario critique de tout ce
qu'on veut faire tout ce qu'on a identifié et après on met tout ça dans une documentation on fait
on fait nos scripts on itère petit à petit sur l'ensemble des scripts au fur et à mesure du temps
parce qu'on va les tester etc mais comment est-ce que finalement on pourrait tester Spera régulièrement
est-ce qu'on doit absolument le tester de bout en bout d'un coup est-ce qu'on peut prendre des morceaux
comment est-ce qu'on s'y prend ? Moi je peux vous raconter ce qu'on a fait chez Tukentoko qui
était en fait donc la première fois qu'on a testé le PR on l'a pas testé sur effectivement
l'intégralité de la prod par contre on l'a testé sur la vraie prod avec des vrais gens impactés mais
qui étaient des partenaires qu'on avait prévenu auparavant et de façon totalement impromptue
on a fait comme si un avion s'était craché sur le serveur et puis moi comme j'avais écrit le
PRA et que je savais comment ça marchait c'était pas intéressant que ce soit moi qui le fasse donc
j'ai attendu de voir comment mes collègues agissaient et du coup si ça intéresse on en a fait un
article qui explique un peu comment ça s'est passé mais ce qui est intéressant c'est que ça a
permis de on parlait de tout à l'heure de le tester en amont pour se rendre compte s'il manque
des choses de quoi que ce soit bah c'était exactement le cas globalement on s'en est plutôt
bien sorti mais il y a clairement des choses sur lesquelles qu'on aurait pu être peut-être
automatisé ou enfin des des ajustements et c'est grâce aux tests qu'on s'en aperçoit et aujourd'hui
si on refait le même test je pense que le temps de convergence il sera il sera plus plus
intéressant parce que justement on est on est un petit peu mieux armé et donc on peut se rendre
compte de tout ça sans cracher l'intégralité du truc mais mais par contre pour en tout cas pour
nous ça a été intérêt et je pense que c'était important de le faire pour de vrai parce que ça
permet aussi de voir la gestion du stress la gestion de l'événement la communication
si on va en venir après mais c'est quand même un élément important et et donc du coup en
pétant un serveur entre guillemets de l'infra bah on peut déjà avoir une très bonne vision enfin
ça dépend bien entendu des contextes et tout mais déjà en pétant juste un petit bout on peut
déjà avoir une bonne idée de si on est dans le juste ou si on est totalement à côté de son sujet
quoi et ben merci mais je pense qu'on peut parler directement de communication puisqu'on arrive
justement au moment où on a testé notre paire on on a appère à mais il y a un problème donc on
applique notre paire mais comment est-ce qu'on communique auprès des gens comment est-ce qu'on
est qu'on met en place cette communication là et comment on s'y prend le truc c'est que la
première chose je pense et en tant qu'utilisateur c'est un truc qui je pense ne touche tous c'est
qu'on il faut être transparent je pense que tout le monde sait que les choses peuvent péter encore
plus avec ce qui s'est passé chez obh récemment maintenant c'est bien ancré dans les esprits
que un data center qui prend feu c'est pas une blague ça peut vraiment arriver et donc du coup
il faut être transparent sur sur sur ce qui se passe sur sur l'impact réel de de la panne
etc et il faut être transparent donc non seulement donc en interne auprès de ces de ses équipes tech
etc mais aussi alors je excusez moi je vais reprendre dans mon cas mais aussi en par rapport à
l'équipe support à l'équipe des chefs de projet à l'équipe des commerciaux pour que pour pas que
ce soit leurs clients qui disent et il n'y a rien qui marche qu'est ce qui se passe et qui disent
attends je vais demander à mon équipe non en fait si c'est ça vous avez déjà perdu donc il faut
vraiment être transparent vis-à-vis de ça et idéalement il faut avoir de quoi communiquer de
façon publique et de façon publique donc il y a il y a quand même aujourd'hui pas mal de services
de page de statut qui permettent par exemple d'avoir de la communication comme ça en
en 1 to mini qui en mettant même des des statuts intermédiaires pour dire où j'en
est dans le rétablissement d'une panne ou quoi que ce soit qui peuvent être hyper intéressant
mais mais du coup enfin le moins ce qui me parait important c'est ça c'est d'être transparent en
vers toutes les personnes qui sont impactées et essayer de donner un maximum de visibilité on a
droit de se tromper on a ça droit de casser mais par contre essayer de le cacher ou faire ce qui
comprend pas c'est quelque chose qui sera jamais toléré par par vos clients et d'ailleurs je
on peut discuter de comment ça s'est passé pour ovh par exemple mais moi j'ai eu le sentiment
que ça avait été plutôt bien géré en termes de communication très vite on a compris que c'était
vraiment la merde très vite ils ont dit si vous avez un plan de reprise d'activité les gars c'est
pas le point qu'il faut l'activer alors pas de chance ça arrivait à une heure où on pourra parler
des astreintes après mais voilà et c'est mais en fait très vite on a su tout ça donc en fait
il y avait pas de je vais peut-être pas activer mon plan peut-être que ça va remarcher vont
trouver que non en fait là très vite on savait c'est la merde faites quelque chose c'est à vous de
vous prendre en charge et je pense que c'est vraiment un point important un point important de
ce type de plan la communication et la la transparence autour de ça en donnant des des
des estimations du temps de rétablissement je sais pas comment vous vous avez pu rencontrer
ou faire face à ça Nicolas peut-être ouais alors deux choses la première c'est que même si je
t'as passé souvent sur ovh je trouve que c'est génial d'avoir une boîte comme ça en France et
surtout depuis le tout début ils ont une transparence qui est vraiment exceptionnelle
beaucoup de boîte y compris des boîtes américaines pour les prendre modèle sur eux bon après des fois
c'est peut-être le canal de communication qui est pas adapté le twitter d'octave c'est pas terrible
surtout qu'il a blacklisté la moitié de twitter mais bon coucou octave pensem des
blacklisté pour le prochain data center qui crame et sinon le pour la partie communication pour moi
il ya un autre truc qui est super important c'est que ça soit une personne qui soit dédiée à la
coordination et la communication parce que on peut pas à la fois rétablir le service parce
qu'on est déjà dans le stress pour remonter tous les trucs rapidement et communiquer en même temps
c'est il faut que c'est une personne qui coordinate qui communique avec le reste de la boîte
avec les clients extérieurs qu'on a un service de com que ça soit ces personnes-là qui fassent
l'interface entre les deux et que il soit sur le pont et qui viennent régulièrement demander
où est-ce que c'en est mais qui laisse les gens travailler et quand on lui dit j'ai pas le temps
bah c'est il fait le tampon pour laisser ceux qui doivent bosser bosser et pour éviter le stress
la répétition c'est super bien parce que faites semblant que votre infrastructure a cramé
répétez vos plans régulièrement et si vous le faites il y en a une répète de votre bras ou même
une bascule réelle tous les mois le jour où ça va cramer ça sera comme si c'était une répétition
pour le coup je pense que je ne vais pas me délaisser c'est vrai que c'est important il pense pas
mais d'avoir un référent qui va savoir qui contactait à qui demander qui va être capable
aussi d'absorber bah généralement quand vous avez un truc qui pète on va vous poser 15 fois la
même question parce qu'il ya 15 personnes qui vont avoir la même question donc c'est important
qu'ils mutueillent tout ça et qu'ils disent bah là j'ai une réponse et qu'il a peu d'âpe cette
réponse et c'est important qu'il puisse identifier si les bonnes personnes et bon communicant et
aussi surtout ça on n'a pas dit mais d'avoir des gens qui soient capables d'identifier les
personnes pour aider parce que la personne qui est sur l'incitement l'aura peut-être besoin de l'aide
de personnes d'autres services qui connaissent mieux les problèmes ou mieux le serveur parce qu'il
y a un problème c'est important de les identifier très rapidement ces personnes qui ont cette
connaissance pour qu'ils puissent être opérationnels sur le problème à un moment dans l'idéal si vous
êtes en présentiel avoir une oire room c'est quelque chose qui se fait beaucoup dans le cas
d'incidence c'est à dire se rouler dans une salle pour avoir une facilité de communication ça marche
faut pas se le cacher ça simplifie quand même la communication si jamais vous êtes à distance
ou ou autre faites un channel matermost slack ou whatever au moins pour pouvoir échanger entre
vous et vous donner des informations directs même si c'est des doutes même si c'est des choses comme
ça pour que vous entre vous pouvez déjà échanger directement et après une personne sera référente
pour communiquer à l'extérieur au niveau de l'entreprise après au niveau encore plus au-dessus
pour le coup mais c'est important et hésitez aussi pas à communiquer dès le début je pense que
c'est important et roi ne le disait c'est pas parce que vous n'avez pas identifié la route
cause et ça ça on verra au post mortem le première chose c'est d'abord dire on a vu un
incident on est dessus pour déjà comme c'est ben problème d'image et aussi pour rassurer dire
il ya un problème et vous inquiétez pas on est au courant on est déjà dessus c'est un côté
rassurant qu'on communique pas tout de suite pas tout tout de suite c'est normal les gens de façon
ne s'y attendent pas on va pas se le cacher donc c'est intéressant de faire ça je pense que
c'est comme comme zéhenicolas si vous êtes bien habitué vous faites vous répétez souvent les
personnes ont chacun un rôle bien identifié votre paire et est un minimum relu et revue vous devriez
vous en sortir très bien pour le coup je compléterai même en disant que il vaut peut-être mieux
solliciter un petit peu trop de personnes quand on a un incident suffisamment grave quitte à ce que
la personne soit là juste pour regarder et que elle soit vraiment disponible au moment où on
en a vraiment besoin parce que c'est c'est des périodes on peut pas se permettre de perdre 5
minutes le temps que le gas connect et ainsi de suite et effectivement c'est c'est du slack mais
aussi en audio au minimum que les gens soient tout le temps là à pouvoir s'entendre parce que
alors ça moi je l'ai vécu c'est pendant un incident tu peux pas te permettre de lire ton
ta messagerie instantanée parce que ça clignote déjà dans tous les sens avec le monitoring et
tout le monde qui te demande si c'est cramé ou pas donc celui qui coordonne il y aussi ses canaux
et dit attendez peut-être que là il y a un truc intéressant à regarder et du coup c'est lui qui
fait le tampon entre le entre toutes les sources d'information et les personnes qui interviennent
voir même s'il ya une personne qui fait l'opération parce qu'on peut pas se litter entre
plusieurs personnes qu'à partage son écran il y a peut-être des personnes qui vont identifier des
problèmes et des messages d'erreur et c'est toujours plus vite que copier-collé dire regarder
le message d'erreur donc ta raison prisé de l'audio voir un partage d'écran ou des choses comme ça
oui c'est vrai que je n'ai pas parlé de partage d'écran mais ça c'est ce qu'on avait fait aussi
en l'occurrence c'était moi qui tapais donc du coup j'ai partagé mon écran j'ai fermé quelques
anglais au passage personne m'en a voulu mais du coup effectivement tout le monde voyait ce que
je faisais et le fait de pouvoir avoir des gens qui font du peering c'est attention là tu vas
peut-être faire une connerie parce que quand tu es dans le stress c'est là où tu fais le plus de
connerie donc avoir une personne sur ton entre guillemets sur ton dos qui vérifie tout ce que je
fais c'est aussi super important je l'ai oublié ça je reprends la parole pour parler de la
communication et des pages de statut pour donner quelques pistes aux personnes qui voudraient en
mettre en place et qui n'auront jamais mis en place donc commencer par des services en ligne c'est
plus rapide pour ça et notamment il y a le plus connu qui est status point aillot qui est utilisé
par gitlam notamment ou alors le petit dernier que j'ai découvert il n'y a pas longtemps qui est
up down point aillot et qui a la particularité d'être fait par une société française et ça
c'est utilisé par froggit donc vous pouvez vous pouvez y aller on a cité aussi statut cake mais je
sais pas si statut cake ça permet aussi de faire des pages de communication et une fois que vous
avez mis en place vos petits services en ligne et que vous voulez internaliser vos pages de statut
parce que c'est bien et c'est cool vous pouvez passer sur des solutions libres et notamment il
y a cachette hq.aillot qui est utilisé par cléberclod et frava soft donc autant dire que c'est un type
pas mal si c'est deux entreprises enfin si cléberclod qui est l'entreprise et frava soft qui est
l'association qu'on connaît tous l'utilise après je pense que vous en utilisez peut-être d'autres
mais je pense que c'est les principales celle là en tout cas si c'est le que moi j'avais envie de vous
dire et er 1 tout à l'heure t'as parlé d'un truc intéressant j'ai trouvé et j'aimerais bien que tu
reviennes dessus tu m'as dit il ya nos clients qui nous demandent comment est ce que est ce que
vous avez appara à ce que vous est ce que vous le faites finalement comment vous vous communiquez
votre pera enfin comment vous communiquez autour de votre pera pour vos futurs clients ou vos
clients est ce que vous avez une page dédiée vous expliquez bah voilà donc quand il ya un
problème on fait ça etc enfin jusqu'au vous allez dans la communication avant que ça arrive en fait
ouais alors il ya ils ont effectivement au fil pas les scripts et la doc tel qu'elle est utilisé en
interne mais on communique sur sur sur plusieurs points le fait mais après ça rejoint un petit peu
tout ce que tout ce qu'on fait dans la mouvance des vops avec le fait de tout est automatisé tout
est scripté on fait rien à la main etc du coup ça rassure sur le fait d'avoir la capacité à
reconstruire vite et et comment dire et après on a on a des comment dire genre nous on sait donner
des informations sur la capacité à enfin le temps de reconstruction de certains de nos clients
enfin de de la stack du client suivant la quantité de données etc et donc du coup pour nous c'est
facile de dire au client bah si demain comme si c'est passé chez ovh il ya un truc qui crame voilà
le temps qu'on va mettre pour re-build ta stack et et ça clairement c'est des choses qui nous
sommes demandes qui nous sont demandé par bon et mais par contre non tu as raison c'est pas non
plus un truc technique très très pointu c'est plus un engagement avec les les différents points
sur lesquels nous on peut rassurer donc l'automatisation le fait que ça soit testé c'est pardon ça c'est
quand même quelque chose d'important si on dit pas juste on saura faire on dit que là en l'occurrence
tu vois le par exemple la reconstruction de stack etc c'est un truc qu'on fait quasiment toutes les
semaines en fait donc du coup on a des stats très précises on sait on sait on sait communiquer
assez facilement là dessus et c'est ce genre d'information qui qui nous sommes demandé par
nos clients et qui moi en tout cas tel que tel que je le vois et je le perçois quand je discute avec
eux ou les retours que j'ai des commerciaux c'est que c'est des choses qui rassurent énormément et
qui créent clairement de la de la confiance et donc de la plus-value pour la boîte quoi
et ben merci et je propose qu'on clôture sur un petit point tu l'as abordé tout à l'heure le post mortem
une fois qu'on a eu nos problèmes et qu'on a fait notre paire à etc et qu'on qu'on est revenu à
froid sur l'incident qu'on a tout anonisé qu'on a trouvé les causes du problème c'est bien en
fait de le décrire d'en faire un document soit de le garder pour nous soit de le communiquer à
l'extérieur peut-être en enlevant des informations sensibles et c'est ce qu'on appelle le post mortem
qui nous permet après de nous améliorer sur cet incident là pour faire des choses différemment
à l'avenir pour éviter qu'on est qu'on est à nouveau ce genre de problème et comme ça fait
déjà une heure qu'on discute et que le sujet est encore foisonnant parce qu'on n'a même pas parlé
d'infrastructure à ce code et j'aurais bien aimé qu'on n'en parle mais tant pis je vous propose
qu'on s'arrête là et qu'on clôture l'épisode et moi c'est le moment que je vais choisir pour
rappeler à nos auditeurs et auditrices que le podcast il est diffusé en ccba y est ça donc
c'est créatif comme un en licence libre donc vous pouvez l'utiliser vous pouvez le découper
vous pouvez en faire ce que vous voulez vous pouvez le diffuser la seule chose qu'on vous demande
c'est de nos crédités et de nous prévenir que vous le faites ce sera avec bon coeur parce que c'est
très intéressant et je vais vous laisser le mot de la fin tous les trois pas tous en même temps
sinon ça va être compliqué mais on va commencer par Nicolas quel est ton mot de la fin sur cet
épisode ma foi très long c'était très intéressant je pense que ça va permettre d'ouvrir un petit
peu l'esprit à nos auditeurs et donc planifier tester ces coules merci d'amir et toi quel est ton
mot de la fin la première ligne de tout documents de reprise d'activité de paire et tout ça
ça doit toujours être ne paniquez pas jamais ne paniquez jamais c'est dur er oen ton petit mot de
la fin super échange j'ai trouvé ça hyper intéressant en plus je ne connaissais pas de
trois trucs que t'as cité pour les pages de statu par exemple donc on en apprend toujours donc c'est
cool et moi le truc que je rajouterai c'est pour aller dans tout ce qui a été dit jusque là mais
c'est vraiment rassurez vous en le testant et du coup comme ça ça validera le ne paniquez pas
cité par belge et pensé à tester tout le temps merci d'avoir écouté radio dévops n'oublie pas de
nos télébizodes plus la note sera élevée et plus sera mis en avant dans les applications tu peux
aussi le partager ça nous aidera à le diffuser et à rendre le mouvement plus visible si tu as
envie de discuter du mouvement alors rejoins nous dans la communauté des compagnons du dévops à bientôt
la balade au diffusion des compagnons du dévops est produit par l'hydra