Face aux licenciements et départs massifs de Twitter, plusieurs personnes ont estimé que Twitter était condamné. Pour tenter d'en expliquer la raison, un ingénieur en fiabilité de site (SRE) ayant plus de 10 ans d'expérience dans l'industrie a présenté des dizaines de scénarios qui seraient, selon lui, de réelles menaces pour l'intégrité de Twitter dans les semaines à venir.« Pour donner du contexte, j'ai vu une variante de chacun de ces problèmes constituer une menace sérieuse pour une application d'un milliard d'utilisateurs. J'ai même causé quelques-uns des plus techniques. J'ai été impliqué dans le triage ou la réparation encore plus ».
Ingénieur SRE, qu'est-ce que c'est ?
Un ingénieur en fiabilité de site, ou SRE, est un rôle qui englobe à la fois des aspects de l’ingénierie logicielle et des opérations / infrastructures. Il englobe également une stratégie et un ensemble de pratiques et de principes à travers les offres de services et est étroitement lié à DevOps et aux opérations. Le terme ingénierie de fiabilité de site a vu le jour chez Google en 2003 lorsqu’une équipe de fiabilité de site a été créée. À cette époque, l’équipe était composée d’ingénieurs logiciels. Depuis lors, le concept d’ingénierie de fiabilité de site a évolué et a fait son chemin dans l’industrie plus large du développement de logiciels et est maintenant son propre rôle au sein des organisations.
Les ingénieurs en fiabilité du site comblent le fossé entre les opérations et les développeurs de logiciels. Bien qu’il n’existe pas d’approche unique de ce qu’un ingénieur en fiabilité de site fait d’une organisation à l’autre, de manière générale, la responsabilité d’un ingénieur en fiabilité de site peut englober un large éventail d’objectifs, tels que la gestion et la surveillance de la disponibilité du système, la latence, les performances, l’efficacité, la réponse aux incidents, ainsi que la planification de la capacité des services d’une organisation.
Quelques scénarios qui sont de réelles menaces à l'intégrité du site, selon un ingénieur en fiabilité de site
1) Un disque dur aléatoire se remplit. Vous n'avez aucune idée à quel point il est courant qu'un seul boîtier flexible provoque des pannes en cascade dans les systèmes, même ceux bien conçus et tolérants aux pannes avec une maintenance active. Où est la boîte ? Qu'est-ce qui le remplit ? Qui va comprendre ça ?
2) Un problème physique avec le réseau supprime un DC [ndlr. Data Center]. Je suppose que Twitter est principalement sur site, et j'ai vu ce qui se passe lorsqu'un arbre détruit une ligne de fibre critique lors d'un grand événement d'actualité.
3) Une mauvaise poussée de code fait planter le site. Empêcher cela était mon travail quotidien, et je peux vous dire que c'est l'un des scénarios les plus effrayants pour toute équipe SRE, qui le serait encore plus pour une équipe complètement en sous-effectif et épuisée.
4) Une mauvaise poussée de code fait planter le site d'une manière qui gâche également la possibilité de pousser un nouveau code. C'est le scénario cauchemardesque pour des équipes comme la mienne. Quand quelque chose comme ça se produit, tout le monde met la main à la pâte. Sans une compréhension approfondie des systèmes, vous pourriez ne jamais récupérer.
Incidents critiques
5) Mystère SEV [ndlr. un incident critique]. Soudain, le site s'assombrit. Le tableau de bord est rouge. Tout semble foutu. Il n'y a aucune indication pourquoi. Vous devez faire appel aux gros canons. Les équipes dont les noms se terminent par Foundation. Qui sont-ils? Comment les appelez-vous ?
6) La base de données est foutue. Tout est en feu. Qui est l'expert qui doit gérer une telle situation ?
7) Quelqu'un, disons, tout à fait hypothétiquement, @wongmjane, trouve une faille de sécurité critique dans votre application iOS. Vous devez proposer rapidement un correctif. Vous avez une équipe d'experts qui savent comment naviguer dans la bureaucratie kafkaïenne d'Apple pour les mises à jour d'applications, n'est-ce pas ? J'espère que vous en avez une.
8) Quelqu'un remarque qu'il est possible de lire les DM de quelqu'un d'autre en chargeant une URL particulière. Il s'agit d'un problème critique SEV1 [ndlr. Un incident critique à très fort impact. Par exemple : un service orienté client comme Jira est en panne pour tous les clients] et vous avez besoin de personnes qui comprennent parfaitement comment fonctionnent vos abstractions de confidentialité et comment les corriger.
9) Le site est hors ligne à 4h du matin, vous n'avez aucune idée de ce qui ne va pas. Vous avez besoin d'un IMOC (Incident Manager On Call) qui sait qui réveiller, pourquoi et comment. Quelqu'un qui comprend vos systèmes, peut synthétiser les informations à la vitesse de l'éclair et coordonner un effort de récupération.
10) Le système que vous utilisez pour trouver d'autres systèmes tombe en panne en interne. Aucun de vos systèmes ne peut communiquer entre eux. Le site et tous vos outils échouent immédiatement. Les outils dont vous avez besoin pour annuler le changement de rupture ne répondent pas. Pouvez-vous comprendre ceci avec une équipe squelettique ?
Et d'autres problèmes
11) Il est 17h un vendredi. Les tableaux de bord passent tous au rouge en même temps. La flotte Web connaît des redémarrages en cascade. Les disques se remplissent depuis mercredi. Il y a eu des centaines de changements de code sur plusieurs systèmes de verrouillage mercredi. Renversez l'un d'entre eux à vos risques et périls...
12) Oh zut. Vous en avez annulé un. Désormais, les tweets de chaque compte suspendus sont visibles par tous. Les gens pourraient littéralement se faire assassiner avec des machettes au-dessus de leurs postes. Ce n'est pas une hypothèse. Il est maintenant 21h. Le site est foutu. Qui allez-vous appeler ?
13) Le système qui garantit que les changements de serveur peuvent être transmis en toute sécurité à la production est défaillant. Vous avez, disons, 30 000 tests qui doivent être exécutés pour garantir la confidentialité/la sécurité/la conformité/la fiabilité. L'un des tests est à l'origine...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par febneo
