Halloween est probablement le moment le plus approprié pour commencer cette nouvelle série de blogs. Je parle beaucoup de théorie dans ce blog, mais lorsque vous êtes en première ligne d’un désastre de production, cela « devient réel » très rapidement. Les gens pensent souvent que les catastrophes de production sont des plantages ou des sites qui tombent en panne comme le récent temps d’arrêt de Facebook. Bien que ce soit un sujet intéressant, beaucoup de ces choses peuvent passer inaperçues et vous frapper comme un mur de briques.
L’histoire d’horreur d’aujourd’hui concerne une jeune startup qui a failli faire faillite à cause de la mise en cache. J’ai été le fondateur de cette entreprise et j’ai beaucoup écrit à ce sujet dans le passé. Cela fait quelques années que ça fait encore mal, j’espère pouvoir écrire d’une voix plus détachée cette fois-ci.
introduction
J’ai cofondé Codename One au début de 2012. La partie SaaS de l’entreprise était un backend complexe qui orchestre les serveurs de build. C’était en 2012, aucun conteneur/Docker ou quelque chose comme ça n’était disponible pour la production. Le PaaS était assez important à l’époque et App Engine gagnait du terrain.
Étant donné que Codename One est une boutique Java et qu’il fallait accélérer la prise en charge d’App Engine, car l’infrastructure avait beaucoup de sens. Google a donné gratuitement quelques ressources informatiques, ce qui a scellé l’accord. À l’époque, App Engine n’offrait pas SQL, uniquement un magasin de données. Encore une fois, nous avons décidé d’utiliser cela, si c’est assez bon pour exécuter Google, c’est assez bon pour exécuter notre petit produit.
Une chose importante que nous devons clarifier. App Engine disposait à l’époque d’un environnement de débogage local. Mais vous ne pouviez pas déboguer l’application car elle s’exécutait dans le cloud. Au cours des 2-3 premières années de Codename One, nous étions principalement satisfaits d’App Engine. Je l’ai même préconisé lors d’une conférence à JavaOne, etc. Une dernière chose importante à savoir est que Codename One est une entreprise amorcée. C’est un framework open source avec des fonds limités.
Grèves en cas de catastrophe
Un beau jour, nous avons reçu un e-mail indiquant que la facturation est élevée. Cela semblait étrange, mais nous nous sommes connectés pour vérifier. Notre facture mensuelle typique était d’environ 70$ + 400$ payés pour le support en or. La facturation à ce stade était déjà dans les 4 chiffres.
C’est là que l’hystérie s’est déclenchée. Nous n’avons pas ce genre d’argent !
Donc, le premier ordre du jour était de réduire toutes les ressources dont nous disposions, comme un certain nombre d’instances, etc. Mais ce n’était pas la raison du problème de facturation. Nous avons essayé d’obtenir de l’aide de l’équipe d’assistance Gold de Google, ce qui n’était « pas utile » (pour le moins). La seule suggestion de Google était de définir une limite de dépenses et de réduire efficacement notre service en conséquence.
La facturation a été entièrement attribuée à une seule ligne du relevé : « App Engine Datastore Read Ops ». Naturellement, nous voulions comprendre ce que cela signifie et quelle partie du code effectue toutes ces lectures. Malheureusement, en raison de la façon dont App Engine est construit (ou a été construit vers 2015), il n’y avait aucun moyen de le savoir. Pour aggraver les choses, notre seul outil de débogage était les journaux, qui coûtaient de l’argent. Donc, afin de déboguer ce problème de dépenses plus élevées, j’aurais besoin d’augmenter nos dépenses.
Les lectures du magasin de données App Engine sont connues pour être lentes. Nous avons donc supposé que c’était un problème là-bas. Google fournit une instance de Memcached que vous devez utiliser pour accéder au magasin de données. Pour autant que je sache, nous l’avons utilisé partout, ce qui était fréquemment utilisé pour mettre en cache tout ce qui était important. Mais il semble que nous ayons raté certains points et la nouvelle mise à jour d’App Engine l’a déclenché.
Résolution
Malheureusement, le déploiement d’une nouvelle mise à jour en production était le seul moyen de la déboguer ou de la corriger. Mais c’est pire. La facturation ne répertoriait pas les numéros « en direct » à l’époque (je ne sais pas si c’est le cas maintenant). Nous avons donc dû deviner des correctifs en ajoutant des couches de mise en cache puis redéployer et attendre une journée pour voir si le changement avait un impact sur la facturation. C’est littéralement le pire des cas, nous avons dû attendre 24 heures pour voir si la facturation était impactée par le correctif.
Pour cette raison, chaque tentative de correctif incluait de nombreuses améliorations différentes du code. À ce jour, nous n’avons aucune idée de ce qu’était le bogue et de ce qui l’a finalement résolu. Il est tout à fait possible qu’il s’agisse d’un bogue dans App Engine qui a été résolu par Google. Nous n’avons aucun moyen de le savoir.
Débriefing – Leçons apprises
Ce que nous aurions dû faire
J’y ai beaucoup réfléchi au fil des ans, qu’aurions-nous pu faire différemment pour éviter cela en premier lieu ? De plus, qu’aurions-nous pu faire différemment lorsque nous avons découvert le problème pour la première fois ?
Tests unitaires ?
Aurait-on pu écrire des tests unitaires qui auraient détecté ou reproduit le problème ?
Honnêtement, je ne sais pas. Nous avons utilisé JPA pour faire abstraction du stockage, je suppose que nous aurions pu nous moquer du stockage pour voir si l’accès est mis en cache. Avant que nous ayons le problème, c’était un joli test de niche que nous n’aurions probablement pas écrit.
Lors du débogage, nous avons essayé de reproduire le problème avec un test ou dans le débogueur. Nous n’avons pas pu reproduire le problème. Si nous avions eu plus de temps pour déboguer le problème et développer un test unitaire, nous aurions peut-être pu le reproduire dans un test unitaire. Mais nous travaillions contre la montre. Un médecin qui essaie de soigner un patient qui saigne n’a pas le temps pour des tests complexes.
Étant donné que ce problème s’est produit en dehors de notre code, même si nous avions une couverture de test à 100%, nous n’aurions pas vu le problème. Ainsi, alors que les tests unitaires sont en effet un outil précieux, dans ce cas, je ne vois pas en quoi ils auraient aidé au préalable.
Observabilité
Cela a vraiment mis en évidence l’importance de l’observabilité et son absence. L’un de mes plus gros problèmes avec Google dans cette affaire est : ils ont facturé l’accès en lecture au magasin de données. Mais ils ne peuvent pas me dire à partir de quels magasins de données je lis (de quelle entité/table). Avoir une direction générale indiquant où le problème se produisait aurait pu nous faire économiser des milliers de dollars.
Les outils d’observabilité sont cruciaux et ils doivent pouvoir creuser dans une granularité profonde.
Rétroaction instantanée
Cela semble être un luxe dans presque tous les autres cas, mais ici, nous avons vu exactement à quel point cela peut être important. Le cycle test/déploiement/attente nous a littéralement coûté des milliers de dollars, à cause d’un problème qui a duré quelques jours. Imaginez si nous étions une plus grande entreprise avec plus de trafic… Nous aurions pu perdre des millions.
Lorsque vous rencontrez un problème de production, vous avez besoin de vos outils pour le signaler instantanément. Vous devez connaître le problème exact et vous devez savoir si votre solution a fonctionné. En raison de la nature d’App Engine, nous n’avions aucun moyen d’utiliser certains des outils disponibles à l’époque. Rétrospectivement, nous avons besoin de meilleurs outils.
Débogage local
Il y a un mouvement qui s’oppose à l’idée de déboguer localement (au moins en sans serveur). Je vois certains de leurs points. Par exemple, dans ce cas, le débogage local n’a pas reproduit le problème. Cela nous a donné une fausse confiance que les choses fonctionnaient, et elles ne l’ont pas fait.
Mais je ne suis pas sûr d’être d’accord avec le résultat final. Je pense que le débogage local devrait être plus proche de la production. Je pense toujours que nous avons besoin d’outils pour déboguer la production, mais ils devraient être en plus d’un environnement local de travail.
Limite de dépenses
À ce jour, je ne sais pas si j’ai pris la bonne décision de sauter la limite de dépenses. Devrions-nous simplement laisser le service tomber en panne pendant quelques jours pendant que nous « résolvons des problèmes » ? Honnêtement, je ne sais pas.
Êtes-vous à risque?
Vous pourriez être tenté de penser que vous ne courez aucun risque. Vous n’utilisez pas App Engine, vous n’utilisez probablement pas PaaS. Cependant, les API sans serveur et tierces présentent un risque similaire. C’est un problème très courant, par exemple quelqu’un s’est même piraté accidentellement avec une feuille de calcul. Une autre équipe a reçu une facture de 72 000 USD pour un compte gratuit.
Ces histoires sont partout.
Si vous choisissez d’utiliser de tels services, vous DEVEZ définir une limite de dépenses. Vous devez également utiliser des outils d’observabilité et configurer des déclencheurs pour vous avertir si quelque chose change.
Épilogue
Il y a quelques années, j’ai rencontré les fondateurs de Lightrun. Ils ont décrit leur vision de l’entreprise qui est en fait un débogueur de production qui nous donne un retour instantané en toute sécurité. J’ai tout de suite pensé à cette histoire.
Qu’aurais-je pu faire avec cet outil à l’époque ? Les idées prennent du sens lorsque nous ressentons la douleur et j’ai ressenti la douleur profondément. Cela a rendu la décision de rejoindre Lightrun une évidence. Donc je suppose que cette histoire d’horreur a une fin heureuse.
Sommaire
L’histoire effrayante d’aujourd’hui concerne une jeune entreprise prometteuse qui s’est aventurée dans un environnement qui semblait accueillant et sain. Seulement pour découvrir que la facturation a soudainement basculé du jour au lendemain et que les frais étaient énormes.
Vous pourriez être le prochain, car de nombreuses jeunes entreprises ont vécu ce cauchemar.
Racontez votre histoire
Avez-vous une histoire intéressante de catastrophe de production à partager ?
Écrivez-moi à shaia (at) lightrun (dot) com. Si vous voulez que votre nom/nom de l’entreprise soit supprimé, je serais heureux de vous obliger. Je peux offrir une boîte de butin Lightrun super cool en récompense, notre butin ici est de premier ordre !
Hâte de vous entendre.