Systèmes de négociation
Pourquoi les états en cours, en pause et arrêté comptent, comment les interpréter et ce qu’une interface opérationnelle claire doit communiquer.
Le moyen le plus rapide de perdre confiance dans un système est de cacher son état d'exploitation. Les états d'exécution définissent si le logiciel peut évaluer les entrées, soumettre de nouvelles demandes, poursuivre la surveillance ou attendre la récupération. Les étiquettes claires comptent, mais les règles de transition et les conséquences opérationnelles derrière chaque étiquette comptent davantage.
Un système peut fonctionner et a encore besoin d'attention. L'état d'exécution devrait être visible parallèlement au contexte d'événement afin que les opérateurs sachent ce que le logiciel fait.
Une interface utile associe l'état à une activité récente, de sorte qu'un opérateur peut faire la différence entre un flux de travail qui fonctionne normalement et un flux de travail qui fonctionne mais qui est coincé derrière une entrée qu'il n'a jamais reçue.
L'opérateur doit cesser intentionnellement de nouvelles actions tout en préservant la visibilité et le contexte. C'est un état de contrôle, pas une vague défaillance partielle.
La pause doit également être réversible et attribuable. L'interface devrait enregistrer qui a interrompu le flux de travail et quand, donc la reprise est une décision plutôt qu'une supposition.
L'arrêt signifie que le système ne prend pas de nouvelles mesures. Cet état doit être explicite tant dans l'interface que dans le modèle d'exploitation.
L'ambiguïté est chère. Si arrêté peut signifier calmement partiellement arrêté, le modèle d'exploitation a une lacune que aucune quantité de polissage d'interface ne fermera.
La plupart des confusions opérationnelles se produisent entre les États plutôt qu'à l'intérieur. Que se passe-t-il lorsqu'un flux de travail est interrompu? Quelles données ou actions sont abandonnées lors de l’arrêt? Qui est autorisé à le reprendre?
Répondre à ces questions pendant la phase de conception est beaucoup moins cher que de répondre à ces questions lors d'un incident.
Une interface d’exécution bien conçue passe un test simple: un nouvel opérateur devrait pouvoir répondre à ces questions d'un seul écran, sans demander à un collègue.
Pour chaque État, déterminer si de nouveaux signaux sont évalués, si de nouvelles demandes de commande peuvent être présentées, comment les commandes ouvertes sont traitées, si la surveillance de la position se poursuit, quelles alertes demeurent actives et qui peut se retirer. Il peut s'agir d'arrêter les nouvelles présentations pendant que la surveillance se poursuit; l'arrêt peut nécessiter un arrêt pur et un processus de rétablissement distinct. La politique exacte doit être visible plutôt que déduite de l'étiquette.
Tester les transitions au cours d'une demande ouverte, les données du marché, la déconnexion du courtier, le changement de configuration et le redémarrage. Si le système ne peut pas établir l'état actuel de la plateforme, il devrait entrer dans la récupération ou l'examen plutôt que de retourner directement à l'exécution. Ces contrôles gèrent le fonctionnement du logiciel; ils ne suppriment pas le risque de négociation.
| État | Nouvelles communications | Surveillance | État de sortie |
|---|---|---|---|
| Courir | Autorisé par des gardes configurés | Tous les contrôles nécessaires sont actifs | Pause, arrêt, défaillance ou défaillance de la garde |
| Paus | Bloqué | Poursuivre les vérifications de compte et de commande définies | Cause dégagée et de reprendre les gardes passent |
| Récupération | Bloqué | Réconcilier l'état local et le lieu | Différences résolues ou attribuées |
| Arrêts | Bloqué | Maintenir la visibilité requise en matière de santé et de vérification | Procédure de redémarrage explicite |
Questions pratiques
Les États définissent ce que le système est autorisé à faire ensuite. Les statistiques décrivent ce qui s'est déjà passé. Les opérateurs ont besoin du premier à agir et du deuxième à examiner.
C'est une décision de conception qui doit être documentée. La partie importante est que le comportement est explicite dans l'interface plutôt que découvert lors d'un incident.
Assez peu pour être mémorable et distinct. Courir, s'arrêter et couvrir la plupart des besoins opérationnels, à condition que les transitions entre eux soient clairement définies.
Poursuivre l’exploration
Collaborer avec Sun Cluster
Les ingénieurs Sun Cluster ont automatisé les systèmes de négociation avec un état d'exécution explicite, des garanties opérationnelles et des chemins de récupération.
