En tant que propriétaire de Simple Analytics, je pense qu'il est très important de gagner la confiance des utilisateurs. Il est pratiquement impossible de ne pas faire d'erreurs, donc si une entreprise ne partage jamais ses erreurs, elle ne vous dit probablement pas la vérité. Voici donc les miennes.
Chaque fois que vous créez une nouvelle fonctionnalité, vous voulez probablement la déployer aussi vite que possible parce que vous êtes trop impatient de la montrer à vos clients. Ou parfois, vous ajoutez un nouveau service à votre serveur et vous ne savez pas quel type d'implication il pourrait avoir. C'est ce qui m'est arrivé.
Au cours des deux dernières semaines, j'ai déployé une nouvelle fonctionnalité appelée Custom domain. Cette fonctionnalité permet aux utilisateurs de Simple Analytics de contourner les bloqueurs de publicité et les bloqueurs de suivi. Je pense que les gens devraient être autorisés à bloquer le suivi, c'est pourquoi Simple Analytics respecte le paramètre "Do Not Track" du navigateur. Malheureusement, Simple Analytics a été ajouté à certaines listes de blocage de la confidentialité, ce qui n'est pas juste puisque nous prenons la confidentialité très au sérieux (nous avons déplacé les serveurs dans un pays très respectueux de la confidentialité, à savoir l'Islande) : Islande ; cryptage de notre serveur de base de données ; suppression des données de la base de données lorsqu'un utilisateur efface quelque chose ; autorisation des personnes à télécharger leurs données). La nouvelle fonctionnalité a donc été très bien accueillie. Une fois qu'elle a été déployée, quelques utilisateurs ont commencé à l'utiliser.
Aujourd'hui, j'ai découvert un bogue (heureusement par moi-même) lors de l'utilisation de la fonctionnalité Custom domain: le JavaScript se chargeait, mais l'appel à l'API demandait un mot de passe. J'ai consulté le site web d'un de mes clients ([excuseme.wtf](https://excuseme.wtf/?ref={{ site.hostname }})) qui, je le sais, utilisait la fonction Custom domain-feature. J'ai vérifié ses statistiques et j'ai été horrifié de constater qu'il n'y avait eu aucune visite au cours de la dernière semaine. J'ai immédiatement commencé à fouiller dans mes serveurs, à la recherche d'indices.
Configuration actuelle
Simple Analytics utilise 4 serveurs pour que tout fonctionne le mieux possible. Nous avons le Queue-server, qui est le serveur de collecte des visites à partir de nos JavaScripts. Ce serveur est différent du serveur principal car ce dernier est crypté. Si un serveur est crypté, il ne doit démarrer qu'après avoir entré un mot de passe (sinon le cryptage est inutile). Dans le cas improbable où un redémarrage serait nécessaire, je veux garantir qu'il n'y aura aucune perte de données. Toutes les données seront envoyées au serveur d'attente qui les enverra au serveur principal. Si le serveur principal n'accepte pas la demande, le serveur de file d'attente la mettra en file d'attente (sauvegarde) lorsque le serveur principal sera en train de sauvegarder.
À côté de ces serveurs, j'ai un serveur de test et un serveur externe. Le serveur de test exécute des tests d'acceptation pour surveiller les flux et les points d'extrémité importants. Le serveur externe est nécessaire pour la fonctionnalité Custom domain. Pour des raisons de sécurité, je ne veux pas que les certificats SSL des clients se trouvent sur le même serveur que le serveur principal.
Qu'est-ce qui n'a pas fonctionné ?
J'ai décidé d'installer une nouvelle application de surveillance sur le serveur de file d'attente, de cette façon je pouvais vérifier à distance s'il y avait des problèmes sur le serveur. Cela m'a également permis d'avoir un aperçu de l'utilisation du processeur et de la mémoire. J'ai ajouté un fichier de configuration NGINX pour cette application afin de pouvoir y accéder de l'extérieur. Lorsque j'ajoute une nouvelle application, je teste toujours la configuration NGINX et la recharge en cas de succès sudo nginx -t && sudo nginx -s reload. NGINX n'a pas donné d'erreur et j'ai donc pu accéder à mon application de monitoring nouvellement installée ; je suis content.
Heureusement, j'ai un répertoire/enregistrement des logs de NGINX, à partir duquel je peux récupérer la plupart des requêtes perdues. Ces logs contenaient moins d'informations à l'époque et n'enregistraient que l'heure, l'URL et l'agent utilisateur.
Qu'ai-je fait pour éviter que cela ne se reproduise ?
Bien que ce bogue n'ait pas affecté un grand nombre de clients et n'ait pas entraîné de pertes de données importantes, je souhaite faire tout ce qui est en mon pouvoir pour éviter que cela ne se reproduise à l'avenir. Le bogue a été créé en ajoutant une autre application au même serveur qui n'avait pas de directive de serveur définie comme serveur par défaut. NGINX fait alors de son mieux pour sélectionner un serveur comme serveur par défaut et envoie les requêtes à l'application définie dans ce serveur.
Tout d'abord, j'ai ajouté le serveur par défaut à la directive listen pour les ports 80 et 443 dans l'application principale(docs nginx). L'application principale sur ce serveur était l'application externe qui gère les certificats pour la fonctionnalité Custom domain et répond avec un script et le point de terminaison de l'API n'utilise pas les URL de Simple Analytics, ce qui le rend difficile à bloquer.
Deuxièmement, j'ai augmenté l'historique des journaux à 90 jours afin de pouvoir récupérer les visites en cas de problèmes futurs. Le serveur de file d'attente et le serveur principal enregistrent désormais toutes les requêtes qui échouent. Cela signifie que toutes les requêtes qui renvoient un code HTTP 5xx ou 4xx seront enregistrées dans les journaux et pourront être récupérées. Cela nécessitera pas mal de travail pour le faire si nécessaire, mais cela signifie qu'il n'y a pas de perte de données.
J'ai ajouté des tests d'acceptation pour la fonctionnalité Custom domain qui vérifie si les deux points d'extrémité fonctionnent toujours comme prévu. Si ce n'est pas le cas, je recevrai un appel téléphonique et un message Telegram.
Enfin, je vais étiqueter les nouvelles fonctionnalités en tant que "version bêta", afin que les clients soient conscients ou s'attendent à ce qu'il y ait des erreurs car elles n'auraient pas été achevées pour la version finale. C'est donc aux clients de tenter leur chance et d'utiliser la fonctionnalité à leurs risques et périls.
J'ai contacté les clients concernés par ce bogue et leur ai proposé de les rembourser pour le mois. Ils n'ont pas jugé cela nécessaire et m'ont dit que je ne devais pas m'en préoccuper. J'ai fait de mon mieux pour récupérer la plupart de leurs données et grâce à toutes les actions mentionnées ci-dessus, je suis presque sûr que cela ne se reproduira plus.
Changeons la transparence autour des erreurs et je crois que les gens prendront votre entreprise plus au sérieux. Vous montrez ce que vous avez fait et à quel point vous êtes capable. Certains diront que c'est intelligent, mais je considère que c'est l'occasion de faire preuve de transparence.