C'est d'abord une culture. Quand on est en DevOps, on prend tout le monde.
DevOps et agile font effectivement partie de la même famille.
Sa virtualisation applicative, c'est très bien.
Aujourd'hui, ça nous prend 10 minutes et un café.
Ce n'est ni être dev, ni être DevOps. C'est avant tout de la communication.
Ce mouvement DevOps, c'est tout simplement drivé par la communauté et endorsé par les entreprises.
J'ai adopté une démarche DevOps.
Le développement agile, on a accéléré des poignements.
Ça amène une clarté sur le travail de...
Être dans une démarche d'amélioration contient votre trou face à des...
Ça, oui, naturellement ensemble, ça donne des résultats contrêts.
DevOps.
L'objectif individuel, ça s'atteint alors qu'une ambition, ça se partage.
Bonjour à tous et à toutes et bienvenue dans un nouveau numéro de DevOps.
Alors, ça fait un petit moment qu'on ne s'est pas eu.
Et aujourd'hui, j'ai la chance d'avoir deux nouvelles personnes.
Alors, je dis nouvelles parce qu'elles sont nouvelles dans les podcasts DevOps.
Mais en fait, je suis sûr que vous les connaissez si jamais vous traînez un tout petit peu sur Twitter.
Et on va commencer Honor aux femmes.
À Texan et toi, c'est Sylvain Morange dans la vraie vie.
Et je suis technicien de système réseau et data center dans une petite boîte qui s'appelle Aquarelle.
Super.
Et avec moi, on a aussi...
Alexie Lambert, ingénieur système réseau actuellement chez Boborama.
Super.
Et donc, Guillaume Lutron, et je suis toujours indépendant des DevOps, expert Kubernetes, etc.
Et j'en passe.
Et alors, comme vous l'avez un peu vu au titre de l'épisode, et même aux invités que j'ai,
on va parler réseau.
Et ça tombe bien.
On est donc le mardi 5 octobre 2021.
Et hier, il y a eu un événement.
Alors, c'est la première fois à cette ampleur là et je pense pas que ce soit la dernière,
mais en tout cas, on va pouvoir en parler.
On a eu le grand Facebook Down.
Et peut-être je vais laisser Cécile, vu que tu as fait un live tweet hier,
à ses conséquents, nous résumer un peu ce qui s'est passé le 4 octobre.
Ça marche.
Je vais commencer parce que j'ai vu de mes propres yeux.
Donc, ça a commencé vers 17h, il me semble, où j'ai eu les premiers tweets...
Enfin, je le connais surtout d'ailleurs.
J'ai vu les premiers tweets qui disaient, ah tiens Facebook, ça marche plus.
Puis Instagram, ça marche plus.
Et WhatsApp, ça marche plus.
Je me suis dit, ok, il se passe quelque chose.
Et puis, je commence à faire mes petites investigations réseaux.
Et puis, je me rends compte que le nom Facebook ne résout plus en DNS.
Donc, ça veut dire que le serveur DNS ne peut plus faire la correspondance
entre Facebook.com et l'adresse IP associée.
Donc, ce qu'il y a pour conséquence, on ne peut plus accéder à Facebook simplement.
Et donc, au fur et à mesure de mes recherches,
je me suis rendu compte que Facebook n'annonce plus ses propres adresses IP.
Donc, j'ai fait une analogie sur mon live tweet,
si vous voulez lire, c'est sur mon compte ataxiannetwork.
En fait, il faut imaginer que Facebook, c'est une île parmi tant d'autres îles
qui sont représentées par les opérateurs et les faillis,
ce qui vous donne internet chez vous, globalement.
Et chaque petit île est reliée par des points différents
avec un protocole qui s'appelle BGP.
Et en fait, ce qui s'est passé avec Facebook,
c'est qu'apparemment, ils ont fait une confliteur de configuration
sur leur routeur, donc les routeurs qui permettent de transiter
les paquets entre les différents réseaux.
Et en fait, ce qui a eu pour conséquence,
que tous les ponts qui allaient vers Facebook,
vers les autres îles, si on reprend ma métaphore,
se sont cassés.
Donc, Facebook, c'est à se retrouver complètement isolé
dans son propre réseau.
Et plus personne dans le monde avait accès à Facebook.
Donc, je suis en train de lire mon live en même temps
pour retrouver un peu le contexte.
Donc, peu à peu, au fur et à mesure des tweets,
on retrouve un...
Là, je relime mes tweets,
et on retrouve quelqu'un sur Reddit,
qui est apparemment interne à Facebook,
qui raconte que les personnes n'ont plus du tout accès
à leur routeur à distance
et sont obligées d'aller sur place
pour aller réparer les routeurs à la main
en branchant un câble
et en repechent la confe à l'ancienne.
Et donc, après, on retrouve plein de conséquences.
Par exemple, chez les cloutes-faires,
comme les DNS, les serveurs DNS Cloutes-Faires et Google,
qui se prennent énormément
d'amplification DNS
parce que toutes les personnes
et tous les applications qui utilisent Facebook
retentent en boucle d'accès d'accès à Facebook
et sauf que Facebook ne répond plus
et donc, ça fait la boucle infinie, simplement.
Et donc, du coup, ça s'est résolu
vers 23 heures à peu près,
heure française, bien sûr,
où peu à peu, Facebook a re-routé
le accès à ses routeurs
et a pu réannoncer ses routes
et reconstruire les ponts vers les autres opérateurs.
Et donc, finalement,
l'incidence est finie vers minuit à peu près
où, peu à peu, tout le monde a pu
avoir accès à Facebook, Instagram et WhatsApp de nouveau.
Voilà, à peu près pour l'incident.
Donc, ça fait combien de temps dedans, à peu près ?
Alors, ça a commencé vers 18 heures
et ça finit vers minuit, donc,
6 gros 6 heures, à peu près.
Un quart de journée
pour l'un des plus grands sites mondiales,
c'est un exploit.
Oui, et puis, enfin, ce n'est pas le seul, en plus.
Alors, moi, j'aurais un avis là-dessus
que j'ai un peu exprimé maintenant,
c'est que c'est Facebook,
et Instagram, et WhatsApp.
On ne parle pas de petits acteurs,
on ne parle pas de 3 petits logiciels.
Ce n'est pas des pages...
pas des blogs, quoi.
Oui, bien sûr.
C'est ça que je trouvais assez hallucinant.
Si on revient
dans le déroulé,
il y a un truc que je trouvais assez drôle,
c'est que la première chose qu'on a vu,
c'est que les DNS étaient morts.
Il y a toujours une phrase l'un d'entre nous,
« It's always DNS »
et encore une fois, « It's always DNS ».
Après, pour le coup, je tiens quand même à préciser
que les DNS n'étaient qu'un symptôme.
Le vrai problème, c'est
l'annonce
de ces routes
qui permettent à accéder aux DNS.
Donc, ce n'est pas parce qu'on connaît
l'adresse d'un correspondant
si toutes les routes
pour accéder à ce correspondant sont coupées,
on est bien embêtés.
Oui, mais c'est marrant.
Au début, on a cru que c'était les DNS.
Encore une fois, les DNS,
au final, ça se retrouvait à être un peu plus grave que ça.
C'est ça.
Donc là, tu avais fait l'analogie tout à l'heure sur l'île.
Donc, c'est les AS.
Il faut voir, je suis un nubi en réseau,
à cette échelle-là.
Je sais configurer un réseau local,
classé,
un truc nul.
À ce niveau-là, je n'ai jamais touché à du BGP.
J'ai jamais voulu toucher à du BGP.
J'ai fait office du candidat.
En face de deux personnes qui s'y connaissent,
1000 fois plus que moi dans le domaine.
Vous, là,
comment vous avez l'habitude de vous gérer ?
Si jamais on le voit,
on va essayer de repartir de votre expérience
avant de repartir sur le problème que
il y a eu à Facebook.
Vous, vos expériences des AS,
quand vous gerez ça, ça se passe comment habituellement ?
Avant de pouvoir
parler de la gestion d'Étouday,
je vais vous parler de la gestion d'Étouday.
Je pense que nos interlocuteurs
vous donnent savoir finalement, c'est quoi Internet ?
En fait,
pour beaucoup d'entre vous,
Internet, c'est un joli nuage
dans un diagramme.
Je pense qu'on a beaucoup de gens techniques qui vont nous écouter.
Mais avant tout,
Internet,
il y a une filiale
administrative,
on ne rentrera pas forcément dans les détails,
mais il y a un
protocole de routage,
BGP.
Chaque acteur qui souhaite
avoir
son petit bout d'Internet
va avoir pour rôle
de se connecter
avec d'autres acteurs
d'Internet
par le protocole BGP
pour ce qu'on appelle
annoncer leur route, donc
leur petit morceau
d'adressage IP, permettant
d'accéder à leur ressource
via le protocole BGP.
Via différents types
d'interconnexion, des interconnections, on va dire,
via des grands acteurs qu'on appelle
les transitaires.
Ces transitaires, en fait,
c'est des gros acteurs
de l'ombre type Zayo,
Telia, NTT,
Kojant, qui a beaucoup fait parler de lui
avec Free, dans la communauté.
Ou
en direct
selon
l'intérêt commun.
Ça c'est marrant d'ailleurs.
Je fais juste une petite abartée.
T'as parlé de communauté
et c'est vrai que c'est une communauté
quand on n'est pas dedans.
Là, s'il n'y a pas un développeur front
réact qui nous parle,
il doit se sentir perdu.
C'est un monde que j'entraperçois
par des tweets,
par des choses comme ça, mais c'est vrai que c'est un monde
à pas à pas.
Je digresse un peu.
C'est pour ça que je vais essayer de faire
vraiment le candid, parce que
je pense qu'il y a certaines choses qui, pour vous,
paraissent normales et qui ne le sont pas
pour tout.
Tu as parlé du protocole BGP,
qui permet de l'annonce de route.
On annonce qui gère quoi, qui fait quoi, etc.
Vous,
concrètement, comment vous gérer ça ?
Est-ce que vous en gérer un ?
Est-ce que c'est...
Pour le coup, dans le cadre
de mon employeur,
mon employeur dispose
de son petit bout d'internet,
avec ses propres précifixes
et son numéro de identification
sur internet, ce qu'on appelle
communément le numéro d'A.S.
Ces ressources étant attribuées
par la partie administrative qu'on appelle les rires.
Le rire
qui gère les ressources en Europe étant le RIP.
Ok.
Donc
c'est vrai que, étant donné
la taille de l'A.S.
sur lequel
je travaille,
nous on est principalement
interconnectés via
des transitaires,
qui, eux, ont la connaissance de
ce qu'on appelle la full view, donc l'ensemble
des routes de l'internet qui correspond
aujourd'hui à peu près à 800 000 routes.
Ok.
Après, ce qu'il faut voir, c'est que tu as plusieurs niveaux
d'opérateurs,
de gens qui ont leur petit bout d'internet,
ce qu'on appelle le terrain, le terrain
le terrain, c'est à peu près ce qu'ils connaissent
tout le monde et toutes les routes.
Et après, tu as les tiers 2 qui sont un petit peu en dessous,
qui vont se connecter au tiers 1
pour avoir le reste du monde, et puis les tiers 3
qui sont tout en bas et qui
vont appeler des tiers 2, qui vont appeler les tiers 1
et tu as les routes qui descendent de petit à petit.
Et donc vous, vous êtes à peu près à quel niveau
c'est s'il que tu as un
en presse ? En fait, je suis sur deux niveaux,
professionnellement, je suis à peu près au milieu.
Donc, j'ai mon employeur qui, lui,
va prendre des routes avec des gens au-dessus, donc
des tiers 1 ou des tiers 2,
et moi, il va
avoir d'autres clients qui vont eux-mêmes
prendre
les routes de mon employeur.
Et donc du coup, nous, on est un petit peu au milieu
et puis moi, au niveau personnel, moi, je suis tout en bas
donc c'est moi qui prends les routes
juste pour moi et je ne relis plus à personne de l'autre derrière.
En fait, j'acte sur deux niveaux différents,
professionnels.
Ce qu'il faut bien comprendre avec ça, c'est
que ce qui caractérise un petit peu les relations
sur Internet, c'est de savoir si on est
un A.S. feuille, donc on est un A.S.
qui redistribue ses propres préfixes
sur Internet et qui
accepte la foule vieux, donc l'ensemble
des routes de l'Internet,
ou si on est un A.S. qui fournit
du transit, donc qui fournit
la foule vieux d'Internet ou une partie
de celle-ci, à d'autres A.S.
Soit tu es en bout de chaîne, soit tu es au milieu
de la chaîne, soit tu es en haut de la chaîne, en fait.
C'est un peu un arbre, peut voir un peu comme un...
Voilà. Ok, et donc
vous, vous en êtes...
Enfin, plutôt que vous m'avez dit à peu près,
toi t'es tier 2 aussi.
Pour le coup, moi je suis plutôt un A.S. feuille,
je suis un A.S. qui est consommateur d'Internet
et pourquoi
mon employeur dispose d'un A.S.
c'est pour pouvoir établir sa propre politique
de routage, donc d'être indépendant
d'un opérateur type orange SFR
et finalement
si SFR se casse la gueule
étant donné que
j'ai...
si j'achète un lien chez SFR
et mes IP chez SFR, si SFR se casse la gueule
je n'ai que mes yeux pour pleurer.
Si j'ai mes propres ressources et que je les annonce
auprès de plusieurs transitaires
si l'un de ces transitaires
décide de tomber, comme il y a plus à
avoir quelques années avec un gros incident
qui avait impacté le VEL3
si tous les acteurs de l'Internet se sont mobilisés
d'ailleurs à ce moment-là pour couper
les différents points d'accès avec le VEL3
le service
s'est rétabli de ce fait-là.
Si jamais je résume bien
il y a quand même une relation
de confiance qui se fait
j'ai l'impression...
la seule analogie que je connais dans ce type
de confiance-là, c'est un peu ce qu'on a avec les certificats
où on a des certificats donc racines
qui sont un peu trustés par n'importe qui
et après on a des décomposés de ces certificats-là
et chacun a son petit bout de certificats
trustés par quelqu'un au-dessus.
Sauf que là en plus tout le monde se discute
avec tout le monde dans les...
Ça a l'idée en fait, le réseau
surtout en BGP c'est basé sur la confiance
et en fait on compte sous les autres pour pas faire de la merde
et pas annoncer n'importe quoi n'importe qui.
C'est un petit peu le...
pour faire l'analogie c'est un petit peu
chacun et chez soi
mais c'est pas parce qu'il est facile
de crocheter une serrure
que on va forcément
aller crocheter la serrure du voisin
mais c'est pas pour autant qu'on ne verrouille pas sa porte.
Ok.
Et donc là quand on parle donc si on revient
donc l'événement de Facebook
donc clairement il y a eu un problème
d'annonce donc c'est quoi
est-ce que c'est un problème venu
de l'aise donc
c'est un problème où ils ont envoyé
quelque chose de mauvais
ou est-ce qu'ils ont eu un problème enfin...
Enfin ils ont juste plus rien envoyé en fait
ils ont arrêté d'envoyer leur route et du coup
ils étaient plus visibles sur internet simplement.
C'est comme si leur bout d'internet
n'existait plus aux yeux du monde.
D'accord et donc les câbles physiques
étaient présents mais plus personne
n'avait la connaissance de leur propre adresse.
Et donc ça en fait ça veut dire
qu'il faut toujours envoyer l'adresse qu'on a
ou est-ce qu'ils ont envoyé on n'est plus personne
enfin c'est un peu différent.
Alors le protocole BGP
est un protocole normalement
qui est iteratif
c'est-à-dire qu'on n'en voit
que les modifications
qui sont apportées au réseau.
Néanmoins
des informations dont on a notre disposition
suite à une maintenance
applicative il semble que les sessions
ont été coupées.
Donc les anciennes routes
ont été désapprises par les
les équipements
et
ces pertes d'informations
se sont propagées de proches en proches
jusqu'à ce que l'ensemble
des routeurs d'internet n'aient plus
accès à Facebook.
Ok, oui c'est
un gros peu pas
ce qu'il faut voir
parce que j'ai bien envie d'avoir votre expérience
là-dedans. Est-ce que déjà
ça vous est arrivé ?
Est-ce que c'est quelque chose de classique ?
Parce que ça a dû arriver à Facebook
ça a dû arriver à d'autres acteurs
Est-ce que vous avez déjà des cas personnels
ou des cas connu ?
Des bugs sur internet
personnellement ça m'est pas arrivé
mais il y a eu par le passé
des gros incidents. Il y a eu
des bugs d'implémentation dans le protocole
qui a fait qu'une partie d'internet
suite à l'exploitation
de ces bugs de protocole s'est retrouvée
ingénieble par le passé.
Il y a eu aussi
comme on disait tout à l'heure, BGP
quand même un protocole qui est basé sur la confiance
il y a ce qu'on appelle vulguément
des hijack, des personnes qui annoncent
des préfixes qui ne leur sont pas
attribués parce que certains acteurs
certains acteurs sur la chaîne
n'ont pas fait leur due d'illigence
et n'ont pas filtré ce qui lui aurait dû être
filtré. Donc
tout l'objet de BGP aussi
c'est que c'est
c'est le point qui est le plus
fondamental. C'est que même si
dans l'incident
qui nous
fait discuter aujourd'hui
c'est de la seule responsabilité de facebook
mais
la santé d'internet
tient à l'ensemble des acteurs de l'internet
et d'ailleurs on peut
citer de ce point là Claude Flair
qui est un gros acteur
qui essaye de pousser
à une
modification
des bonnes pratiques de l'internet avec
quelque chose qui s'appelle le RPKI
qui pousse les acteurs à signer
les préfixes qu'ils annoncent
sur internet. D'ailleurs il y a eu
un incident avec Claude Flair il y a pas
quelques mois genre Verizon
Claude Flair non ?
Verizon avait annoncé les IP Claude Flair
à la place ou que Mulem Verge je sais plus
quelque chose comme ça ? J'avoue
que je n'ai pas connaissons de l'incident
mais j'ai vu quelque chose comme ça il y a quelques mois
Bon il faut voir qu'en fait des incidents
en BGP ils en arrivent quand même assez souvent
de manière plus ou moins
legit. On sait que
des fois genre la moitié du trafic d'internet se retrouve
en Chine pendant quelques secondes
ou quelques minutes comme ça magie
mais
mais là en fait ce que j'aimerais
avoir c'est que j'aimerais essayer de me mettre dans la place
d'un ingénieur de chez facebook
donc voilà demain je
vous place avec votre connaissance
qui est forcément parcellaire parce que
on n'est pas chez facebook, aucun de nous 3
ne travaille chez facebook et on n'a travaillé chez facebook
mais voilà on va dire que vous êtes à peu près dans votre boîte
et il se passe ce problème là
qu'est ce que vous faites ?
qu'est ce qui sans doute s'est passé ?
qui n'a pas marché ? qui n'a pas fonctionné ?
vous avez une alerte
il est 14h
14h heure de chez vous
Pour répondre à cette question
je vais revenir à un incident qui n'est pas lié à BGP
mais qui est lié au réseau
en somme et qui est finalement un bon représentatif
de l'incident
j'ai un collègue qui par le passé
sur un équipement
a tapé une mauvaise commande
et
c'est retrouver l'équipement inaccessible
dans le pire des cas
le dernier moyen de recours
pour accéder à l'équipement et ce que facebook
était amené à faire
c'est se déplacer, brancher vulgèrement
ce qu'on appelle un cap console
sur l'équipement pour aller enlever
la ligne votive
mais normalement c'est l'élément
de dernier recours
tout bon réseau bien conçu
a un réseau qu'on appelle
vulgèrement le réseau out of band
a opposé au réseau inbound
qui est le réseau qui rend le service
le réseau out of band
c'est le
c'est le réseau un petit peu pour citer
avec l'industrie nuclear
avec le générateur de
dernier secours qui a été posé pendant le grand carénage
c'est le réseau qu'on va utiliser
pour avoir accès
à l'équipement soit via un protocole IP
soit via un protocole série
par IP
pour aller remettre l'équipement en service
ce protocole out of band
ce réseau out of band
chez facebook était
avait un couple hache fort avec le réseau inbound
qui l'a rendu inaccessible
donc les ingénieurs de facebook
n'ont pas pu
riverte rapidement la conf
qu'ils avaient mis en place
deuxième élément qu'on peut lire
sur les différents réseaux sociaux
il semblerait que des employés
n'aient pas pu avoir physiquement accès aux équipements
parce que les badgers étaient connectés sur le réseau de facebook
qui lui-même tombait
c'est ce qu'on appuie beaucoup tout à l'heure
parce que facebook a ses propres data centers
ça c'est jamais je comprends bien
la plupart du temps
il y a un prissateur tiers
qui est celui qui possède
le bâtiment et qui lui gère les badgers
et gère les accès
là on a un bâtiment qui est facebook
avec un réseau facebook avec tout qui est connecté
facebook
les bureaux entre guillemets tiers tiers de facebook
étaient reliés sur les badgers
et même
pour avoir des informations
sur d'autres gaffes hames
il est assez fréquent quand ces gaffes hames
s'installent sur des des tiers
qui ont des contrats particuliers
signés avec le data center
pour que le gaffame gère ses propres accès
à ses cages
donc à ses équipements
et donc potentiellement
un défaut de couvasionnement entre son accès physique
à l'équipement
et le réseau qui permet de manager celui-ci
c'est marrant parce que ça c'est
on peut comprendre pourquoi ils le font
c'est traditionnellement
je veux gérer mes accès
je veux avoir une certaine sécurité etc
on a vu que la sécurité
donc en fait
à lutter contre des risques
pourquoi ils veulent avoir un réseau à eux
c'est limiter les institutions
limiter tout ça etc
ils voient que cette limitation du risque leur a créé un nouveau risque
qu'ils n'avaient pas prévu et pas anticipé
après en opération au quotidien
il faut bien avouer
que dans la gestion quotidienne
même d'une infrastructure
système quand on a affaire
avec certains grand data center
dont les gens du milieu je pense
auront repenu le nom à Paris
il est des fois très risqué
de faire appel aux personnels
de proximité qui des fois s'avèrent plus nuisibles
qu'utiles
oui mais là pour le coup, pour être bien
dans une optique
dans une optique de protection des assets
d'un grand provider de cloud
je peux comprendre qu'ils aient envie de se
protéger de la médiocrité
du data center dans lequel ils sont hébergés
oui mais tu vois là ils se sont
trop protégés et c'est leur rapport télépho
je pense qu'ils n'ont pas trop le bon équilibre
entre leurs propres réseaux
et ils voulaient absolument tout faire eux-mêmes
et avoir un petit peu
quelque chose à côté qui leur permet
en cas de défaillances complets
comme on a pu voir hier
puis leur sauver la vie
ce qui leur a manqué c'est une vraie procédure
de dernier recours
parce que les incidents du genre arrivent
j'ai eu l'occasion
de mettre en place une automatérisation
réseau c'est quelque chose
qui évite beaucoup d'erreurs
du quotidien parce que c'est
un filet de sécurité
mais c'est quand l'automatisation
elle-même devient défaillante
les impacts
qui sont accourus sont forcément
beaucoup plus importants
et c'est exactement ce qui s'est passé avec facebook
l'automatisation en elle-même
a créé un nouveau risque
oui parce qu'on a pas, enfin je ne sais pas
c'est bien écouté quand on a parlé de tout à l'heure Cécile
mais les causes exactes du pourquoi
ça s'est passé
il semblerait qu'on est commencé à avoir des pistes
j'ai lu en travers tout à l'heure
le rapport complet de facebook technique
avant de commencer
de ce que j'avais lu hier et aujourd'hui
c'est en fait apparemment une erreur de conf
qui s'est propagée à cause de l'automatisation
et du coup ça s'est propagée
sur le réseau entier de facebook
ça m'a même l'air d'être
un problème de test
ils étaient en train de faire des tests
ils étaient en train de faire du monitoring
on en parlait tout à l'heure en off
apparemment un ingénieur
quelqu'un a passé une mauvaise commande
et ils avaient un système d'audit qui permettait
de détecter en cas de mauvaise commande
d'aborter le truc et d'allumer la configuration
et c'est ce système d'audit
a fail et du coup a propagé
totalement la mauvaise configuration partout
c'est un peu ce que j'ai lu en travers tout à l'heure
juste avant dans le rapport facebook
l'exemple que je connais
peut-être qu'il ne parlera pas beaucoup parce qu'il est assez vieux maintenant
c'était un bug qui avait eu
github, github avait été down pendant
2 jours, un jour et demi je crois
on devait être en 2012, quelque chose comme ça
ça fait un petit moment
et on avait eu la cause
c'était qu'ils avaient eu
un système automatique
donc github est énormément corrélé
couplé à MySQL
et ils ont une base master
une base slave
vous avez compris
ah oui je l'avais lu sur un point de vue
ce qui se passait c'est que la base
donc il y a eu un split brain
un truc classique, un split brain entre
le maître et l'esclave
et le
système automatique
a considéré que
le système esclave devait passer maître
et en fait ils sont retrouvés à avoir un double
un double maître
ce qui est le truc le pire
parce qu'il y a continué à avoir des écritures
pendant un petit moment où en fait
des gens ont continué de poucher
etc ils ont continué de faire des écritures
et ils sont retrouvés, heureusement ils ont
tombé assez vite le service
et ils sont retrouvés après à devoir
recorréler les écritures dans les deux masters
pour aller en sorte dans les mains
pour les faire converger, c'est pour ça qu'ils ont mis
un jour et demi
et en fait ce qu'ils ont dit ensuite c'était que
à partir de maintenant ils ne feraient plus d'automatisation
ils préféraient peut-être avoir
perdre 15 minutes
le temps que quelqu'un se lève, le temps que quelqu'un intervienne
sur le service
et passe la base slave en master
mais en étant sûr que l'autre master
est vraiment tombé et pas juste
ne voit plus l'autre
mais il préfère maintenant ne plus automatiser
cette charge-là. C'est tout le problème
des tie-breakers qui
je pense sur ce cas bien précis
aurait dû situer sur un 3ème
site correctement
interconnecté avec les deux premiers
et c'est un cas
pour le coup on parle ici d'un cas classique
on rappelle qu'un quorum
c'est 3, c'est pas 2
si jamais vous avez 2 datacenters
vous avez aucune résilience
à partir de 3 qu'on a une résilience de 1
je crois que c'est un truc qu'il faut appréhend seulement dire
parce que je reconnais plein qu'il y avait 2 datacenters
et qu'ils se disaient qu'ils avaient une redondance
non c'est 3, oubliez pas
je trouve que quand on disait alors ça se plie brène
et puis les deux passent en mode entre guillemets
oui ou alors les deux sont tombés
parce que l'un ne voit pas l'autre etc
on peut avoir un arbitreur
moi là ce que je trouve
ce que je trouve assez intéressant de l'un de l'autre
c'est qu'on a vraiment Facebook
on en disait un peu off
qui rend dans une intégration verticale totale
c'est à dire qu'il maîtrise absolument tout
du datacenter jusqu'au démon BGP
qu'ils ont écrit eux-mêmes
ah oui rappelons-le
c'est des routers en maison qui ont de sonner
des routers, enfin tout le réseau
il fait maison
pour le coup ils font ce qu'on appelle de l'open networking
donc un équipement réseau
qui dispose certes
de matériel spécifique
mais dont l'OS de base est purement libre
et sur lequel on vient rajouter
des composants selon le service que
l'équipement doit rendre
mais des composants soit libre
soit développer maison
on parle de
de gestion et ça me fait penser à ce que j'ai lu hier
j'avais lu hier
qu'en fait il y avait les gens qui étaient dans le datacenter
qui n'avaient pas la compétence de remettre en route le hauteur
et les gens qui pouvaient
mettre en route le hauteur n'avaient pas la compétence
d'aller en datacenter et brancher le câble
en fait je trouvais ça super marrant que les compétences soient tellement séparées
et qu'en fait t'es obligé d'avoir
plusieurs, plein d'équipes différentes
pour pouvoir saisir un problème
c'est tout le problème de l'effet slow des grands groupes
et en fait c'est un truc que tu retrouves beaucoup dans les grands groupes
mais que dans mon job
ou dans d'autres jobs, genre 15 dans une boîte
tu ne retrouves pas en fait et je pense que c'est le problème
des gros groupes où en fait la compétence
se sépare beaucoup trop
et à un moment où tu as une panne
c'est obligé d'avoir 15 personnes pour réparer la panne
là là on est dans des questions organisationnelles
c'est d'ailleurs
un grand, à l'un des grands principes
des jobs de gestion
c'est que quand la structure
grossit, il vient un temps
où les frais de gestion de cette structure
sont plus importants que les gains
apportés par la structure
c'est marrant d'ailleurs ça me fait penser
là je réagis en direct
c'est
alors je sais pas
c'est une urbaine légende ou je sais pas
mais ce qu'on appelle la tout pizza team
c'était de dire je crois que c'était un manager
chez Spotify qui disait
pour n'importe quel problème je dois être capable de mettre
deux pizzas dans une salle
et que les gens puissent résoudre le problème
ce qui disait qu'en gros une équipe
doit pas être plus grande que 8 personnes
ça dépend du... la taille des mangeants de pizza
mais on avait
on avait un peu ça
et
et en fait
là c'est vrai que c'est quelque chose qui était assez impressionnant
c'est qu'en fait on avait
des gens en parler sur Twitter hier en se disant
imaginer qu'il y a peut-être un gars
qui est encore à l'intérieur des locaux
qui est un technicien qui n'a jamais touché à une machine de sa vie
et il y a des gens qui à travers la paroi
en gueulant à travers un mégaphone
sont en train de lui dicter des commandes
à taper dans un équipe en réseau
parce que le badgeuse était en panne
c'est ouf
d'imaginer ça
et étant donné l'environnement de data center
c'est assez peu probable
étant donné que la plupart des data center
sont plutôt proches de la cache de Faraday
donc aucun
moyen de communication et beaucoup de bruit
d'ailleurs tu parles de cache de Faraday mais ça me fait penser
qu'hier on a découvert aussi que tous les services
non seulement Facebook, Instagram et WhatsApp étaient dons
mais les services internes de Facebook aussi étaient dons
donc ça veut dire que les gens ne pouvaient pas communiquer
via les messages internes
et étaient obligés de communiquer par SMS
ou via des messages de mail externes
j'irais même beaucoup plus loin
c'est bien d'avoir un système de secours
qui ressemble au télés avait un réseau hier c'est de secours
c'est encore mieux quand ce réseau de secours
était testé régulièrement
mais là on rentre
dans une problème de gestion
de la sûreté
comme on peut voir dans l'industrie aéronautique
ou ferroviaire ou même nucléaire
c'est que la cause
d'un accident est multifactorial
et ici c'est une erreur de conf
l'impossibilité
d'accéder physiquement à l'équipement
et le fort couplage entre
le réseau in-band
et le réseau out of band
et les mécanismes
de protection
qui ont été défaillants
en fait ça a fait un tout
ça a fait une panne impressionnante qui a duré
du ducleur
il serait absolument inconvenant
d'associer cette simple erreur
aux techniciens qui a tapé une mauvaise commande
l'erreur est organisationnelle
et non liée à un individu
et justement quand on vient
c'est pour ça qu'on est dans devops
il y a un petit lien
quand même avec tout ça
on n'est pas que dans du réseau
j'avais
je vais donner mon expérience un peu personnelle
par rapport à Facebook
j'essaie de retrouver les e-mails que j'avais eus
mais ça remonte un peu
ça devait être en 2012-2013
j'avais déjà été contacté par Facebook pour rejoindre leurs équipes
et leurs motos c'était
Mufas Bluxings
ce qui était très différent
parce que moi dans mon premier boulot
j'avais un manager qui était arrivé devant moi
et qui m'avait posé un papier
parce que j'avais fixé un serveur XMPP
à l'époque
mais que j'avais fait tomber le service pendant 15 minutes
il m'avait mis un papier
me disant
don't think when it's not broken
il m'avait posé ça
devant mon bureau
j'étais encore stagiaire
à ce moment-là, à cette époque
et quand j'avais vu ce truc de moto de Facebook
j'avais été un peu impressionné
j'ai fait un premier entretien avec eux
mais le jour où ils m'ont demandé toutes les sorties de SH
qu'est-ce que ça fait
dollars pour l'interrogation
dollars machin, dollars trucs etc
j'ai vite arrêté
et quelques années plus tard
j'avais été recontacté par l'équipe
de recrutement de Facebook
et là pour le coup ils avaient rajouté quelque chose
c'était Mufas Bluxings
but make it working
il y avait eu un but
et maintenant il y a même plus
c'est même plus le moto
il y a même plus le moto
oui ça existait
comme tu disais, en 2012-2013
et que depuis quelques années ils avaient arrêté
parce que
j'aime bien le concept
d'expérimenter
on en a déjà parlé en off plusieurs fois
expérimenter fait des choses mais
il faut que ça marche à la fin
je comprends beaucoup l'intérêt
mais en fait là ils sont dans une situation
où c'est trop risqué de faire quelque chose
par porte cassé
en fait ils ont l'effet inverse de l'époque
et ils sont dans cette heure dedans
ce dernier point ça veut dire simplement
qu'on remet
l'utilisateur en face
face à ses responsabilités
et en fait c'est la culture
c'est la culture du blâme
et donc c'est pas quelque chose qui pousse
à faire évoluer les choses
c'est pas quelque chose qui pousse à essayer de se remettre
en question
et d'essayer de
corriger les problèmes de fond
parce que ça implique souvent des chantiers
qui sont compliqués et des chantiers
qui sont risqués
et là la question c'est
donc je sais que sans doute dans les équipes
de facebook il y a quand même
dans les équipes de dev il y a quand même du sre
en mode poussé donc cette culture là peut-être
qu'elle existe encore dans plein d'endroits
moi c'est vraiment genre sur cette partie
réseau j'ai l'impression qu'en fait c'est un contexte
un peu particulier moi de mon expérience
dans les sociétés où je suis passé qui étaient un peu
un peu grosses et qui faisaient de la publicité
et qui commencent par un C
et ben on avait c'est un peu ce problème
là aussi ce truc où l'infrastructure réseau
c'était un peu un truc un peu
un peu différent avec des pratiques différentes
avec un esprit différent
est-ce que à l'heure actuelle vous pourriez
implémenter cette culture là donc t'avais dit
qu'il fallait avoir des procédures de test ou des choses comme ça
est-ce que demain
si jamais je vous donne
l'infrastructure de facebook
est-ce que comment vous implémenteriez
ce type de
de logique d'apprentissage
de test de chaos engineering comme on le dit un peu
dans l'univers netflixien
tout le problème du réseau
c'est que quand quelque chose est
cassé bien souvent ça se voit
et ça a des impacts qui sont
extrêmement conséquents et des impacts
qui sont
qui sont en vagues
prenant un exemple je vais revenir
sur l'incident technique
mentionné précédemment
mais sur la suite de l'incident
c'est que le fix
en lui-même de l'incident d'un point de vue
réseau c'était retirer une ligne de configuration
ce qui littéralement
prend deux minutes il y a plus de temps
pour se déplacer pour enlever la ligne
que de retirer la ligne en elle-même
la vraie question c'est que cette ligne a eu
des impacts réseaux et par exemple sur le système
cause des spits de brain
et que donc il y a une culture
du risque en réseau qui est beaucoup plus importante
et surtout que par exemple à l'échelle de facebook
tu n'as pas de pacte que facebook mais
tu impactes tout le réseau en manquant
toute la galaxie facebook et puis tu as un sac
tu impactes indirectement
les services qui utilisent facebook
facebook ne marche plus j'avais vu un tweet
d'ailleurs ça me fait penser à ça
tu pouvais plus de connecter à Airbnb si tu avais un compte facebook
donc tous les gens se retrouvent à la rue parce qu'ils pouvaient plus
connecter à Airbnb
il ne pouvait pas rentrer dans leur maison
faut pas oublier aussi que
le secteur
de marché de facebook ce n'est pas les réseaux sociaux
mais bien la publicité
et le targeting d'utilisateur
et que de ce fait plein de sites
ont des boutons j'aime et
des pixels facebook
et de l'intégration facebook
et ces intégrations
ont aussi eu beaucoup d'impact en termes
de lenteurs d'accès et potentiellement
sur certains sites d'auto de conversion
parce que quand le site est lent on n'a pas forcément envie
d'acheter et donc comment vous feriez
pour faire en sorte de
est ce qu'il existe
à l'heure actuelle
je ne sais pas des papiers, des gens, des sociétés
qui vous semblent être à la pointe
de ce type de technologie
ou de test ou de pratique, de bonne pratique
qui serait un peu moins conservateur
peut-être
quels seraient les bonnes pratiques qui existent dans ce domaine
peut-être qu'il y en a pas
chaque société a sa vision
de la réelle et chacun la gère un peu
c'est très compliqué d'avoir une bonne pratique
en particulier parce que chaque réseau est différent
tu t'interconnectes différemment
tu as des tailles différentes
alors je vais être un petit peu pompeux
avec mon expérience
j'ai tendance à dire
que le réseau a à peu près 10 ans de retard
sur le système
qui a lui même 10 ans de retard sur le développement
et on s'en perd beaucoup
je pense pour le coup
que le réseau aujourd'hui
est seulement en train de commencer
à adopter
par exemple les reviews de codes
les reviews de configuration
sur GitLab
l'industrialisation
c'est quelque chose
qui est du domaine des 3-4 dernières années
alors ne parlons pas
de tests unitaires
de tests AB
souvent la première limite de ça
c'est que le réseau
nous l'oublions pas et quand même
pour beaucoup de boîtes un environnement très fermé
et très propriétaire
et que même si les protocoles sont standards
leurs implémentations ne le sont pas
et que souvent on n'a pas forcément beaucoup de marge de madoeuvre
pour tester que l'implémentation
du constructeur ou que la conf qu'on implément
chez tel constructeur
est valide
parce que faut pas l'oublier
c'est que les budgets qui sont en jeu pour le réseau
sont extrêmement conséquents
et que pour arriver à avoir des tests
d'intégration qui soient cohérents
souvent il faut quasiment disposer
d'une réplique du réseau
parce que beaucoup de bugs en réseau sont liés
non pas à l'implémentation logicielle
mais à l'interaction subtile
entre le logiciel, le matériel
et des fois les ondes électromagnétiques
oui c'était l'expérience
quand je travaillais chez Claude Watt
on n'avait qu'un gros F5
matériel
avec le rack
qui vaut 20 000 balles
et en fait en dev on avait un Hatch
à proxy des familles
configurées par nous-mêmes
et à chaque fois qu'on passait en prod
on avait un problème
après il faut pas oublier que le réseau
c'est le coeur de métier de très très très très très peu de boîte
donc du goût c'est très difficile
d'avoir quelque chose similaire
à du code ou du système
et j'ai même envie de dire que beaucoup
d'ingé systèmes, je l'ai encore vu aujourd'hui
avec mes collègues au travail
on m'aime peur du réseau
il y a beaucoup de gens qui ont peur du réseau
c'est marrant, en 2010
dans ma première boîte on avait un Paris
d'ailleurs il tient encore, il est presque fini
ce pari là
j'avais parié qu'il y aurait quasiment plus d'ingé
réseau en France
en 10 ans donc c'était en 2020
est-ce que j'ai raison ou pas
est-ce qu'on peut dire ça aujourd'hui, est-ce qu'il y a quasiment plus
d'ingé réseau
je pense qu'on a autant qu'avant
c'est juste que les autres domaines
de la tech se sont développés
principalement le développement avec
les cours devient développeur en 10 minutes
le 6 admins
reste encore un peu accessible
étant donné qu'on peut tous un peu monter
sa petite VM chez soi relativement
facilement aujourd'hui
par contre, quand on veut entrer dans le réseau
c'est tout de suite un billet à sortir
et il faut avoir des connaissances
et souvent on entre au réseau après être entre
au système
ou alors on le découvre dans ses formations
soit tu as des connaissances qui font déjà du réseau
qui t'apprennent soit tu découvres
par hasard et puis tu fais toi même
soit tu achètes du matos
c'est beaucoup plus compliqué d'apprendre le réseau
que d'apprendre le système
moi le réseau j'ai l'impression que tu apprends le réseau
quand tu as ton badge certification plus 6
en Cisco
moi j'ai toujours vu ça comme ça, le gars du réseau
c'était le gars qui avait une certification plus 1000 de Cisco
j'ai l'impression de voir un avant-vente Cisco
chaque fois qu'on avait un gars
c'était comme ça que je voyais les gars du réseau
alors c'était...
alors entendons-nous bien c'est quand même vachement moins vrai aujourd'hui
surtout chez les petits opérateurs locaux
et les gens qui essayent d'être un peu intelligents
et de se sortir un peu
des constructeurs
mais c'est vrai que
l'esprit communautaire se retrouve beaucoup
dans le réseau et c'est un petit peu aussi
le fondement d'internet
internet faut pas l'oublier
ça a commencé par 3 universités qui ont tiré un câble
et qui se sont enliest l'une à l'autre
et tenez v'la internet
mais justement est ce que demain
la révolution qui s'est passée
dans le monde de l'ops
personnellement en tout cas ça a été la standardisation
dans le bon sens du terme
je déste ça pour les gens qui me connaissent
mais ça a été le fait de pouvoir partager
des bonnes pratiques
vous avez dit tout à l'heure que... enfin Cécile t'as dit que
donc chaque réseau était différent etc etc
c'est assez drôle
c'est quelque chose que j'entendais
au début où je travaillais donc pareil il y a 10 ans
j'en mets ça en mode bah non mais on peut pas
on peut pas faire
la même infrastructure qu'à côté parce qu'on a des besoins différents
on n'est pas les gens d'à côté etc
et aujourd'hui
tu as des trucs qui s'appellent les RFC
qui standardisent entre guillemets
les bonnes pratiques enfin c'est des recommandations
c'est pas les obligations
mais les RFC
j'avais personne à implémenter une RFC
les RFC standardisent les protocoles
les protocoles oui mais pas leur implémentation
pas l'architecture
alors est ce qu'il faut pas démain
une grande révolution de l'open source
ou l'open network
t'en as un peu parlé
il y a deux choses
il y a la partie physique
et il y a la partie architecture
sur la partie architecture
on en est encore très loin
parce que beaucoup d'employeurs et de boîtes
considèrent que leur configuration réseau
ne serait-ce que les ranges d'IP
qui sont pourtant publiques et qui l'auront été attribués
par les rires
le fait même de citer ces informations
au public et de communiquer
sur les choix de design qu'on a fait en réseau
est un secret industriel
oui mais mes secrets terraformes
tu les connais pas
pourtant je peux te donner mon code terraformes
mais même
sans donner ces variables
le simple fait de décrire
l'architecture sans donner d'informations
d'adressage est considéré
pour beaucoup de boîtes comme un secret industriel
on est vraiment dans une révolution
c'était le système de la pratique
avant même de rentrer dans une révolution technique
il faut rentrer dans une révolution
les deux vont ensemble
en tout cas pour le système
qu'est ce qui a créé cette révolution
c'est des outils qui ont obligé
à passer à ces systèmes là
personne n'y serait pas savant
tout le monde aura toujours continué à avoir ces scripts bashes
vm.sh
ou vm.sh
avant de passer
j'ai un Kubernetes
Cube 7L Play
et j'ai quelque chose
je sais pas ce qu'il y a dans le Cube 7L
c'est ton logiciel
mais prenons
l'industrialisation réseau et prenons ce que Cécile a dit
imaginons
nous qu'on est un opérateur
l'opérateur va vouloir transcrire
dans son industrialisation réseau
les offres
et comment il l'avant au client
donc
dans l'industrialisation réseau
se trouve quelque chose qui définit
sa particularité commerciale
donc quelque chose qui est lié à son bise
et qui peut rentrer dans le domaine du secret industrial
mais par contre
dans d'autres cas
dans le domaine or opérateur
où le réseau est un outil et non pas un service
je pense que
de plus en plus de boîtes
vont peut-être finir par communiquer leur configuration
d'ailleurs on a eu
un exemple récent
de Chadeau
qui a publié
en ressources libres son orchestrateur
et l'ensemble des confs
liés à deux data centers
qu'ils ont décommissionnés
ça va dans le bon sens mais on a encore énormément de chemin
il faudrait que quelqu'un utilise
cet orchestrateur là
et toi Cécile, tu es jeune
dans le métier on va dire
pas les vieux cons qu'on peut être
toi justement tu vois ça
comment alors et que tu as le t...
toute cette partie
industrialisation je sais pas est-ce que tu viens
avec un oeil neuf dans ce domaine là
ou pas ou est-ce que c'est
pour l'instant on apprend tissage
est-ce que tu apprends le nouveau ou pas
j'ai un côté où tu vois
quand je me dis ce qui s'est passé avec Facebook
et je me dis ouais l'automatisation
ça père si il vous fait ça et puis je me dis
d'un côté l'automatisation ça peut être vachement pratique
et surtout si tu gères plusieurs data centers
dans plusieurs pays différents
ça peut être ouf pour pacher des configurations facilement
mais pour moi il y a toujours un juste milieu
entre faire quelque chose manuellement pour être sûr
et faire complètement confiance à l'automatisation
tu vois tu vois ce juste milieu
moi je suis entièrement
enfin là moi alors et que si jamais
je donne mon avis sur ce qui s'est passé
c'est pas tant qu'il y a eu un problème
les problèmes ça arrive
le chaos engineering je pense pas même d'ailleurs
que Facebook devrait tomber régulièrement
c'est un site qui est assez gros pour tomber régulièrement
le problème c'est
le régulièrement est 7h
oui c'est 7h le problème
voilà c'est ça
comment ils n'ont pas pu avoir accès
à leur out of band
et comment n'ont-ils pas pu accéder
physiquement aux équipements
comment ça se fait qu'il y a eu deux fautes
non c'est comment ça se fait qu'il n'est pas vu avant
qu'ils avaient ce couplage là
le problème pour moi c'est qu'ils ont créé
un château de carte
et qu'ils ont fait confiance au château
et c'est vraiment un problème que je vois régulièrement l'indense
et qu'en fait on se met à être de plus en plus frileux
etc donc ils ont enlevé le mood fast
pourquoi ? parce qu'en fait au fur et à mesure
ils n'arrivaient plus à résoudre les problèmes
c'est-à-dire qu'en fait ils ont créé une architecture
basée sur des sables mouvants
basé sur lui-même
sur des process type itil et compagnie
personnellement dans une fiche de poste
quand je vois écrire itil je fuis
oui ben c'était un peu le
moi quand j'ai entendu raci en mode la prochaine fois
qu'il faut mettre en prod
il va falloir faire plus de raci plus de trucs comme ça
j'ai avalé mon veuille
si je puis me permettre
c'est un peu
les chefs de projet Pouss Propell qui sont un peu trop racis
il y a mon goût
donc la dessus en fait
pourquoi je pose la question là-dedans
c'est pas vraiment
c'est pour ça que je demandais s'il y avait des bonnes pratiques modernes
etc qui était peut-être celle qui n'était pas
adoptée par l'industrie mais apparemment
il y a des protocoles
qui commencent à se développer
aujourd'hui
que ce soit sur les infrastructures data center
on parle des infrastructures
VXLAN VPN
qui se développent de plus en plus
d'ailleurs quand on regarde
les infrastructures de Facebook
on retrouve
ce type d'infrastructures qui est mis en place
il y a
des protocoles standard
qui commencent à se mettre
avec finalement peu de différences d'implémentation
donc
peut-être que dans les prochaines années on verra
une forme de standardisation
mais je pense que
l'industrie je pense que
c'est peut-être aussi une faute d'architecture
c'était ça le problème
ce qu'on disait aussi avant
c'était comment c'est possible que ce soit
et tout Facebook et tout Instagram et tout WhatsApp
c'est ok c'était
entre guillemets moins cher où il y avait une visibilité
d'être moins cher mais si jamais tu es automatisé
que tu es automatisé un AS ou que tu en as automatisé
1000
c'est un coût identique
et c'est pour ça que je ne comprends pas
comment ils ont pu mettre tous leurs oeufs dans le même panier
surtout s'ils ont de l'automatisation
je vraiment j'ai du mal à comprendre ça
à quel point ils ont été
blind sur un problème
après
logiquement s'il s'agissait que
des routes au DNS
une erreur aussi
c'est que les bonnes pratiques du DNS
visent à inberger
une partie de leur DNS
hors de l'AS de Facebook
pour limiter les risques
mais ils auraient peut-être dû avoir un AS pour le DNS
un AS pour Facebook
techniquement
ce qu'ils auraient pu faire c'est avoir
un AS par grand produit
et inberger leur DNS
commun l'ensemble des produits
sur plusieurs de ces AS
après c'était un choix
ils ne sont pas rendus compte des conséquences
c'est à force
de vouloir rationaliser les coûts
ils en ont oublié
la résilience
pour le coup dans le cas de Facebook je pense pas que c'est une question de coûts
je pense que c'est une boîte qui n'a pas de problème comme ça
c'est souvent même un problème de l'esprit
de la volonté de réduire
en se disant que ça sera plus simple à gérer s'il y en a un
c'est un truc que j'entends
toujours je l'ai encore entendu cet après-midi
dans une de mes réunions
qui était le but c'était de rationaliser
et en fait cet esprit de rationaliser
c'est quoi ce qui est rationnel en informatique
on l'a vu l'un de dents et
ça me rappelle un taux que j'ai fait sur le risque
il n'y a pas longtemps
souvent on essaie de limiter l'occurrence
on se dit si on l'a une fois
l'avantage c'est qu'on peut le bichonner
comme il faut et faire en sorte que ça n'arrive pas
bah non on a un système d'audite
on a un système de machin on essaie de limiter
l'occurrence d'un problème
et en fait on oublie la gravité
c'est à dire que les problèmes shit sa pun
ça va arriver un problème
mais d'avoir mis tous ces heures dans le même panier
c'est sûr et certain que le jour où t'as un problème
il est échelle fois mille
et je trouve ça assez grave
qu'il n'est pas vu et qu'il n'est pas
qu'il n'est pas essayé de mieux le gérer
alors après on n'a pas les détails de tout ce qui s'est passé
dans la gestion du risque, dans l'analyse
de risque s'il y a les bienfaites que peu de boîtes font
pour des vrais experts
de la sécurité informatique
le risque normalement c'est un produit
entre l'occurrence et la sévérité
et la détectabilité
et le troisième facteur
que j'ai trouvé, en toc là-dessus
à un moment temps, c'est
occurrence, gravité, détectabilité
ça veut dire si jamais tu as quelque chose qui n'est pas grave
qui arrive peu souvent
mais tu détectes pas et qui va rester là
pendant des années et des années
ça devient un problème à terme
genre les backup
les backup qui sont pas fait
les backup qui plantent
et que tu le sais pas
c'est pas vraiment très grave, tu apprends d'aller pas tomber
sauf le jour où t'en as besoin
la détectabilité d'un problème, un risque c'est important
tu peux avoir des problèmes silencieux
et c'est très grave dans ton infra
et le dernier c'est l'acceptation
tu peux très bien avoir des problèmes
qui sont en fait que tu rends acceptable
je sais pas par exemple
tu perds tes DNS, c'est grave
mais c'est pas extrêmement grave si jamais
dans ton application mobile, il y a les routes
les IP qui sont hard-codés
ça va même
si ça te n'aussande l'accessibilité
elle va beaucoup plus loin
imaginons, t'es une boîte qui livre des cartons
bon, si tu perds ton Sylvitrin
parce que t'as perdu les DNS
bon, l'impact est
très faible, ça peut bourrir une semaine
ça va pas faire ton business
c'était Facebook
qui dépend de la publicité, qui dépend des hits
qui sont associés
pour le coup
l'acceptabilité est plutôt nul
on a vu qu'ils ont perdu 5% en bourse
pendant la panne
voir plus
surtout qu'ils ont eu la personne qui a
je suis pas trop suivi
il y a eu une l'enseise d'alerte
sur ça, plus toutes les enquêtes internes
sur le pic Instagram
était nuisible pour les jeunes
on a vraiment un truc
mais même en perte
c'était plus de 100 000€ par minute
la perte
moi je me souviens
quand j'étais dans les boîtes d'avant
j'étais à peu près à ça, on était à 100 000€
mais je sais plus c'était par heure ou par 10 minutes
mais on savait que c'était le salaire
d'un ingénieur
par 30-10 minutes
ce qui fait d'ailleurs que je suis déjà allé voir
mon patron en disant
tu me laisses faire quoi que ce soit
mais je t'enlève 10 minutes de dents par an
et tu me laisses faire du kubernetes plutôt que de faire de la merde
dans mes os
tout le monde reconnaîtra
mais ça pouvait devenir
c'est pour ça que souvent il faut le lier
t'as dit tout à l'heure Alexis que c'était
cher le réseau
oui mais c'est cher d'avoir un mauvais réseau
et c'est ça souvent qui, là dans ce cas-là
je pense que les gars doivent s'en mordre les doigts
de se dire putain si on avait eu un deuxième AS
on aurait peut-être eu
moins de problèmes, ça nous aurait coûté
x milliers d'euros en plus
le pire c'est que
la ressource laissent en lui-même
ce n'est pas une ressource qui est facturée
à proprement parler
non mais l'équipement on va dire, l'équipement et la gestion
l'équipement et les ingénieurs qu'il faut
pour le maintenir, mais même une équipe totale
il faudrait faire le calcul du coup
mais ça veut dire combien d'ingénieurs
à plein temps depuis la création de facebook
genre qui pouvait mettre
juste à gérer un AS en plus
pour éviter un problème aussi grave que ça
maintenant même gérer mieux l'auto-offband
ça aurait carrément suffi, ça ressemble à avoir
un meilleur réseau auto-offband et la PAS
c'était régulant à une heure qu'en max
pour citer certains grands opérateurs français
eux on standardisait leur auto-offband
et l'ont totalement découplé
étant donné que pour contacter leurs équipements
ils ont collé au cul de leurs équipements
à modem
ils ont trouvé une solution
qui était appropriée à leurs besoins
mais qui leur permet
simplement parce que le protocole
est décoré les du reste
de clairement isoler
leur autofband de leur Ipame
après il y a toujours un problème
c'est que n'oubliez pas que genre
Watch the Watchmen
ça m'est déjà arrivé en prod
que le réseau d'Ipame qui est un peu
l'auto-offband des machines physiques
et bien ce soit lui qui fait cracher le décès
tout le décès en entier
et puis en fait tous les autres décès à côté
pour plein d'autres raisons etc
mais en fait il y a eu un bug réseau
encore un
sur le réseau d'Ipame
qui a fait entièrement cracher tout le data center
donc en fait il faut faire toujours attention
à ça et même je donnais d'autres exemples
dans d'autres boîtes où c'était le monitoring
qui avait fait un dédose interne et qui avait fait tomber
toutes les API clientes
il faut aussi faire attention à ça
et c'est peut-être ça d'ailleurs le problème
c'est que l'auto-offband aurait dû être un produit
avec sa propre SLA
avec ses propres tests
alors que souvent c'est un produit annex
de la même équipe qui en aura besoin plus tard
en fait c'est peut-être ça le problème
ça va même être pire c'est que souvent
la auto-offband s'est construite
avec les restes de la génération
L-1 du réseau
on a tous connu
les vieux Cisco 2960
en réseau auto-offband
ça marche chez Rocksolid
mais c'est monoalime, c'est souvent pas monitoré
et qu'on se rend compte souvent
que le truc est inaccessible
quand on en a besoin
ou alors Pierre c'est au moment où tu en as besoin
que tu le stresses un peu et que
c'est là où il crache
L-1, les contraintes de service
en termes de débit et d'accès
sur ces réseaux sont souvent plutôt faibles
donc généralement
les contraintes techniques qui sont associées
sont plutôt faibles
par contre il y a souvent sur ces réseaux
un vrai défaut de monitoring et un vrai défaut de suivi
et c'est ce qu'on disait
nous serais ce qu'avec les moyens de communication
de dernier recours de Facebook
c'est que c'est des moyens dont on ne se sert pas
ou peu
donc on se rend compte qu'ils sont cassés
que le jour où on en a besoin
L-M-Mais ça mais pour régler ça
la seule solution que je connais c'est le chaos engineering
ils auraient dû casser leur AS
à un moment et se rendent compte qu'ils ne peuvent pas le casser
donc c'est qu'il y a un problème
en fait il aurait dû avoir quelqu'un qui arrive
et qui fait bonjour la S
y'a plus d'alimentation dessus
c'est pas ça
et c'est ça qui aurait dû se passer
en fait tu aurais dû avoir quelqu'un qui allait couille
d'aller fermer un équipement
qu'il sait être un équipement
prioritaire
L-M-Mais là ça reste tout le temps dans notre problème
c'est qu'il y a un spoof
C'est comme ça que tu peux aller voir
un directeur financier ou n'importe quoi
en disant bah regarde
j'ai éteint un composant à un seul endroit de notre infra
malgré tous les ingénieurs qu'on a
malgré tous les équipements qu'on a
malgré tous les data centers on a perdu le service
donne moi de l'argent pour
pour régler ce problème
Mais c'est tout le problème de la gestion de la date technique
et du legacy parce qu'il faut produire
livrer
faire rentrer de nouveaux clients, faire de nouveaux biz
mais par contre c'est vraiment pas sexy
de gérer l'infrastructure qu'on a actuelle
et de la maintenir en condition opérationnelle
S-Sauf si on prend le cas de Facebook le réseau c'est un coût
et c'est pas des revenus
C'est tout une question de
gestion de centres de coût
et de choses courtes termistes
et finalement on le retrouve
toutes les boîtes ont cette proportion
à un moment ou à un autre à le faire
S-Dou la question de budget maintenant
et de montrer que ça ne marche pas
ça aurait dû être fait
apparemment c'était pas fait chez Facebook
sinon on peut imaginer
et voilà
je sais pas si on arrive déjà
presque à l'heure pour parler de ce sujet
je sais pas si vous avez encore quelque chose en particulier
que vous avez vu que vous auriez aimé parler
S-Tout le monde on a fait le tour je pense
S-Je pense qu'on a pour le coup fait
un très bon tour là dedans
qui est plus simple à faire
que des résumés en tweet
même dans un grand grand thread
et c'était tout l'intérêt l'un de dans
ce sujet s'est rajouté un peu au dernier moment
je trouve ça assez bien d'en parler
et là j'avais avec ça
deux personnes du réseau
S-L'occasion fait le lauron
S-Exactement, merci beaucoup à tous les deux
merci beaucoup pour
ce numéro
spécial sur le réseau
qu'est ce qu'on avait encore jamais eu
jamais eu dans DevOps
et alors n'hésitez pas à rejoindre
pour ceux qui écoutent ou les auditeurs
le Discord si vous le voulez
n'hésitez pas à venir partager
et même partager
avec nous sur le Discord
et même à venir dans le Discord
dans le DevOps, dans les podcasts
je vais y arriver
parce que je suis à la recherche toujours de personnes
pour discuter l'un de dans
de tous les sujets donc vraiment
de manière très très large
même si vous avez envie de faire le candid
de venir juste être en direct pour poser des questions
c'est ce qui est vraiment très intéressant
donc n'hésitez pas
à venir participer, à proposer vos sujets
ça peut être plus court que ça
on peut même faire ça en remote là
on était joy de l'après Covid
en physique ensemble
c'est pour ça d'ailleurs qu'on est enregistré
sur YouTube en direct donc voilà
n'hésitez pas aussi à vous inscrire à la chaîne
pour avoir les notifications
et voilà
bien merci beaucoup
c'était un grand plaisir
et bien merci
et puis à une prochaine