La ligne de code qui a gaspillé 8 000 dollars

• À cause d’un bug de mise à jour automatique dans Screen Studio, une app d’enregistrement d’écran pour macOS, un fichier de 250 Mo était retéléchargé toutes les 5 minutes
• Résultat : en un mois, 2 Po (2 000 000 Go) de trafic ont été générés sur Google Cloud, entraînant une facture d’environ 8 000 $
• La cause était un simple oubli dans le code : la logique qui devait arrêter les requêtes répétées après le téléchargement de la mise à jour avait été omise
• Pour certains utilisateurs, cela a même provoqué des dommages concrets, comme la résiliation de leur service Internet, et l’équipe de développement a pleinement reconnu sa responsabilité
• L’incident met en avant plusieurs leçons : configurer des alertes de coûts cloud, relire le code susceptible d’engendrer des dépenses, et prévoir des mécanismes de contrôle côté serveur pour les mises à jour

---

Aperçu de l’incident

• Screen Studio est une application d’enregistrement d’écran de bureau pour macOS, avec une fonction de mise à jour automatique
• Le fichier de mise à jour pèse environ 250 Mo, et l’app vérifie le serveur toutes les 5 minutes
• À cause du bug, même après détection de la mise à jour, les requêtes toutes les 5 minutes ne s’arrêtaient pas et relançaient sans cesse le téléchargement

Le début du refactor fatal

• Auparavant, la fenêtre pop-up de mise à jour gênait l’enregistrement et posait un problème d’UX
• Lors d’un refactor destiné à améliorer ce point, la logique qui arrêtait le timer après la mise à jour a été supprimée
• Résultat : la logique de téléchargement répétitif du fichier de mise à jour s’est retrouvée intégrée dans l’application

Le contexte inquiétant : exécution en arrière-plan

• Un grand nombre d’utilisateurs laissaient l’app tourner en arrière-plan pendant plusieurs semaines
• Dans cet état, des milliers d’instances téléchargeaient automatiquement 250 Mo toutes les 5 minutes

La catastrophe en chiffres

• Un téléchargement toutes les 5 minutes = 288 fois par jour
• Trafic téléchargé quotidien par utilisateur = 72 Go
• Sur environ 30 jours, en supposant 1 000 utilisateurs :
  • 250 Mo × 288 × 30 × 1 000 = environ 2 Po de trafic
• Coût estimé sur Google Cloud : environ 8 000 $

La chaîne d’erreurs

• Aucune alerte de coût Google Cloud n’était configurée
• L’équipe se reposait sur un coût mensuel historique d’environ 300 $
• Le problème n’a finalement été repéré qu’après le blocage des transactions à cause du dépassement de la limite de carte bancaire

Les dommages côté utilisateur

• Pour un utilisateur, ce trafic a conduit son FAI (fournisseur d’accès à Internet) à notifier une résiliation du contrat de service
• Aucun fournisseur alternatif dans sa zone → fortes perturbations au quotidien
• L’équipe a reconnu sa responsabilité et proposé une compensation des coûts ; heureusement, la situation s’est réglée à l’amiable
• Mais avoir causé du tort à un utilisateur a laissé aux développeurs un profond sentiment de remise en question

Résumé des leçons

• Les alertes de coûts cloud sont indispensables
• La logique de mise à jour automatique doit être écrite avec une extrême prudence
• Tout code susceptible de générer des coûts doit faire l’objet d’une revue particulière
• Prévoir des signaux de contrôle côté serveur (par ex. un flag de mise à jour forcée) dans la conception
• Vérifier régulièrement l’état d’utilisation du cloud

[GN⁺]

Avis Hacker News

• Pour ceux qui trouveront ce fil via une recherche web à l’avenir : screen.studio est un logiciel d’enregistrement d’écran pour macOS qui vérifie les mises à jour toutes les 5 minutes. Mais le bug décrit dans ce post consiste à télécharger un fichier de mise à jour de 250 Mo toutes les 5 minutes

  • Les développeurs considéraient tout cela comme normal, mais les téléchargements réels ont entraîné 8 000 $ de frais de bande passante
  • En résumé : le logiciel d’enregistrement d’écran vérifie les mises à jour toutes les 5 minutes. Cela fait 12 fois par heure
  • Je choisis les logiciels en fonction du degré de confiance que j’ai dans le jugement du développeur. Je vous invite à vous demander si ce jugement est raisonnable

• Screen Studio est un enregistreur d’écran pour macOS. C’est une application de bureau. Ils affirment qu’une mise à jour automatique est nécessaire pour installer facilement la dernière version

  • Mais la mise à jour automatique entraîne plusieurs conséquences négatives
  • Elle télécharge des mises à jour sans le consentement de l’utilisateur, ce qui génère du trafic côté client
  • Le téléchargement se répète en continu toutes les 5 minutes. On peut se demander s’ils détectent si l’utilisateur est sur une connexion limitée
  • Il y a un bug où la fenêtre pop-up de mise à jour interrompt le flux de travail
  • La pop-up elle-même offre une mauvaise expérience utilisateur. Il vaudrait mieux l’autoriser à la fermeture de l’app et gérer le reste en arrière-plan
  • Certains utilisateurs surveillent de près les connexions sortantes de leurs applications, et vérifier les mises à jour toutes les 5 minutes est excessif. Il n’est pas nécessaire de le faire pendant l’exécution de l’application. Mieux vaut vérifier au démarrage et demander à la fermeture
  • Toute la complexité supplémentaire de l’application a provoqué les problèmes ci-dessus. Cela engendre aussi des coûts pour le développeur
  • L’App Store pourrait être, dans ce cas, une manière parfaite de gérer les mises à jour

• Il est absurde qu’un développeur d’une application non essentielle comme un enregistreur d’écran pense devoir vérifier les mises à jour toutes les 5 minutes

  • Une fois par jour serait largement suffisant

• Je doute vraiment qu’il soit nécessaire de vérifier les mises à jour toutes les 5 minutes. Une fois au démarrage suffit, et même si l’utilisateur laisse l’application ouverte plusieurs jours, on pourrait vérifier une fois par jour, voire moins souvent

• Je suis toujours strict sur les revues de code. Une fois, quand un manager m’a dit d’en laisser davantage à la QA, j’ai répondu : « Nous pourrions tous perdre notre emploi. Nous pouvons toujours perdre notre emploi à cause d’une seule mauvaise ligne de code »

  • Il arrive souvent que des développeurs juniors ou expérimentés écrivent quelque chose qui entraîne une fuite potentielle de PII. Dans la plupart des systèmes, cela peut très facilement provoquer des problèmes juridiques

• Le problème de la bande passante gaspillée inutilement sur les forfaits de données de milliers d’utilisateurs

  • Ce genre d’erreur négligente peut provoquer de la congestion pour tous les utilisateurs d’Internet
  • Si cette erreur avait été absorbée non pas par une facture de 8 000 $, mais par l’offre gratuite de Google Cloud ou un autre plan, je me demande si elle aurait tout de même été considérée comme un bug grave et corrigée rapidement
  • Combien de conceptions défectueuses génèrent du trafic et consomment des ressources communes ?

• Quand j’ai distribué une application de bureau Mac :

  • Nous utilisions Sparkle pour gérer les mises à jour. Choisir leur propre système de mise à jour a été une mauvaise décision
  • Notre application était très complexe et était distribuée avec Mono. Pourtant, elle faisait environ 10 Mo. La version Windows faisait 2 Mo et incluait des binaires 32 bits et 64 bits. Je me demande pourquoi ils distribuent un enregistreur d’écran de 250 Mo
  • Ils ne semblent pas avoir retenu la leçon. Tout l’article les fait passer pour des idiots

• Je suis surpris que « de meilleurs tests » ne soient pas mentionnés dans le résumé

  • La suggestion « écrivez le code avec soin » ressemble à une erreur de débutant
  • Il est extrêmement frustrant que les développeurs utilisent les appareils des utilisateurs comme banc de test

• Je suis prudent quant à l’adoption de bibliothèques tierces (car chacune peut devenir une source de problèmes à long terme), mais les mises à jour d’application en valent la peine

  • C’est fondamentalement un gros cas limite, et c’est une partie importante du plan de reprise si l’application a un bug grave
  • Ce bug n’est pas le seul problème de leur système de mise à jour. Vérifier toutes les 5 minutes, c’est complètement fou. Cela montre qu’ils n’y ont pas réfléchi sérieusement

• J’exploite un service de proxy anti-censure qui utilise des fichiers Proxy Auto-Configuration (PAC)

  • Si le fichier contient du mauvais JS, ou si sa taille dépasse 1 Mo, alors quand il est configuré à l’échelle du système, toutes les applications continuent à envoyer des requêtes au serveur
  • Cela a fini par DDoS mon serveur et faire bloquer l’IP au niveau BGP
  • Plus de 500 000 utilisateurs s’en servent chaque jour. Mon serveur web tourne sur un VPS à 20 $ par mois avec trafic illimité. Grâce à cela, je ne me suis pas retrouvé dans la même situation que l’auteur du post