Votre environnement dev Outscale est plus gros que vous ne pensez

Vous pensez que votre environnement dev coûte 1 500 €/mois. Vous vous trompez probablement de moitié.

Les environnements dev, c'est là que les factures Outscale se cachent. La production a des métriques, des dashboards, et des rotations d'astreinte. La production est regardée. Le dev est utilisé 8 heures par jour par des humains et ignoré les 16 autres. Il est aussi utilisé par chaque "j'essaye un truc" qui n'a pas été nettoyé, chaque cluster staging qui aurait dû être une seule instance, chaque snapshot d'un projet qui s'est terminé il y a six mois.

Pourquoi le dev grossit en silence

Les raisons structurelles sont prévisibles :

• Personne ne possède le dev. La prod a des SRE. Le dev a celui qui l'a monté, qui est parti, et maintenant personne.
• Coût ≠ douleur. Le downtime prod, on le sent tout de suite. Le coût dev, on le sent en fin de mois, par quelqu'un de la finance, qui email quelqu'un de l'ingénierie.
• Pas d'incitation au nettoyage. Provisionner, c'est une récompense en 5 minutes (la chose marche). Décommissionner, c'est une corvée de 30 minutes sans bénéfice observable.
• Les défauts sont agressifs. La taille de volume par défaut, c'est 100 Gio. Le planning par défaut, c'est 24/7. La rétention de snapshot par défaut, c'est pour toujours. Aucun de ces défauts ne correspond à ce dont le dev a vraiment besoin.

Les quatre causes de coût

Pour la plupart des environnements dev, 90 % du coût vit dans quatre seaux :

1. Compute qui tourne quand personne ne travaille. Une VM dev qui tourne 24/7 sur un planning typique lun-ven 8h-18h gaspille 70 % de ses heures de calcul. Sur 20 VM, ce n'est pas "à optimiser un jour" — c'est le plus gros poste que vous verrez quand vous taguerez vos ressources dev et regarderez.

2. Compute surdimensionné pour le workload. La VM a été dimensionnée pour le jour où quelqu'un a fait un load test. Elle est à 5 % de CPU depuis. La planification coupe le temps, le redimensionnement coupe le taux. Les deux se cumulent.

3. Volumes orphelins. Des volumes qui étaient attachés à des instances terminées mais le volume n'a pas été supprimé. Ils continuent à être facturés au plein tarif Gio-mois, sans rien faire. Facile à énumérer via l'API ; rarement énuméré en pratique.

4. Accumulation de snapshots. Chaque snapshot est petit. Quelques centaines de snapshots ne le sont pas. La rétention de snapshot, c'est le désastre canonique du "configure et oublie" — ça marche bien jusqu'à ce que vous regardiez la facture et trouviez six mois de backups hebdo pour un environnement qui n'existe plus depuis trois.

Comment les trouver vraiment

Trois outils, dans l'ordre :

Les tags. Si vos ressources dev sont taguées (environment=dev, team=...), vous pouvez filtrer Cost Explorer par tag et voir la sous-facture dev. Si elles ne sont pas taguées, c'est le travail numéro zéro — on ne peut pas gérer ce qu'on ne peut pas mesurer. Appliquez les tags via l'API en 30 minutes ; l'analyse de coût devient possible immédiatement.

Cost Explorer avec granularité quotidienne. Regardez le coût dev sur les 30 derniers jours, par jour. Vous voyez des creux le week-end ? Vous devriez. Si la ligne est plate les samedis et dimanches, votre environnement tourne 24/7. Voilà votre cible de planification.

Inventaire de ressources croisé avec l'état runtime. Tirez tous les volumes BSU du compte, filtrez ceux qui n'ont pas d'instance attachée. Tirez tous les snapshots, filtrez ceux qui ont plus de 90 jours. C'est deux appels API. La liste, c'est votre file de nettoyage.

La règle des 50 heures

Une semaine de travail normale, c'est 50 heures d'activité (8h-18h × 5 jours). Un environnement dev normal tourne 168 heures. C'est un écart de 70 %, chaque semaine, chaque mois, pour toujours — jusqu'à ce que vous lui mettiez un planning.

Le calcul est simple. L'objection n'est pas le calcul, c'est "et si quelqu'un en a besoin un samedi". La vraie réponse : presque jamais, et quand c'est le cas, ils peuvent démarrer l'environnement via un bouton en 30 secondes. Le coût du "toujours disponible" se paye toutes les semaines. Le coût du "démarrer manuellement quand on en a besoin" se paye peut-être une fois par trimestre.

Une habitude hebdomadaire

La façon la plus simple de garder les coûts dev sous contrôle, c'est de les regarder toutes les semaines. 5 minutes, tous les lundis. Qu'est-ce qui tourne ? Qu'est-ce qui grossit ? Qu'est-ce qui est encore là depuis le trimestre dernier ?

La plupart des équipes le font tous les mois parce que c'est quand la facture arrive. À ce moment-là, c'est déjà un mois de gaspillage. Toutes les semaines, ça attrape les problèmes quand ils font un quart de la taille.

Si vous avez Vextnd connecté à votre compte, les coûts dev se trouvent dans Cost Explorer avec les filtres pertinents enregistrés. Cinq minutes par semaine — et les économies se cumulent comme le gaspillage le faisait avant.