Soixante conteneurs sur un seul serveur
Une machine bare-metal exécute des dizaines à des centaines de conteneurs Hoody. La dédupplication KSM et BTRFS rend le coût marginal quasi nul.
Containers·Snapshots
TypeStandardÉtapeGain rapideDifficultéSimpleTravailAutomatiser une tâchePourÉquipes de devPourDevOps & infraServicesCronPourquoi HoodyHTTP-natif
TypeStandardÉtapeGain rapideDifficultéSimpleTravailAutomatiser une tâchePourÉquipes de devPourDevOps & infraServicesCronPourquoi HoodyHTTP-natif
use-cases / mute-flaky-job / hero
CRON · MANAGED ENTRIES · PATCH
Mettez en sourdine la tâche instable sans la perdre
L'export horaire des métriques échoue depuis trois jours. Vous êtes d'astreinte ce soir. Faites un PATCH sur l'entrée cron managée avec enabled:false — la planification, la commande, le commentaire restent tous en place. La tâche est dans un état défini : présente et muette, en attendant que quelqu'un la corrige.
cron.containers.hoody.com · entries
https://cron.containers.hoody.com/users/me/entrieslive
actifidplanificationcommandestatut
- a1f2*/5 * * * *curl -fsS http://prod/healthactivée
- c4b90 3 * * */usr/local/bin/backup.shactivée
- e7d30 * * * */srv/cron/metrics-export.shmuette · il y a 2j · @alexmuette depuis 2d ago · par @alex“flaking on monday with prod-db — see #pager-fri”
- 9b21@hourlypsql -c 'VACUUM ANALYZE'activée
- f0a80 9 * * 1-5/srv/cron/digest.shactivée
- d3c7*/15 * * * */srv/cron/reindex-search.shpatch en cours…
PATCH/users/me/entries/d3c7corps de la requête
{ "enabled": false, "comment": "reindex flaking — see thread" }
le bouton n'est qu'un PATCH · l'entrée ne quitte jamais la liste
use-cases / mute-flaky-job / mechanism
Mettre en sourdine, c'est un seul PATCH
Les entrées managées de Hoody Cron sont une ressource JSON : chaque ligne possède un id, une planification, une commande, un commentaire et un drapeau enabled. Faire passer enabled à false, c'est un seul PATCH. L'entrée reste dans la crontab pour que la personne suivante puisse la lire et décider quoi faire.
terminal · ordinateur d'astreinte
PATCH · mute# mute the flaky entry — entry stays in the crontab curl -X PATCH \ https://cron.containers.hoody.com/users/me/entries/e7d3 \ -H "Content-Type: application/json" \ -d '["enabled": false, "comment": "flaking on monday with prod-db — see #pager"]' # response HTTP/1.1 200 OK { "id":"e7d3", "enabled":false, "schedule":"0 * * * *", "command":"/srv/cron/metrics-export.sh", ... }
terminal · le lendemain matin
GET · vérification# the entry is still on the list — just not running curl GET https://cron.containers.hoody.com/users/me/entries HTTP/1.1 200 OK [ { "id":"a1f2", "enabled":true, ... }, { "id":"e7d3", "enabled":false, "comment":"flaking — see #pager" }, { "id":"9b21", "enabled":true, ... } ] # present and muted — the on-call hand-off has somewhere to point
Le PATCH ne supprime, ne réécrit, ni ne déplace l'entrée — il bascule un seul booléen. La passation tient en une ligne : « l'entrée metrics-export e7d3 est muette, voir hoody-cron, regardez s'il vous plaît. »
use-cases / mute-flaky-job / states
Trois états, une seule entrée
Une entrée dans une crontab Hoody est toujours dans exactement l'un des trois états. Chaque état a des conséquences différentes sur ce que l'équipe saura demain matin.
ENTRY · e7d3 · /srv/cron/metrics-export.shPATCH bascule entre les états — jamais destructeur
ENABLED
Tourne selon la planification, alerte en cas d'échec
L'entrée est dans la crontab et le démon cron du noyau la prend toutes les heures. Les échecs réveillent l'astreinte. C'est l'état par défaut pour les tâches saines.
MUTED
Présente, en pause, annotée
enabled:false. L'entrée est toujours dans la crontab, l'équipe peut donc lire sa planification, sa commande et son commentaire. Le démon cron la saute. Pas d'alerte à 2h du matin demain, personne n'oublie qu'elle existe.
DELETED
Disparue — et le contexte avec
Une fois que vous faites DELETE, la planification, la commande, le commentaire, la raison — tout quitte la crontab. Le prochain astreint n'a plus rien à grep. Mettre en sourdine est le choix qui préserve la mémoire.
Mute est l'état intermédiaire que la plupart des planificateurs n'ont pas nommé. Hoody Cron, si — parce que enabled est un champ de premier rang sur l'entrée managée.
use-cases / mute-flaky-job / powers
Pourquoi un état muet bien défini compte
Quand vous ne pouvez pas réparer une tâche ce soir, la question est : quelle forme prendra son absence demain. Le mute rend cette forme lisible.
PASSATION
Le message d'astreinte tient en une ligne
Au lieu de coller un fil Slack ou une PR avec une ligne supprimée, le message est l'id de l'entrée. L'astreinte du lendemain ouvre l'URL cron, lit le commentaire, et sait par où commencer.
AUDIT
Chaque mute est une ligne, pas un souvenir
GET /entries renvoie enabled:false avec le commentaire. Construisez un panneau d'audit en filtrant. Qui l'a mis en sourdine, pourquoi, et depuis combien de temps : tout est dans le JSON, pas dans les DM de quelqu'un.
RÉVERSIBLE
Réactiver, c'est le PATCH inverse
Une fois le problème de fond corrigé, un PATCH de plus avec enabled:true remet l'entrée sur la planification. Pas de réécriture de l'expression cron, pas de risque de coquille, pas de cycle commit-and-deploy.
use-cases / mute-flaky-job / capacity
Ce que l'API cron vous offre
Les chiffres viennent de la surface managed-entries de Hoody Cron, pas de benchmarks inventés.
- UNE SEULE MÉTHODEPATCH
PATCH /users/[user]/entries/[id] accepte un corps partiel. Envoyez ["enabled":false] seul — la planification, la commande et le commentaire ne sont pas touchés.
- CHAMPS PRÉSERVÉS5+1
La planification à cinq champs, la commande, le commentaire, expires_at et l'id persistent tous à travers la mise en sourdine. La crontab du noyau reflète encore l'entrée — simplement commentée par le service cron.
- RÉÉCRITURES0
Pas d'édition de fichier, pas de PR, pas de déploiement. L'aller-retour de mute est un seul appel HTTP depuis n'importe quel terminal, y compris celui de votre téléphone.
Selon l'API Managed Entries de Hoody Cron : chaque entrée porte un booléen enabled à côté de la planification, la commande, le commentaire et un éventuel expires_at. PATCH accepte des corps partiels.
use-cases / mute-flaky-job / punchline
Désactivée n'est pas supprimée — l'entrée attend que quelqu'un la corrige.
ce soir · d'astreinte · 23:14demain · l'équipe · 09:00
À QUOI RESSEMBLAIT L'ANCIEN FLUXvim crontab → commenter la ligne → commit → PR → merge → deploysix étapes · perd le contexte du commentaire · risque de coquille un soir fatigué
À QUOI ÇA RESSEMBLE MAINTENANTcurl -X PATCH .../entries/e7d3 -d '["enabled":false]'un seul PATCH · l'entrée reste dans la liste · la note voyage avec elle
use-cases / mute-flaky-job / replaces
Ce que cela remplace
Les manières habituelles dont les équipes « parquent temporairement » une ligne cron instable. Chacune est soit destructive, soit lossy, soit à deux PR de la production.
- commenter à la main les lignes de la crontabPerd le drapeau enabled structuré · facile à oublier
- supprimer l'entrée et « se souvenir »Planification, commande et raison s'en vont avec elle
- commentaires // FIXME manuels dans le codeVivent dans un dépôt, pas dans la planification qui tourne
- fils Slack en guise de mémoire d'astreinteCherchable pendant une semaine · puis ce n'est plus le travail de personne
- issues GitHub pour les tâches muettes-mais-non-suppriméesUne issue pour quelque chose qui est encore dans la crontab — état dupliqué
- configuration cron managée par TerraformPlan, apply, deploy — pour un seul champ booléen
use-cases / mute-flaky-job / cta
Arrêtez de supprimer les tâches instables à 2h du matin. Mettez-les en sourdine, laissez une note, et laissez l'astreinte de demain lire le JSON.
use-cases / mute-flaky-job / related
Découvrez les autres
