Pilier Operational Excellence sur OUTSCALE

Le pilier Operational Excellence couvre la conduite quotidienne d’une infrastructure cloud : tagging, runbooks, observabilité, gestion du changement par IaC, métriques DORA, post-mortems. Sur OUTSCALE, il s’appuie principalement sur OMS pour le traçage des appels API (équivalent CloudTrail), sur la discipline IaC (Terraform, Packer, Ansible) comme mécanisme de changement contrôlé, et sur une stack d’observabilité Prometheus/Grafana ou OpenTelemetry pour les métriques applicatives. Cette page formule les questions clés à poser sur une infrastructure OUTSCALE, propose une checklist actionnable, deux ADR types et les points d’audit correspondants.

Le pilier en deux phrases

Operational Excellence évalue la capacité d’une organisation à opérer son infrastructure de manière reproductible et observable, à gérer le changement sans incident majeur, et à apprendre de ses incidents. Sur OUTSCALE, il se matérialise par un plan de tagging unifié, un pipeline IaC comme seule porte d’entrée des changements, un traçage des appels API via OMS, et une boucle de feedback alimentée par les métriques DORA.

Les questions clés

Une architecture qui revendique une posture Operational Excellence doit pouvoir répondre aux questions suivantes :

Tagging — chaque ressource OUTSCALE porte-t-elle des tags env, project, owner, cost-center, compliance cohérents et obligatoires sur tous les environnements ?
IaC comme porte d’entrée — toute modification de production passe-t-elle par un commit Git (Terraform/Ansible) ? Existe-t-il une break-glass procedure documentée pour les exceptions ?
Reproductibilité des OMI — les images sont-elles construites par Packer + Ansible avec un Pipefile versionné, ou bricolées à la main ?
Traçage des appels API — l’équipe interroge-t-elle régulièrement OMS (ReadApiLogs) ? Un collecteur archive-t-il les logs vers OOS pour une rétention longue alignée sur la conformité ?
Observabilité applicative — existe-t-il une stack métriques/logs/traces (Prometheus, Grafana, Loki, OpenTelemetry) déployée sur les workloads ? Les alertes sont-elles routées vers une astreinte ?
Métriques DORA — l’équipe mesure-t-elle son deployment frequency, lead time for changes, change failure rate, mean time to recovery ? Sait-elle où elle se situe sur l’échelle Low/Medium/High/Elite ?
Runbooks — pour chaque incident-type connu (perte d’EIP, saturation BSU, expiration de certificat), existe-t-il un runbook versionné et testé ?
Post-mortems — les incidents production donnent-ils lieu à un post-mortem sans blâme documenté, avec actions correctives suivies ?

Une équipe qui répond « non » ou « partiellement » à plus de trois de ces questions est en posture fragile sur Operational Excellence — un incident significatif est probable dans les six prochains mois.

Application sur OUTSCALE

Tagging unifié

Le plan de tagging est le socle. Sur OUTSCALE, les tags se posent à la création des ressources via Terraform (tags = { ... } sur chaque ressource Outscale) et se vérifient via OAPI ReadTags ou directement sur la ressource. Cinq tags structurants suffisent pour la plupart des organisations :

env — dev, staging, prod. Permet le routage des alertes, le filtrage des coûts, la séparation des politiques de sauvegarde.
project — code projet ou produit interne (ex. marketing-site, data-pipeline). Référence unique non ambiguë.
owner — équipe ou personne responsable. Permet de retrouver un interlocuteur sur une ressource orpheline.
cost-center — code analytique pour la refacturation interne. Indispensable dès qu’une organisation veut ventiler les coûts cloud par BU.
compliance — secnumcloud, rgpd, hds, none. Sert de filtre pour les contrôles de conformité.

L’absence d’un de ces tags doit déclencher une alerte ou un rejet dans le pipeline IaC. Sans cette discipline, une ressource créée à la main par un développeur en debug se retrouve six mois plus tard sans propriétaire identifiable et sans imputation de coût.

IaC comme porte d’entrée

La règle non négociable : aucune modification de la production OUTSCALE ne se fait via le Cockpit ou via un appel CLI direct. Tout changement passe par un commit Git, une revue de PR, et l’exécution d’un pipeline Terraform sur un runner CI dédié. Le backend d’état Terraform est centralisé sur OOS avec verrou natif (lock via DynamoDB-compatible ou via un lock applicatif simple), pour éviter les exécutions concurrentes.

La break-glass procedure documente les rares cas où une intervention directe est autorisée (incident majeur, indisponibilité du pipeline). Elle prévoit un enregistrement systématique dans un canal dédié et un commit de réconciliation Terraform dans les 24 heures suivantes.

Traçage OMS

OMS (OUTSCALE Monitoring Service) est le service d’audit des appels API OUTSCALE. Il enregistre qui (utilisateur EIM ou rôle), quand, quelle action (CreateVm, DeleteVolume, UpdateAccessKey, etc.), sur quelle ressource et avec quel résultat. L’API associée est ReadApiLogs.

Point de vigilance : la documentation de ReadApiLogs précise que les logs sont accessibles pour les 32 derniers jours via l’API. Pour une rétention longue (12 mois RGPD, 36 mois SecNumCloud, plus selon le secteur), il faut un collecteur côté client qui interroge régulièrement l’API et archive les enregistrements sur un bucket OOS dédié dans un compte d’audit séparé.

Observabilité applicative

OUTSCALE n’expose pas de service managé d’observabilité applicative équivalent à CloudWatch. La pratique standard consiste à déployer une stack Prometheus/Grafana/Loki sur le cluster OKS, ou un OpenTelemetry collector routant vers la plateforme de votre choix (Grafana Cloud, Datadog, Dynatrace).

Les trois piliers restent : métriques (Prometheus), logs (Loki ou ELK), traces (Jaeger ou Tempo via OTel). Pour une mise en production, viser le triplet dashboard utilisateur (taux d’erreur, latence p95), alertes routées astreinte (Alertmanager → PagerDuty/Opsgenie), rétention longue (90 jours minimum sur les logs, 13 mois sur les métriques pour comparer trimestre à trimestre).

Métriques DORA

Les quatre métriques DORA de l’équipe DevOps Research and Assessment fournissent le tableau de bord le plus utilisé pour mesurer la performance d’une équipe livraison :

Deployment Frequency — combien de fois par jour/semaine/mois le code part en production ?
Lead Time for Changes — combien de temps entre un commit et sa mise en production ?
Change Failure Rate — quel pourcentage de déploiements provoque un incident ?
Mean Time to Recovery (MTTR) — quel temps moyen pour rétablir le service après un incident ?

Sur OUTSCALE, ces métriques se collectent via les GitLab/GitHub APIs côté CI/CD, croisées avec les incidents déclarés dans l’outil d’astreinte. Pas de magie : un dashboard Grafana avec quatre tuiles suffit pour démarrer. Le seuil Elite (DORA 2023) demande un déploiement plusieurs fois par jour, lead time inférieur à une heure, change failure rate inférieur à 15 %, MTTR inférieur à une heure.

Checklist Definition of Done

Cette checklist doit être validée pour qu’un environnement de production OUTSCALE soit considéré comme conforme Operational Excellence. Chaque item est vérifiable.

Une organisation qui valide moins de 70 % de ces items présente un risque opérationnel élevé.

ADR types

ADR-OE-01 — Politique de tagging unifiée

Contexte : l’organisation crée des ressources OUTSCALE sans discipline de tagging. La répartition des coûts par projet est impossible, les ressources orphelines s’accumulent.

Décision : adopter cinq tags obligatoires (env, project, owner, cost-center, compliance) sur toutes les ressources créées. Implémenter un contrôle bloquant dans le pipeline Terraform (rejet de tout terraform apply si un tag est manquant).

Conséquences : surcharge initiale de migration des ressources existantes (1 à 2 sprints sur un parc moyen). Bénéfices durables : refacturation possible, audit de propriété immédiat, filtrage facile pour les politiques de sauvegarde et de conformité.

ADR-OE-02 — Centralisation du backend Terraform sur OOS

Contexte : l’équipe utilise des backends Terraform locaux ou disséminés sur des volumes partagés. Les exécutions concurrentes provoquent régulièrement des corruptions d’état.

Décision : centraliser le backend d’état Terraform sur un bucket OOS dédié, dans un compte d’audit séparé. Activer le versioning sur le bucket. Restreindre l’accès via une politique EIM à un seul rôle d’administration IaC.

Conséquences : simplification de la collaboration, élimination des risques de corruption d’état, traçabilité complète des modifications via l’historique des versions OOS. Coût : la mise en place d’un compte d’audit séparé demande quelques heures de travail initial.

Points d’audit correspondants

Sur un compte OUTSCALE réel, ces contrôles peuvent être menés via oapi-cli ou via un outil d’audit automatisé. Les commandes ci-dessous illustrent l’approche.

oapi-cli ReadTags

Vérifier que toutes les ressources retournées portent les cinq tags obligatoires. Le filtrage par absence de tag se fait côté shell (jq sur la sortie JSON).

oapi-cli ReadAccessKeys

Lister les access keys et vérifier leur âge. Les access keys de plus de 90 jours doivent être rotées (ou justifiées dans un ADR).

oapi-cli ReadVms --Filters.VmStateNames[] running

Pour chaque VM en cours, vérifier qu’elle est référencée dans le code Terraform de l’environnement correspondant. Une VM en running non Terraform-managée est un signal d’alerte immédiat.

L’audit complet est traité dans une page dédiée du Volet 5, à venir.

Antipatterns à éviter

Cockpit en production. Provisionner des ressources de production via le Cockpit graphique. Le geste paraît anodin mais déconnecte l’environnement de son code Terraform — la prochaine terraform apply détecte une dérive et propose de la corriger en supprimant la ressource créée à la main, ce qui est rarement souhaité.

Tags optionnels. Définir un plan de tagging mais ne pas le contrôler en CI. Six mois plus tard, 30 à 50 % des ressources créées entre-temps ne respectent pas le plan. Le contrôle a posteriori est un travail manuel chronophage.

Pas de collecteur d’archivage OMS. Se contenter des 32 jours de rétention API par défaut. En cas d’investigation tardive sur un incident remontant à plusieurs mois, l’absence d’archive long terme rend l’analyse impossible.

Observabilité greffée sur production. Déployer une stack Prometheus/Grafana en production sans la déployer en staging. Quand une alerte critique se déclenche, l’équipe découvre que l’instrumentation n’a pas été testée à l’échelle.

Post-mortems blâmants. Pratiquer des post-mortems qui désignent un coupable. La conséquence est que personne ne déclare plus jamais d’incident, ce qui réduit artificiellement le change failure rate observé sans réduire les incidents réels.

À retenir

Tagging unifié sur cinq dimensions (env, project, owner, cost-center, compliance) — contrôlé en CI, non négociable.
IaC unique porte d’entrée des changements production — Terraform + Packer + Ansible, backend d’état OOS centralisé.
OMS exploité via ReadApiLogs (rétention API 32 jours) ; collecteur d’archivage OOS pour la rétention longue.
Stack observabilité Prometheus/Grafana/Loki ou OpenTelemetry — alertes routées astreinte, rétention 90 jours logs / 13 mois métriques.
Métriques DORA mesurées et publiées — quatre tuiles Grafana suffisent pour démarrer.
Runbooks versionnés, post-mortems sans blâme, break-glass documentée et testée annuellement.

Prochaines étapes

Volet 5 — Vue d'ensemble Le sommaire des 7 piliers Well-Architected appliqués à OUTSCALE.

Le Well-Architected adapté à OUTSCALE — introduction Le pourquoi du framework et le détail des 7 piliers.

Volet 3 — Industrialiser (IaC) La discipline Terraform/Packer/Ansible qui sert ce pilier.

EIM — patterns multi-comptes La séparation des comptes audit / production qui sert OMS.