Djinious
Fiabilité des sitesExploitation d’entreprise

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.

DjiniousWorkflow
La page Fiabilité dans DjiniousWorkflow : points de terminaison qui répondent, pire budget d’erreur consommé, une note rédigée, les derniers contrôles de points de terminaison, les temps de réponse, le budget d’erreur par service et les minutes d’indisponibilité par jour.

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é

DjiniousWorkflow
Une exécution DjiniousWorkflow terminée : trois contrôles de points de terminaison parallèles, un nœud en échec en rouge portant son message d’erreur et son nombre de tentatives, le reste au vert avec leurs nombres d’exécutions, et un widget de tableau dessiné à l’intérieur de l’un des nœuds.
L’échec au milieu, c’est le produit qui fonctionne : deux nouvelles tentatives avec backoff, puis sortie par la branche d’erreur, qui a ouvert un incident et alerté le propriétaire. L’exécution s’est terminée au vert parce que c’est ce que le graphe dit devoir se produire.

Comment les graphes fonctionnent

  1. Un contrôle par point de terminaison, éclaté

    Avec des nouvelles tentatives et un backoff sur chacun.

  2. Un échec qui devient un incident

    Un enregistrement d’incident et une alerte, pas une exécution morte.

  3. Routage par gravité et une mise à jour de statut rédigée

    Et une personne entre le brouillon et le public.

  4. 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.