Mandats

Un mandat est une instruction permanente définissant sur quoi Coroid doit travailler en l'absence de demande explicite : un objectif, les projets concernés, un budget hebdomadaire ou mensuel, et la date limite d'exécution. Les demandes émanant de vos systèmes — l'interface d'entrée de travail API, les automatisations, les intégrations, la surveillance — sont prises en compte selon vos mandats actifs. Ce n'est pas le cas pour les demandes formulées par des personnes ; consultez Quelles demandes sont régies par un mandat ?.

Un mandat détermine quels travaux peuvent être lancés. Il n'autorise pas Coroid à fusionner ou déployer quoi que ce soit. Consultez Ce que décide Coroid, et ce qui reste sous votre contrôle..

Quand un mandat est-il pertinent ?#

Rédigez un mandat lorsque du travail parvient à Coroid sans que personne ne sollicite chaque tâche individuellement, et que vous souhaitez définir à l'avance l'étendue de son exécution :

• un outil de suivi d'erreurs ou de surveillance qui signale les incidents via l'interface d'entrée de travail API ;
• les notifications de GitHub, ou les messages Slack, Telegram et Jira, provenant d'un Qualifier le travail une automatisation les transforme en demandes ;
• un outil de support ou de retours clients qui transmet les signalements des utilisateurs ;
• un scanner ou une tâche d'intégration continue qui enregistre les résultats un par un.

Sans mandat, ces demandes sont traitées comme toutes les autres : une fois qualifiées, elles rejoignent la file d'attente des mêmes emplacements d'agents que les travaux demandés par les personnes, sans budget propre. Une semaine chargée d'alertes peut alors saturer votre file d'attente. Un mandat les encadre : les projets qu'ils peuvent toucher, leur budget hebdomadaire ou mensuel, et le nombre d'emplacements d'agents qu'ils peuvent occuper simultanément.

Comment une demande est-elle traitée ?#

Prenez le mandat illustré ci-dessus, établi pour un projet appelé Facturation API. Son outil de suivi d'erreurs génère une alerte pour une nouvelle exception lors de l'exportation de factures. Le webhook de la règle d'alerte, via un petit relais de votre création, la soumet à l' interface d'entrée de travail API, en indiquant l'ID de l'incident comme empreinte du signal, la route affectée, et 500 requêtes comme niveau d'exposition nécessaire avant de juger de la correction.

1. Qualification s'effectue comme pour toute demande : suppression des secrets et données personnelles, vérification de la version en cours, recherche de doublons, validation du rapport et évaluation.
2. Admission cherche le mandat couvrant Facturation API et vérifie, dans l'ordre : si le même incident est déjà traité, ici ou dans un autre projet ; si l'évaluation confirme le comportement attendu ; si l'un des deux emplacements du mandat est libre ; si le budget de la semaine le permet ; et si le résultat peut être mesuré.
3. Admise, la demande devient une tâche disposant d'un emplacement réservé et d'une partie du budget hebdomadaire. Elle suit le processus habituel — spécification, code, tests, contrôles de qualité, Révision et inspection — pour aboutir à un pull request.
4. Une personne fusionne celle-ci. La contrat de résultat précise ce que cette fusion doit accomplir : aucun nouvel événement lié à cet incident pendant 24 heures après 500 requêtes sur la route concernée.

Si la même alerte se déclenche à nouveau, la deuxième demande est Déjà résolu et lié au premier. Si une mauvaise déploiement génère six nouveaux problèmes en même temps, au maximum deux d'entre eux sont traités sous le mandat à la fois ; les autres sont reportés, puis admis un par un lorsque les créneaux du mandat se libèrent. Les deux autres créneaux d'agents restent disponibles pour les demandes de votre équipe dans Nouveau travail.

Exemples de mandats#

Éviter l'accumulation des erreurs de production#

Les services API de votre entreprise signalent les erreurs à un outil de suivi d'erreurs, et leur correction s'effectue lorsque quelqu'un a le temps.

Les demandes proviennent de l'outil de suivi d'erreurs via l'interface d'entrée de travail API, chacune avec un signal indiquant l'ID du problème dans l'outil de suivi, les routes et un nombre de demandes. Chaque problème donne lieu à au maximum une tâche de travail, peu importe sa fréquence d'apparition. Une mauvaise semaine coûte au maximum 100 USD. Une alerte envoyée sans routes est mise en attente plutôt qu'initiée, car rien ne permet de savoir si sa correction a fonctionné ; indiquez les routes ou activez Admettre le travail dont l'issue ne peut être mesurée.

Traiter les bogues signalés dans GitHub#

Les utilisateurs ouvrent des problèmes dans le dépôt de votre application web plus rapidement que quiconque ne peut les trier.

Une Évaluer la tâche L'automatisation sur les nouveaux problèmes GitHub en crée un pour chaque cas. Cette évaluation évite les doublons, signale les problèmes déjà corrigés dans la version actuelle et indique qu'ils ne peuvent pas être reproduits. Le commutateur de mesurabilité est activé car le problème ne mentionne aucune route ou trafic, donc son contrat d'issue ne peut pas être mesuré ; si ce commutateur est désactivé, chaque problème attendrait. Les problèmes ouverts par des personnes ayant un accès en écriture démarrent automatiquement ; les autres attendent qu'on les lance, comme décrit dans Lorsque le travail commence.

Agir sur les retours des clients#

Votre outil de support collecte les rapports des clients, et les plus urgents n'arrivent à l'équipe ingénierie qu'en retard.

L'outil de support enregistre chaque rapport via l'interface d'entrée de travail API avec un compte de service. L'évaluation écarte ce qui ne peut pas être reproduit, et le mandat empêche qu'une semaine chargée de rapports occupe plus de la moitié des créneaux d'agent ou dépasse son budget.

Terminer un nettoyage avant une date limite#

Le SDK de paiement que vous utilisez atteint la fin de son cycle de vie au prochain trimestre, et ses appels obsolètes sont répartis sur deux services.

Un job CI crée une demande par site d'appel, en utilisant le fichier et la ligne comme empreinte digitale du signal ; ainsi, un site d'appel retrouvé lors de l'exécution suivante est lié au travail déjà en cours de traitement. Coroid n'interprète pas encore la cible : lorsque le dernier appel disparaît, choisissez Terminer vous-même.

Lorsque vous n'avez pas besoin d'un mandat#

• Le travail que les personnes demandent. Les demandes créées dans Nouveau travail ou importées sont acceptées si elles remplissent les critères, sans jamais être reportées ni consommer le budget d'un mandat.
• Calendriers et suivis via des hooks. Ils créent des tâches directement, sans Qualification, donc aucun mandat ne les limite. Attribuez-leur plutôt une priorité inférieure ; consultez Calendriers.
• Une initiative ponctuelle. Un travail ayant une forme connue et une fin définie est un plan, pas un mandat.
• Mandats chevauchants. Lorsque plusieurs mandats actifs couvrent le même projet, le plus ancien gère ses demandes. Attribuez chaque projet à un seul mandat.

Où se trouvent les mandats#

Ouvrir Contrôle qualité → Mandats. Chaque périmètre dans Contrôle qualité — la valeur par défaut de l'organisation et chaque projet — est lié à la même liste, car un mandat appartient à l'organisation et nomme lui-même ses projets. Ouvrir le périmètre d'un projet ne filtre pas la liste.

Les propriétaires et administrateurs créent et modifient les mandats. Les membres peuvent les consulter. Les agents et comptes de service ne peuvent absolument pas modifier un mandat.

Ce qu'un mandat contient#

Type. Les mandats finis ont une cible et s'achèvent lorsqu'elle est atteinte, par exemple « réduire à zéro les vulnérabilités de sécurité non résolues ». Les mandats assortis d’un objectif prennent fin lorsqu’il est atteint, par exemple « ramener à zéro le nombre de problèmes de sécurité non résolus ». Les mandats en cours concernent la maintenance, par exemple « maintenir les routes de production exemptes d'exceptions non gérées » ; ils ont une date de revue plutôt qu'une cible. Les mandats de maintenance consistent en une maintenance, par exemple « maintenir les routes de production exemptes d’exceptions non gérées » ; ils ont une date de révision plutôt qu’un objectif.

Objectif. Une phrase décrivant ce qui devrait être vrai. C'est ainsi que les gens lisent le mandat ; l'acceptation elle-même dépend du périmètre, du budget et de l'état.

Référence. La métrique utilisée pour mesurer le mandat et sa source. Vous nommez la métrique, et les relevés sont collectés par Coroid, sans jamais être saisis manuellement. Ils ne figurent jamais dans les exports de paramètres. Un nouveau mandat affiche Aucun relevé pour l'instant.

Cible. Pour un mandat fini : la métrique et la valeur indiquant que l'objectif est atteint.

Priorités. Une par ligne. Lorsque le travail entre en concurrence pour la capacité, la première priorité l'emporte.

Périmètre.

• Projets. Les projets couverts par le mandat. Si aucun n'est sélectionné, il couvre tous les projets de l'organisation, y compris ceux créés ultérieurement. Cochez les projets concernés ; un mandat destiné à un seul dépôt doit nommer ce projet.
• Zones. Les motifs de chemins au sein de ces projets, un par ligne, par exemple apps/api-*/src/**. La valeur vide signifie tout emplacement.
• Classes de modifications. Les types de modifications auxquels s'applique le mandat, par exemple exception_fix.
• Accepter les tâches dont le résultat ne peut pas être mesuré. Désactivé par défaut. Lorsqu'il est désactivé, une demande dont contrat de résultat ne peut pas être mesuré attend en suspens au lieu de démarrer.

Budget. Le montant que Coroid peut consacrer au mandat lors de chaque période, en dollars américains et en heures d'agent, par semaine ou par mois. Une semaine commence le lundi à 00h00 UTC ; un mois commence le premier jour du mois. Le budget se réinitialise automatiquement.:00 UTC ; un mois commence le premier jour du mois. Le budget se réinitialise de lui-même.

Conditions d'arrêt. Arrêter lorsque le budget est épuisé, lorsque l'objectif est atteint, après un certain nombre de résultats non concluants consécutifs, ou à une date donnée.

Date de révision. Pour un mandat en cours : la date à laquelle une personne le renouvelle ou le retire.

Règle de dérive. Pour un mandat en cours : une limite pour la métrique de référence. Si cette limite est dépassée sur une période, une alerte doit être envoyée au responsable.

État et versions#

Un mandat débute en tant que brouillon. Publier le rend actif, et seuls les mandats actifs acceptent des tâches.

Modifier un mandat publié crée une nouvelle version. Les versions antérieures sont conservées avec l'identité de leur auteur et la date de publication.

Chaque publication et chaque modification d'état constitue une décision liée au mandat. Provenance, avec la personne qui l'a créée, ainsi qu'un événement dans le flux d'audit de votre organisation (mandate.created, mandate.published, mandate.paused etc.).

Les demandes régies par un mandat#

Un mandat régit les demandes qui arrivent sans qu'une personne soit identifiée dans Coroid : depuis l'entrée de travail API, depuis les automatisations et intégrations comme GitHub ou les tickets Jira, ainsi que depuis la surveillance.

Une demande formulée par une personne dans Nouveau travail, ou lors des importations, n'est pas soumise à un mandat. Elle est toujours admise si elle remplit les critères, jamais différée, et ne consomme pas le budget du mandat. Une personne l'a demandée ; les files d'attente d'agents la traitent simplement.

Une demande non attribuée est associée au mandat actif le plus ancien dont les projets incluent celui de la demande, ou au mandat couvrant tous les projets. Une demande non couverte par aucun mandat est admise comme une demande ordinaire.

Ce que décide l'admission#

L'admission est la dernière étape de La qualification. Elle ne fait aucun appel au modèle. Pour chaque demande, elle choisit l'une des options suivantes :

• Admise. Le travail est créé, avec une réservation pour une file d'attente d'agent et, dans le cadre d'un mandat, pour une partie du budget du mandat. Son démarrage autonome dépend de la source, comme décrit dans Quand le travail commence.
• Déjà résolu. Le même signal — le même incident dans votre outil de suivi ou de surveillance, ou la même panne — est déjà traité dans le cadre d'une autre demande dans tout projet de l'organisation. La demande est liée à ce travail, et rien de nouveau n'est créé.
• Aucune modification nécessaire. L'analyse de la qualification a révélé que le comportement signalé était prévu. Rien n'est créé.
• Différée. La demande est admissible mais ne doit pas démarrer immédiatement : la part de files d'attente d'agents du mandat est déjà utilisée, son budget pour la période concernée est épuisé, ou son résultat ne peut pas être mesuré et le mandat ne l'autorise pas.

Chaque décision et sa raison sont enregistrées avec la demande.

Demandes différées#

Coroid examine à nouveau les demandes différées chaque minute et les acceptent dès qu'un créneau ou un budget est disponible, selon la version actuelle du mandat. Augmenter le budget du mandat ou mettre en pause un autre mandat occupant des créneaux libère une demande différée lors du prochain contrôle. Aucune option ne permet de démarrer une demande différée directement.

Une demande ayant attendu plus longtemps que la durée prévue par son mandat — une semaine ou un mois — ou dont le mandat n'est plus actif, se termine sans être traitée.

Comment le travail lié aux mandats partage la capacité#

Le travail lié aux mandats peut occuper au maximum la moitié de la capacité de votre organisation. créneaux d'agents en même temps, y compris le travail en cours et le travail accepté mais pas encore démarré. Le reste reste libre pour les demandes des utilisateurs. Si votre abonnement propose un nombre illimité de créneaux, cette même proportion s'applique à votre budget mensuel de dépenses.

Une demande acceptée conserve sa réservation pendant 30 minutes le temps que sa tâche démarre. Après ce délai, la réservation expire : une demande dont la tâche n'a pas encore été créée retourne en état différé, et une tâche existante attend un créneau comme toute autre tâche.

Dans une exportation de paramètres#

Les mandats sont inclus dans une exportation de paramètres: type, objectif, cible, priorités, périmètre, budget, conditions d'arrêt, date de révision et règle de dérive. Les projets sont identifiés grâce à leur clé stable, et les propriétaires selon leur rôle. Les lignes de base ne sont jamais exportées ; il s'agit de mesures issues de l'organisation d'origine. Un mandat présentant un nouvel objectif arrive sous forme de brouillon à publier par un utilisateur. Un mandat dont l'objectif correspond à un mandat existant le met à jour : en tant que brouillon s'il est encore en cours, sinon en tant que nouvelle version publiée.

Lié#

• Contrats de résultats
• Ce que décide Coroid et ce qui reste sous votre contrôle
• Capacité et créneaux d'agents
• Nouveau travail et qualification
• Provenance