Les GAFAM aussi ont des incidents

Dernièrement Facebook a eu un incident majeur et a disparu du net pendant plusieurs heures.

Les réactions que cela a suscitées, dans la sphère technique, m’ont quelque peu surpris, donc nous allons parler dans ce billet des pannes chez les big tech.

Par big tech, j’entends ces boites que l’on pense bien trop grandes pour avoir le moindre incident visible de l’extérieur.

Facebook : Tu me vois, tu me vois plus !

Facebook a rencontré un incident réseau impressionnant et très simple en même temps. Une erreur de manipulation a conduit à la suppression des routes BGP vers Facebook.

Ce sont ces routes qui permettent d’indiquer à Internet comment arriver à Facebook.

L’incident peut sembler anodin, mais repropager des routes BGP peut prendre du temps, surtout pour une infrastructure de la taille de Facebook.

De manière visuelle, voici ce que ça a provoqué :

Point ayant empiré la situation : Facebook ayant perdu son réseau, il était nécessaire d’aller en datacenter pour accéder aux machines, datacenter qui était impossible d’accès vu qu’il nécessitait un accès réseau pour l’authentification.

C’est un point qui a été remonté par Facebook dans leur communiqué de presse :

We’ve done extensive work hardening our systems to prevent unauthorized access, and it was interesting to see how that hardening slowed us down as we tried to recover from an outage caused not by malicious activity, but an error of our own making.

AWS : Une erreur de configuration Kinesis plonge Internet dans le noir

J’en avais parlé sur ce blog à l’époque, AWS a rencontré en fin d’année dernière un incident majeur, suite à l’ajout de stockage sur leur moteur Kinesis, pour les usages internet (IAM notamment), un incident majeur a paralysé une énorme partie d’Internet pendant plusieurs heures.

Arretez Internet : AWS ne répond plus!

Il y a quelques jours, un incident impactant le fournisseur cloud AWS a eu un écho important chez beaucoup d’entreprises et de services, directement touchés par cette instabilité. J’ai vu sur les réseaux sociaux de nombreuses réactions, souvent à côté du sujet (malheureusement) et je me suis dit

TFerdinand.netTeddy FERDINAND

Une fois de plus, le communiqué de presse de l’entreprise est transparent sur la cause de l’incident :

The new capacity had caused all of the servers in the fleet to exceed the maximum number of threads allowed by an operating system configuration. As this limit was being exceeded, cache construction was failing to complete and front-end servers were ending up with useless shard-maps that left them unable to route requests to back-end clusters

Vu de l’extérieur, l’incident semble assez bête en fait, un problème de dimensionnement des machines qui a conduit à une indisponibilité mondiale.

Google GCP : Je ne te connais pas

Quelques semaines après l’incident AWS, Google rencontre aussi un incident majeur : l’authentification de l’ensemble de ses applications ne répond plus.

Que ce soit YouTube, GCP, Google Workspace, plus aucun utilisateur ne parvient à se connecter.

De par l’intégration des services de Google un peu partout, l’impact a été visible par beaucoup de monde.

Une fois de plus, l’entreprise a été transparente sur la cause de cet incident dans son communiqué de presse :

Google uses an evolving suite of automation tools to manage the quota of various resources allocated for services. […] An existing grace period on enforcing quota restrictions delayed the impact, which eventually expired, triggering automated quota systems to decrease the quota allowed for the User ID service and triggering this incident.

Azure AD et les incidents distribués

En septembre/octobre 2020, Azure AD a rencontré un incident rendant le service d’authentification de Microsoft inaccessible (en grosse partie).

La root cause : une double anomalie, un package en test (slow ring) déployé en production, et un déploiement en parallèle sur l’ensemble des serveurs au lieu de le déployer en rolling update.

Azure AD is designed to be a geo-distributed service deployed in an active-active configuration with multiple partitions across multiple data centers around the world, built with isolation boundaries. Normally, changes initially target a validation ring that contains no customer data, followed by an inner ring that contains Microsoft only users, and lastly our production environment. These changes are deployed in phases across five rings over several days.

In this case, the SDP system failed to correctly target the validation test ring due to a latent defect that impacted the system’s ability to interpret deployment metadata. Consequently, all rings were targeted concurrently. The incorrect deployment caused service availability to degrade.

Pourquoi tu me parles de ces incidents ?

La bienveillance : connait pas

Dans un premier temps, j’ai constaté que la bienveillance de beaucoup de communautés techniques disparaît lorsque l’on parle des GAFAM. Sans en être un grand fan, je n’oublie pas que ce sont des femmes et des hommes comme mes collègues et moi qui sont derrière. Beaucoup sont passionnés par leur travail et le niveau requis pour rentrer dans ces entreprises est loin d’être anodin.

Pour autant, nombre de messages sur les réseaux sociaux considéraient que c’était "amateur" que d’avoir ce type d’incident.

Pour avoir connu nombre d’incidents majeurs dans ma carrière, parfois, il ne s’agit pas d’incompétence, mais d’un concours de circonstances imprévu et difficilement prévisible !

Personne n’est too big to fall

Point intéressant à retenir, même des colosses comme les GAFAM rencontre des incidents impactant. La différence majeure pour moi reste le facteur d’échelle : chez les GAFAM, l’incident est directement très visible.

Personnellement, je trouve cela rassurant de se dire que même ces boites aussi énormes rencontre des incidents somme toute assez classiques.

Les entreprises valorisent leurs erreurs

Pour chacun de ses incidents, on a pu constater un post mortem clair et transparent sur ces derniers. Permettant ainsi de mieux appréhender la portée de ces anomalies et pourquoi leur résolution à parfois pris du temps.

Mais on voit aussi que les entreprises communiquent de suite sur la manière dont elles vont éviter que cela se reproduise.

Le poids du legacy

Le legacy, cette dette technique éternelle que l’on voit dans toutes les entreprises (ou presque). Il serait idiot de penser qu’il n’y a pas de legacy ou de manque de documentation chez les GAFAM.

Quand bien même ils ont des processus bien huilés (en tout cas en public), comme toutes les boites, ils ont un historique et des composants qui sont anciens et/ou mal documentés.

La différence majeure étant le facteur d’échelle, du legacy chez Microsoft n’a pas le même poids que chez une entreprise de taille plus modeste.

En conclusion

Ce billet a avant tout pour but de mettre un peu en avant ces incidents et la toxicité de certaines communautés Tech autour de ces derniers.

Les GAFAM ne sont pas invincibles et rencontre des incidents d’exploitation comme toutes les entreprises. D’un côté, je dirais même que c’est rassurant de se dire que cela leur arrive aussi !

Et vous, qu’en pensez-vous ?