Menu
La récente déconvenue du service de cloud computing d’Amazon est l’occasion de rappeler qu’en informatique « everything fails all the time », comme le disait déjà Werner Vogels, directeur technique d’Amazon, ou plus crûment « shit happens ». Plutôt que de prévenir à tout prix il vaut mieux parfois guérir, c’est à dire savoir quoi faire en cas d’erreur, et ce d’un point de vue technique mais surtout et avant tout d’un point de vue métier.
Cela me permet de mettre en lumière les « erreurs » et de voir que plutôt que de les éviter il vaut mieux réfléchir de manière globale sur la place des erreurs dans le système.
Afin d’illustrer ce propos je vous propose la description du fonctionnement des cafés starbucks réputés non pour la qualité de leur café mais pour le volume de commande par heure (autrement dit le débit ou throughput en anglais). Ce fonctionnement est l’occasion d’illustrer un nombre important de principes liés à l’informatique distribuée avec un exemple de la vie courante.
Comment se déroule une commande chez starbucks ?
Voici une user story et un scénario typique :
- User Story:
- En tant que client
- Je veux passer ma commande
- Afin de pouvoir déguster mon café rapidement
- Scénario:
- Etant donné un caissier disponible
- Lorsque le caissier me demande ma commande
- Quand j’indique un double expresso macchiato
- Alors le caissier transmet la commande ‘double expresso macchiato’ au barrista <- lancement asynchrone de la réalisation du café SANS attendre la fin du traitement de paiement
- Alors le barista accuse réception en répétant la commande
- Alors le caissier m’indique que le prix est de 3 €
- Quand je paye en espèce avec un billet de 5 €
- Alors le caissier me rend la monnaie de 2 € avec le ticket
- Lorsque le barrista indique la commande ‘double expresso macchiato’
- Quand j’acquiesce pour cette commande
- Alors le barrista me donne mon ‘double expresso macchiato’
C’est intéressant de noter l’asynchronisme introduit lorsque le caissier transmet la commande au barrista alors que l’encaissement n’est pas terminé. Mais alors, que se passe t’il en cas d’erreur dans l’un des traitements ?
- Cas de l’encaissement non effectué (pas assez de monnaie, carte bloquée, etc.) : le café est tout simplement jeté ou fourni à un autre client s’il s’avére que la commande était identique,
- Cas de la commande en erreur (caissier a mal compris la commande, le barrista a mal compris, etc.) : la commande est tout simplement refaite.
- etc.
Les mécanismes possibles afin de traiter une erreur
- « Laisser tomber » : dans le cas où la conséquence de l’erreur est négligeable (comme un café par exemple)
- « Réessayer » : utile surtout en cas d’indisponibilité d’un des maillons de la chaîne, exemple de la vie courante : le caissier répète plusieurs fois le nom de la commande jusqu’à recevoir un retour du barrista
- « Compenser » : que fait ma banque lorsqu’elle a facturée indument un service par un débit ? Elle crédite mon compte de la somme correspondante, ce qui compense l’erreur.
Bénéfices
L’asynchronisme introduit après la prise de commande permet d’augmenter le taux d’occupation de chacun des acteurs, le barrista n’attendant pas la fin du paiement pour démarrer la réalisation du café. J’ai même parfois remarqué que lors d’affluence chez Starbucks un acteur intermédiaire prend la commande en avance, jouant ainsi le rôle de dispatcher vers les deux files de traitement : paiement et réalisation.
La conséquence d’une erreur dans l’une ou l’autre des chaines de traitements est négligeable au regard du gain énorme obtenu dans le débit (throughput) du système. Le point important à noter étant que plutôt que d’éviter à tout prix une « erreur » dans les traitements, celles ci sont considérées comme faisant partie intégrante du système avec des actions qui sont prévues lorsqu’elles surviennent.
Le fonctionnement de starbucks permet d’illustrer que plutôt que de mettre en place des mécanismes évitant toutes erreurs avec l’introduction d’un élément centralisateur (pas de café réalisé si le paiement n’est pas effectué), il est parfois préférable d’accepter des erreurs afin d’augmenter le taux d’occupation de chacun des acteurs du système. Chaque erreur potentielle est donc à mettre en regard de sa conséquence.
Ce mode de fonctionnement met également en oeuvre le principe d’identifiant de corrélation : c’est à dire comment je corrèle deux traitements exécutés indépendamment afin de finaliser le traitement global. Dans notre cas, comment le client récupére le café qu’il a commandé après avoir payé. Il faut donc corréler le client, son paiement et sa commande. Cela est effectué de différentes manières suivant les établissements Starbucks et les pays, on trouve ainsi comme identifiant de corrélation :
- Le nom du café commandé : surtout en Europe
- Le nom du client : j’ai surtout expérimenté cela aux états-unis, à noter que cela renforce le côté sympa car je préfère entendre mon prénom plutôt qu’un impersonnel « le double espresso Machiatto c’est pour qui ? »
Conclusion
J’aime bien cet exemple de chez Starbucks car la transposition dans le monde physique d’un mécanisme, et l’intuition qui va avec, est un excellent moyen de conception ou de compréhension de quelque chose qui peut rester obscur sinon. Cela permet également d’illustrer des mécanismes utilisés dans des systèmes distribués et asynchrones :
- Asynchronisme
- Identifiant de corrélation
- Gestion d’erreur
Au final c’est surtout l’occasion de montrer qu’une gestion d’erreur « métier » intégrée de manière globale dans l’ensemble de la chaîne permet une optimisation permettant des gains considérables de débit sur l’ensemble du processus.
Cet article est inspiré par cet ancien article de Gregor Hohpe « Starbucks does not use two phase commit« . Je recommande également cet autre article de Gregor « Let’s have a conversation » où il compare les échanges entre deux systèmes comme une conversation que peuvent avoir deux personnes.
