Le provisionnement est une machine à états, pas une action
Personne qui a construit des systèmes d’approvisionnement en ressources d’infrastructure ne croit simplement à la « création ». Créer est un parcours : valider la demande, réserver de la capacité, allouer des ressources, configurer, activer. Chaque étape peut échouer, et lorsqu’une étape échoue à mi-parcours, vous vous retrouvez avec quelque chose qui n’est ni vraiment une ressource ni absolument rien. Les objets à moitié créés sont une réalité dans les systèmes de provisionnement à grande échelle. Le code qui les trouve, les termine ou les balaie est le lieu où réside une grande partie de la véritable ingénierie.
La facturation a la même forme. Un abonnement n’est pas un événement ; c’est une machine à états : essai, actif, en retard, mis en pause, annulé. Les bugs intéressants résident tous dans les transitions : la mise à niveau qui s’est appliquée à moitié, le changement de plan prévu pour la fin de la période qui s’est déclenché deux fois, l’essai qui s’est converti mais a conservé son prix d’essai. Si vous avez déjà recherché une VM qui existe dans la base de données mais sur aucun hôte, vous comprenez déjà l’abonnement qui facture un forfait que le client ne peut pas voir.
Prenons l’exemple d’un client qui effectue une mise à niveau en milieu de cycle. Le changement de plan s’engage sur le dossier d’abonnement, mais le service d’admissibilité n’en entend jamais parler. Le client paie la mise à niveau mais ne reçoit pas l’accès correspondant. Trois semaines plus tard, le support reçoit un ticket. L’assistance peut voir le montant facturé, mais pas le droit manquant. Il s’agit du jumeau d’abonnement de la VM qui existe dans la base de données mais sur aucun hôte : le parcours de création est arrivé à mi-chemin et personne ne l’a balayé.
