Comment une limite de connexions à la base de données a failli redémarrer les Mac de mes clients

Nous gérons un petit parc de Mac mini pour des clients. Un démon sur une machine centrale interroge chaque Mac en SSH, envoie la télémétrie à un plan de contrôle, et escalade quand une machine se tait. D’abord, il attend. Ensuite, il coupe et rallume la machine via une prise connectée. Enfin, il appelle un humain.

La semaine dernière, le plan de contrôle s’est mis à renvoyer des erreurs 500. Treize minutes plus tard, le démon avait conclu que les quatre Mac étaient morts et enregistré une coupure de courant pour chacun. Deux appartenaient à des clients payants. Un troisième avait été vendu le matin même.

Ce qui a vraiment lâché

Un pool de connexions à la base de données. Le plan de contrôle tourne sur des fonctions serverless, devant un pooler Postgres plafonné à quinze connexions pour tout le projet. Quelques fonctions chaudes les ont toutes prises, et chaque route d’API adossée à la base s’est mise à échouer. Les détails sont dans un article séparé.

Les Mac allaient bien. SSH marchait. Chaque session graphique était ouverte. Le client qui compilait sur l’un d’eux n’a rien remarqué. La seule chose cassée était le système dont le travail était de savoir si les Mac étaient cassés.

Comment un parc sain a paru mort

Le démon gardait un horodatage par machine : la dernière fois qu’un sondage avait réussi. La logique d’escalade le comparait à l’instant présent. Le sondage commençait, assez logiquement, par récupérer la liste des machines auprès du plan de contrôle. Il s’arrêtait tôt quand cette requête échouait.

Pendant la panne, aucun sondage n’a donc tourné, aucun horodatage n’a avancé, et tous les écarts ont grandi ensemble. La logique d’escalade ne savait pas que le démon n’avait jamais essayé. Elle a vu treize minutes de silence venant de quatre machines, et elle a fait ce pour quoi elle était faite.

ladder: Unit 02 unreachable 12m51s → power cycle
ladder: Unit 03 unreachable 12m51s → power cycle
ladder: Unit 04 unreachable 12m51s → power cycle
ladder: Unit 05 unreachable 12m43s → power cycle

Pourquoi rien n’a redémarré

Aucune prise connectée n’était configurée. L’étape de coupure a cherché une prise, n’en a trouvé aucune, et est passée à la suite. Ensuite, les quatre machines affichaient des uptimes de six jours, six jours, un jour et environ une heure. Rien n’avait été touché.

C’est de la chance, pas de la conception. Les prises connectées font partie du plan pour le prochain lot de machines. Si elles avaient été installées, un problème de connexions à la base aurait coupé le courant de trois Mac clients. L’un d’eux était peut-être en plein build. Aucun n’avait rien fait de mal.

La correction

Le démon enregistre désormais la dernière fois qu’il a réussi à récupérer la liste des machines et à les contacter réellement. La logique d’escalade refuse d’agir si ce n’est pas récent, et elle note pourquoi : la faute vient du plan de contrôle, pas des machines.

ladder: skipped, no successful unit poll in 14m02s (control plane, not the units)

Cette ligne dit exactement ce qu’elle refuse de faire, et pourquoi. C’est ce que l’ancienne aurait dû dire dès la première fois.

La règle sous-jacente est simple. Une remédiation doit exiger la preuve que la vérification a tourné. "Nous avons essayé de le joindre et nous avons échoué", c’est une preuve. "Nous n’avons pas de nouvelles", non. Car c’est aussi à cela que ressemble une panne de celui qui écoute.

Quoi tester dans votre propre automatisation

Nous avions testé ce qui arrive quand un Mac meurt. Nous n’avions jamais testé ce qui arrive quand le système qui surveille les Mac meurt. Ce n’est pas le même test. Et c’est le second qui met la main sur l’interrupteur.