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'ont dit qu'ils gardaient de longues listes de fous, les mémorisaient. Les gens veulent tuer Zuck. Comme un meurtre rituel dans la baignoire. Ils se présentent au bureau tout le temps. Votre équipe de sécurité est-elle dotée de personnel et prête ?
28) Génocide. Les gens utilisent votre plate-forme pour orchestrer des meurtres de masse, à la machette dans les églises. Et vite. Rapide comme l'éclair. Vous devez être préparé avant. Si vous n'avez pas d'équipe qui sait comment détecter et arrêter ça au plus vite, vous allez être traîné à La Haye.
29) Rébellion. Des millions de personnes utiliseront votre plateforme pour orchestrer une rébellion contre leur gouvernement. Utilisez-vous les outils de #28 pour les arrêter ? Laissez-vous les choses se passer ? Comment vous décidez-vous? Et si vous les laissiez faire et que la même chose se produise la semaine prochaine dans un pays que vous aimez vraiment ?
30) Facteur de bus. Supposons qu'il vous reste 3 SRE de niveau senior+ dans votre organisation Core Services. Ils sont absolument indispensables, pour des raisons que vous pouvez déduire d'en haut. Comment les gardez-vous tous en vie ? Peuvent-ils être dans le même avion ? Quel est le plan d'urgence s'ils le font tous de toute façon ?
Intrusion dans le réseau d'entreprise
31) Envahisseurs. Un seul boîtier de votre centre de données est connecté par erreur à l'Internet public et oublié pendant des années (cela arrive vraiment, vraiment, vraiment, je le promets). Quelqu'un ouvre la boîte. Il pénètre vos systèmes. Comment le détectez-vous ? Que faites-vous une fois que vous l'avez détecté ?
32) Envahisseurs : les plus silencieux. Ils sont dans votre réseau. Ils ne font que regarder et attendre. Ne rien faire. Je vous promets qu'une grande organisation de sécurité pourrait même ne pas détecter cela. S'il ne vous en reste plus un bon... Quels dégâts peuvent être causés par l'observation ? Données de carte de crédit ? Mots de passe ? Messages privés ?
33) Envahisseurs : Acteurs étatiques. Le PCC vient d'avoir accès à vos systèmes. S'il réussit, il est là pour rester. Comment votre équipe de sécurité le découvrira-t-elle ? Comment trouvera-t-elle et éliminera les portes dérobées ? Comment allez-vous protéger les messages privés et les tweets privés des utilisateurs ? Si vous ne le faites pas, des gens pourraient mourir.
34) Envahisseurs : les chaotiques. Ils sont là pour faire des putains de dégâts. Ils pourraient supprimer des données, redémarrer la flotte de caches et fermer le site pendant des semaines, publier des menaces nucléaires comme le POTUS... Vous feriez mieux d'avoir une grande équipe de sécurité talentueuse et expérimentée si vous voulez être prêt.
35) Au sujet des envahisseurs... Comment se porte la sécurité informatique de votre entreprise ? Il est facile de ne penser qu'à la flotte de production, mais que se passe-t-il si l'ordinateur portable d'un ingénieur est volé dans sa Camry ? Pouvez-vous le détecter avant qu'il ne soit signalé ? Pouvez-vous verrouiller et effacer à distance ? Invalider ses clés ?
Modération
36) Et encore une fois, comment va cette équipe de sécurité physique ? Quelqu'un essaiera absolument de brancher un Raspberry Pi sur votre réseau d'entreprise. C'est à 100 % certain. Ils essaieront d'usurper le wifi. Micros dans les bureaux exécutifs. Comme dans un film d'espionnage des années 1960. Je ne plaisante pas.
37) Modération du contenu. Vous avez besoin de 3 choses : une équipe géante de personnes vérifiant les rapports 24 heures sur 24, 7 jours sur 7, une autre équipe travaillant sur des outils pour aider cette équipe et des rendez-vous réguliers en psychiatrie pour la première équipe. Sans blague, encore une fois. L'humanité est SOMBRE. Vos modérateurs peuvent et vont se suicider.
38) Oups ! Vous n'avez pas embauché une équipe de modération de contenu. Votre site est plein de choses très désagréables. Tout le monde part parce que c'est si désagréable, ou (pire pour vous personnellement) vous êtes traîné devant les tribunaux pour avoir enfreint toutes sortes de lois sur la décence, le piratage et la confidentialité/le harcèlement.
39) Oups ! Vous n'avez pas embauché une équipe pour créer des outils pour vos modérateurs de contenu. Ils sont complètement submergés par les millions de rapports. Ils s'épuisent, vous ne pouvez pas les remplacer assez rapidement, et #38 arrive quand même
Source : différents scénarios auxquels pourrait être confronté Twitter
Et vous ?
Que pensez-vous de ces scénarios ? Lesquels vous semblent les plus probables ? Y en a-t-il qui vous paraissent exagérés ? 
Envoyé par Bill Fassinou
