Contrôle des versions des configurations

1) Pourquoi convertir les configurations

La configuration est une stratégie exécutable : elle définit le routage, les limites, les drapeaux fich, les accès, les schémas de données. Le contrôle des versions rend les modifications répétables, prévisibles et réversibles : réduit le taux de MTTR et de changement, élimine la « magie dans la vente », donne un audit pour la sécurité et la conformité.

2) Taxonomie des configurations

Infrastructure (IaC) : clusters, réseaux, LB, OBD, files d'attente.
Service : paramètres d'application, ressources, limites, délais, retraits.
Logique produit/entreprise : tarifs, expériences AB, règles de contenu.
Données/DataOps : contrats de schémas, SLA de fraîcheur, transformation.
Sécurité : politiques d'accès, rôles, clés/certificats (les secrets eux-mêmes sont hors du repaire).
Observabilité : SLI/SLO, alertes, dashboards.

La règle : tout ce qui affecte le comportement du système est la configuration et doit vivre sous le versioning.

3) Principes de gestion de version

1. GitOps : la seule source de vérité est le référentiel ; changements via PR et piplines automatiques.
2. Déclaration : description de l'état cible, pas des scripts d'étapes.
3. L'immutabilité des artefacts : config → un snapshot définitivement matérialisable.
4. Schémas et validation : JSON/YAML-schema, mise en forme stricte des types, champs obligatoires.
5. Les environnements en tant que code : « bou » sont des dossiers/overleys (dev/stage/prod), les différences sont minimes et explicites.
6. Idempotence et reculs : toute version de la configuration est réversible (revert/rollback).
7. Audit et traçabilité : auteur, cause, tiquet/RFC, signatures de changement.

4) Stratégies de versioning

• MAJOR - Modifications incompatibles des schémas/politiques.
• MINEUR - nouveaux champs/règles, rétrocompatibilité.
• PATCH : Corrections des valeurs sans modifier les schémas.
• Tag-release et release notes : ce qui a changé, comment reculer, points de contrôle.
• Pinning/lock-files : nous enregistrons les versions des dépendances (modules, charts).
• Versions matricielles : l'artefact de l'application X est compatible avec le config Y (matrice dans le catalogue du service).

5) Organisation du référentiel

config-repo/
policies/     # общие политики (RBAC, SLO, алерты)
services/
checkout/
schema/    # JSON/YAML схемы конфигов base/     # дефолтные значения overlays/
dev/
stage/
prod/
data-contracts/  # схемы данных, SLA свежести releases/     # теги, changelog, артефакты валидации tools/      # линтеры, генераторы, тесты

Branche : trunk-based (main) + branches de fonction courtes. Merge - seulement via PR avec CI obligatoire.

6) Validation et test

Schéma : chaque modification passe par la vérification du schéma (required, enum, ranges).
Linters statiques : format, clés, prises, champs interdits.
Tests de compatibilité : flig + version service/chart monte dans le bac à sable.
Processions de contrôle : dry-run applications, « what-if » diff de l'état cible.
Politiques-as-code : Règles d'admission (Rego/CEL) - qui et ce qui peut changer.

7) Inversion et inversion des configurations

Livraison progressive : Canaris à 1%→5%→25 % avec les gardes SLO.
Gate deploy : pas de SEV-1 actifs, les alertes sont vertes, les signatures sont valides, le retour est prêt.
Retour en arrière : 'revert tag vX. Y.Z 'ou basculement vers le snapshot précédent ; les commandes de retour sont documentées dans le runbook.
Annotations de sortie : la version de flig est publiée en métriques/logs pour être rapidement corrélée aux incidents.

8) Configuration dynamique et distante

Remote bou/feature flags : nous modifions les paramètres sans restarts ; tous les drapeaux sont aussi sous GitOps.
Bordures : les paramètres que vous pouvez modifier dynamiquement (liste des listes blanches).
Cache et consistance : TTL, versions, remplacement atomique des ensembles (publication en deux phases).
Garde-corps sécurisés : limites et gammes pour les changements de runtime, auto-rollback lorsque vous quittez SLO.

9) Secrets et données sensibles

Nous ne gardons jamais de secrets dans le repo. Dans les configurations, seulement les liens/playholders.
Cryptage des fichiers de configues si nécessaire : intégration avec le gestionnaire de secrets/clés.
Rotation et JIT : accès émis pendant la durée des opérations ; la trace de l'action est immuable.
Camouflage de terrain : la validation interdit aux PII/secrets d'entrer dans le config.

10) Gestion de l'environnement

Base + overlays : les différences entre dev/stage/prod sont minimes et transparentes.
Promotion sur les artefacts : le même snapshot qui a passé le stage avance en prod.
Fenêtres temporelles : les changements de configues ne se produisent pas au moment du changement de garde ; pour risk-high - RFC et fenêtre de service.

11) Détection et élimination de la dérive

Le contrôleur compare l'état cible à l'état réel et signale le diff.
Drift-alerts : Page uniquement pour les écarts critiques ; les autres sont Ticket.
Auto-remediation : lors de la résolution - retour à l'état cible.
Vérification des modifications manuelles : tout « kubectl edit/ssh » → incident de processus et CAPA.

12) Catalogue des configurations et propriété

Annuaire de service : propriétaire, SLO, politiques associées, schémas, versions, interopérabilité.
RACI : qui propose, qui revoit, qui approuve ; Le BOU pour les risques élevés.
Transparence : chaque entrée a un historique des versions et des liens vers PR/tickets/AAR.

13) Métriques de maturité

Coverage :% des services/politiques sous GitOps (objectif ≥ 95 %).
Lead time config-change : médiane de PR à prod.
Change failure rate : proportion de versions config avec retour en arrière/incident.
Taux de drift : nombre d'écarts/semaine et temps d'élimination.
Rollback time : récupération médiane à la version précédente.
Audit complet : proportion de changements avec evidence complète (validateurs, dry-run, commentaires).

14) Chèques-feuilles

Avant de modifier la configuration

• Il y a un tiquet/RFC et le propriétaire du changement.
• La validation des schémas et des linters est passée.
• Il y a un plan de retour et des commandes dans le runbook.
• Gate : les tests sont verts, les signatures sont valides, il n'y a pas de SEV-1 actifs.
• Pour les risques élevés - une fenêtre de service est assignée.

Pendant le tri

• Les canaris et les gardes SLO sont actifs.
• Les annotations de version sont publiées.
• Il y a des messages d'écho dans le canal ; le bruit d'alert est supprimé selon les règles de MW.

Après

• Fenêtre d'observation passée, SLO vert.
• Les résultats et evidence (graphiques avant/après, dry-run reports) sont joints au ticket.
• Les schémas/documents ont été mis à jour si nécessaire.

15) Mini-modèles

15. 1 Schéma de configuration (YAML-schema, fragment)

yaml type: object required: [service, timeouts, retries]
properties:
service: { type: string, pattern: "^[a-z0-9-]+$" }
timeouts:
type: object properties:
connect_ms: { type: integer, minimum: 50, maximum: 5000 }
request_ms: { type: integer, minimum: 100, maximum: 20000 }
retries:
type: object properties:
attempts: { type: integer, minimum: 0, maximum: 10 }
backoff_ms: { type: integer, minimum: 0, maximum: 5000 }

15. 2 Flig de base + overle prod

yaml services/checkout/base/config.yaml service: checkout timeouts: { connect_ms: 200, request_ms: 1500 }
retries: { attempts: 2, backoff_ms: 200 }
limits:  { rps: 500 }
features:
degrade_search: false psp_a_weight: 80 psp_b_weight: 20

yaml services/checkout/overlays/prod/config.yaml limits:  { rps: 1200 }
features:
psp_a_weight: 70 psp_b_weight: 30

15. 3 Politique d'admission (idée)

yaml allow_change_when:
tests: passed schema_validation: passed active_incidents: none_of [SEV-0, SEV-1]
rollback_plan: present signed_by: ["owner:team-checkout","platform-sre"]

15. 4 Carte de sortie de flig

Release: checkout-config v2.3.1
Scope: prod EU
Changes: psp_b_weight 20→30, request_ms 1500→1300
Risk: Medium (маршрутизация платежей)
Canary: 1%→5%→25% (30/30/30 мин), guardrails: success_ratio, p95
Rollback: tag v2.3.0

16) Anti-modèles

Les modifications dans la vente sont passées par GitOps (« rapide »).
Secrets/PII dans le référentiel de configues.
Absence de schémas et de contrôles statiques.
Forte divergence des environnements (base≠prod).
Drapeaux « vivants » sans version ni histoire.
Ignorer la dérive et les modifications manuelles sur les serveurs.
Balises sans release notes et plan de retour.

17) Feuille de route pour la mise en œuvre (4-6 semaines)

1. Ned. 1 : inventaire des configues ; catalogues séparés, schémas pour les 10 meilleurs services.
2. Ned. 2 : inclure les linters/validation et dry-run dans l'IC ; interdiction de la merge sans chèques verts.
3. Ned. 3 : GitOps scalé + canaris ; annotations de version en télémétrie.
4. Ned. 4 : entrée de la politique d'admission (policy-as-code) et des modèles rollback ; alertes à la dérive.
5. Ned. 5-6 : couvrir 90 % des services ; réduire les différences entre les deux ; ajouter des métriques de maturité et une revue hebdomadaire des modifications config.

18) Résultat

Le contrôle des versions des configurations est un système, pas simplement un Git. Les schémas et la validation, les GitOps et les politiques d'accès, les canaris et les retraits, la détection des dérives et l'audit complet transforment les flig en artefact géré. Le résultat est un changement rapide et sûr, la prévisibilité de SLO et la confiance de l'équipe dans chaque version.