Fiabilité des sites
Des points de terminaison sondés en parallèle, des incidents ouverts par la panne elle-même, et rien n’atteignant une page de statut publique sans qu’une personne n’approuve les mots.

Nouvelles tentatives · branches d’erreur · jalon humain
Le graphe de sondage surveille délibérément un point de terminaison qui ne se résout pas. Il retente deux fois avec un backoff, sort par la branche d’erreur, ouvre un enregistrement d’incident et alerte l’équipe propriétaire — et l’exécution se termine tout de même au vert avec les deux contrôles sains rapportés, car c’est ce que le graphe dit devoir se produire.
Le graphe d’admission route une alerte par gravité, fait rédiger par un modèle la phrase destinée aux clients, puis s’arrête : l’approbation est une ligne de base de données, si bien que l’exécution attend aussi longtemps que la décision le nécessite.
Le sondage, tel qu’il s’est exécuté

Comment les graphes fonctionnent
Un contrôle par point de terminaison, éclaté
Avec des nouvelles tentatives et un backoff sur chacun.
Un échec qui devient un incident
Un enregistrement d’incident et une alerte, pas une exécution morte.
Routage par gravité et une mise à jour de statut rédigée
Et une personne entre le brouillon et le public.
Le budget d’erreur du mois
Relu depuis une véritable base de données, avec le SQL dans le nœud.
Sur le canevas
http:get · __output_error · flow:approve · sql:sqlite* · views:metric
Il est livré avec le produit
Ce projet est livré avec DjiniousWorkflow. Une commande l’initialise, une autre exécute chaque graphe qu’il contient, et les captures ici proviennent de ces exécutions.
Là où un graphe s’appuie sur une fixture plutôt que sur un système en direct, il lit la fixture là où votre déploiement lirait une base de données — remplacez le nœud en tête et le reste du graphe ne change pas. Le travail du moteur — l’éclatement, le rassemblement, l’approbation, la publication — est celui du produit lui-même.
Continuer à explorer



