Un ingénieur fiabilité de site présente des dizaines de scénarios qui pourraient signer la fin de Twitter

Suite à la réduction drastique des employés dans l'entreprise par Elon Musk

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 des échecs. Pouvez-vous trouver lequel ? C'est aussi la coupe du monde. De plus le site est en panne.

Se conformer aux lois

14) Un utilisateur aux Philippines est sur le point de publier CEI sur la plate-forme. Vous ne pouvez pas laisser ce contenu en place. Vos employés ont-ils des relations avec les forces de l'ordre aux Philippines ? Vos systèmes de modération de contenu fonctionnent-ils ? Avez-vous vos modérateurs ?


15) Le FBI veut inspecter le contenu des messages privés de quelqu'un qu'il pense être sur le point de commettre le 11 septembre 2 : Atomic Boogaloo. Avez-vous un système pour leur accorder l'accès ? Leur refusez-vous l'accès ? Comment savez-vous que c'est vraiment eux ?

16) Vous leur accordez l'accès. Maintenant, quelqu'un d'un pays connu pour ses horribles violations des droits de l'homme frappe à la porte. Ils ont une citation à comparaître d'apparence officielle. Les laissez-vous voir les message privé d'un dissident ? Pouvez-vous expliquer pourquoi ? Vous devrez peut-être le faire, devant un tribunal très officiel quelque part en Europe.

17) Un autre pays vous dit qu'il veut que toutes vos données sur ses utilisateurs soient stockées sur des serveurs dans son pays. Avez-vous des experts en politiques dans ce pays ? Avez-vous beaucoup d'avocats très motivés ? Avez-vous un ingénieur infra qui sait comment partitionner vos données de la sorte ?

18) RGPD. Vous êtes trouvé en infraction. Il a fallu des mois à une équipe de centaines d'ingénieurs, d'avocats, d'experts en politiques, de concepteurs et de gestionnaires « d'ingénierie hardcore » pour être en conformité en premier lieu. Comment gérez-vous la situation ? Je vous assure que ne pas le faire coûtera plus cher que l'effectif d'une organisation.

Un manque d'employés

19) Une fois par jour, tous les jours, à 00h13, un service spécifique dans votre pipeline de données ralentit à un rythme absolu. Cela ne semble pas causer de problèmes, mais vous êtes un peu inquiet car cela semble empirer. Attribuez-vous un SRE pour jeter un coup d'œil ? Vous en reste-t-il ?

20) Le service que vous utilisez pour découvrir d'autres services fonctionne bien, mais l'un de vos meilleurs ingénieurs effectue des calculs et se rend compte qu'il ne s'adaptera pas à plus d'utilisateurs et à plus de services, et (hypothétiquement) vous souhaitez créer une super-application appelée X. Est-ce que vous la réécrivez ? Qu'est-ce que vous faites ?

21) Vous décidez de la réécrire. 8 mois plus tard (lol) votre nouveau système est prêt à accueillir ses premiers utilisateurs. Qui coordonne la migration ? Comprennent-ils vraiment les systèmes complexes ? Sont-ils bons avec les gens ? Peuvent-ils procéder à l'exécution ? Ont-ils la connaissance du domaine dont ils ont besoin ?

22) Vous venez d'embaucher un super directeur technique de Microsoft pour une organisation centrale. Lentement, la productivité de leur organisation ralentit et l'attrition grimpe très haut. Le directeur jure que tout va bien. Si vous licenciez le directeur, l'un de vos vice-présidents a soudainement environ 18 rapports. Qu'est-ce que vous faites ?

23) Un ingénieur vient de lancer une commande pour redémarrer la flotte. Oups, il n'a pas utilisé --slow. Maintenant, tous vos caches sont vides. Tous. Chaque demande va directement à la corbeille. Les bases de données sont toutes surchargées instantanément, certaines commencent à OOM et redémarrent en boucle... Comment rechargez-vous le cache ?

Gestion des évènements

24) Coupe du monde. C'est l'événement déterminant. Nous avions l'habitude d'organiser des soirées de surveillance pour les cartes routières. La quantité de trafic que votre site reçoit en une semaine est époustouflante. C'est en énormes rafales. Il teste chaque système que vous avez jusqu'à ses limites. Si l'un se casse, espérons qu'ils ne tombent pas en cascade. Mais ça sera le cas

25) Saint-Sylvestre, côte est des États-Unis. Chaque année. Je me souviens d'être assis à l'extérieur du bureau, des feux d'artifice explosant au loin, appelant frénétiquement les gens à prendre des vidéos. Tout le monde poste des vidéos de leurs feux d'artifice. Tout le monde. Il remplira les disques et testera votre bande passante jusqu'à la limite.

26) Je l'ai déjà dit, mais... CEI. Si vous le gérez mal, si vos responsables politiques et vos avocats ne sont pas au top, vous allez vous faire démolir devant le Congrès, devant des juges, dans les journaux du soir, des endroits où vous ne voulez pas être si vous dirigez une entreprise de médias sociaux.

Sécurité physique

27) Sécurité physique de vos bureaux. Les gardes de sécurité m...