2026 Egress sur CI Mac distant : gros artefacts, snapshots, limitation

Fuites d’egress fréquentes

1. Couches énormes re-tirées – octets × builds.
2. Snapshots / dossiers magiques – uplink saturé hors pipeline.
3. Bidouilles nocturnes dupliquées sans découpage.
4. Résolveurs bavards sur long RTT.
5. Mauvaise ligne analytique – fournisseur, artefacts, replication confondus.

Lorsque Proximity couvre déjà bien le RTT mais Finance seule dérape, commencez par ce playbook.

Qui porte le chiffre en staff ? « Bande montante brute du host » côté plateforme et « l’archive est lente » côté CI sont deux registres différents. Décomposez chaque build en lignes auditables (pull Git, registry, backfill objet, synchro multi-région) avec source SNMP/vendor/Ingress, fenêtre, RACI-A.

Les mêmes URL peuvent emprunter des routes de facturation différentes (CDN anonyme vs préfixe Bearer) ; des CLI « identiques » génèrent alors des doubles egress.

Matrice

Tant que des cellules sont à compléter, aucun passage des garde-fous en OKR. Complétez les preuves RTT de Proximity sans les remplacer.

À chaque ligne attachez une phrase d’acceptation mergée : « Replica RO région ouest ; canari une semaine docker pull −40 % octets cross-région ; rollback manifeste documenté. » Sinon Finance lit une liste de vœux.

Ne fusionnez pas latence réseau (ms) et volume egress (facturable) sur un seul axe : la première vit dans Proximity, la deuxième dans le grand livre. Deux colonnes évitent la question « latence ou cash ? ».

Six étapes de livre de bord

1. Trois codes comptables.
2. Échantillonner octets pic vs jour.
3. Re-brancher les arêtes lourdes (guide).
4. Locations courtes = pré-chauffe.
5. Sync nocturne avec arrêt throughput.
6. Contrôle semaine quatre.

Les étapes 2 et 6 meurent en réunion : un hot spot CD heureux sur une machine de test n’est pas une vérité ; rejouer seulement la semaine 1 ignore les fenêtres de maintenance. Exigez le même script que les panneaux Grafana et deux captures identiques pour la revue.

Les nœuds burst du guide multi-région qui retéléchargent toute la pile la première heure manquent presque toujours de pré-chauffe — enregistrez un egress duplicable, pas « l’amont est lent ».

#!/usr/bin/env bash
IFACE="${IFACE:-en0}"
read_b () { netstat -ib | awk -v nic="$IFACE" '$1==nic {print $(NF)}'}
B0=$(read_b); sleep "${BUILD_PAUSE_SEC:-900}"; B1=$(read_b)
echo "delta_bytes~$(($B1-$B0))"

Faits réutilisables

• Graphes bavards : journaliser % HTTP ≠200 et taux de retry par build de référence, pas seulement RTT moyen.
• Faux manques de cache : digests divergents avec journaux « CDN hit » → préfixe Bearer ignoré par un curl naïf.
• Collision snapshot / pic release : sur un même uplink, fixer par ticket qui préempte quoi (QoS ou pause explicite).

Chaque point doit être exportable vers Jira. Traiter un volume WORM comme dossier chaud génère des pics hors pipeline. Documentez NFS/SMB dans le wiki.

Alternatives naïves

Limiter la bande passante sans topologie incite les retry ; la durée moyenne de build × PR parallèles refait monter le TCO.

Chat et stockage perso brisent la chaîne de possession ; les VM partagées sans index d’artefacts re-téléchargent les mêmes URL.

MACCOME Cloud Mac relie pics, budgets et audits dans un même contrat multi-région (jours à trimestre) avec traçabilité ticket↔octets :

D’abord le livre, ensuite le tableau de bord

Quatre champs minimum — tenant / fenêtre / domaine de facturation / octets ou unité — doivent alimenter le même schéma que le calendrier des releases.

Les courbes d’économies doivent provenir des mêmes sondes que les scripts de remédiation, sinon la semaine quatre oppose Excel à l’observabilité.