Azure App Configuration : diagnostiquer un feature flag avant rollback

Un incident de production causé par la configuration ressemble rarement à un incident de configuration au départ. Le déploiement est vert, l’image conteneur n’a pas changé, l’API répond encore, mais un parcours retourne 500, une nouvelle fonctionnalité devient visible au mauvais public, ou une dépendance est appelée avec un endpoint inattendu. Le réflexe consiste souvent à rollback l’application, désactiver le feature flag partout ou modifier une valeur directement dans le portail.

Le cas d’usage est une application Azure qui utilise Azure App Configuration pour ses feature flags et paramètres d’exécution. Elle peut tourner sur App Service, Azure Functions, Container Apps ou AKS. Certaines valeurs sont labelisées par environnement, région ou ring. Certains paramètres référencent des secrets Key Vault. Le but du runbook est de décider si la régression vient d’un flag, d’un label, d’un refresh trop lent, d’une identité, d’une référence Key Vault ou du déploiement applicatif lui-même.

Figer le périmètre de configuration

Commencez par nommer la surface exacte du changement. Un feature flag n’est pas seulement un booléen. Il peut avoir des labels, filtres, règles de ciblage, pourcentages de déploiement, fenêtres horaires, cache de refresh et chemins de code qui l’interprètent différemment.

Incident
Application: orders-api-prod
Environnement: production
Region ou ring: westeurope / ring-1
Symptome: retries checkout et erreurs de validation paiement
Cle ou flag suspect: FeatureManagement:UseNewPaymentAdapter
Label attendu: prod
Derniere valeur saine connue et horodatage
Version de deploiement et digest image
Store App Configuration et replica
References Key Vault impliquees

Questions avant changement
Quel label le runtime a-t-il lu ?
L'application a-t-elle rafraichi la nouvelle valeur ?
Le flag ciblait-il uniquement les bons utilisateurs ?
Une reference Key Vault a-t-elle echoue derriere le parametre ?
Le rollback doit-il porter sur le label, le flag ou la version applicative ?

Ce cadrage évite deux erreurs fréquentes : désactiver un flag globalement alors qu’un seul label est faux, ou rollback le code alors que la version déployée lit une configuration obsolète.

Lire les labels et valeurs effectives

La première preuve est l’état réel des clés, pas la valeur dont l’équipe se souvient. Exportez les clés utiles avec labels, ETags et dates de dernière modification. Si les labels servent à représenter les environnements ou rings de rollout, comparez-les côte à côte.

APP_CONFIG_NAME="appcfg-prod"
KEY_FILTER="FeatureManagement:*"

az appconfig kv list --name "$APP_CONFIG_NAME" --key "$KEY_FILTER" --label prod --fields key label value content_type last_modified etag --output table

az appconfig kv list --name "$APP_CONFIG_NAME" --key "$KEY_FILTER" --label ring-1 --fields key label value content_type last_modified etag --output table

az appconfig feature list --name "$APP_CONFIG_NAME" --label prod --output json

Gardez l’ETag et l’horodatage dans l’incident. Ils permettent de prouver qu’une valeur a changé pendant l’incident et de restaurer la valeur précédente sans deviner.

Vérifier l’identité et le chemin réseau

Quand une application lit App Configuration avec une managed identity, un 403, une valeur obsolète ou un fallback local peuvent ressembler à un bug applicatif. Prouvez l’identité et le chemin utilisés par le workload avant d’éditer les flags.

Acces runtime
Managed identity attachee au workload
Role App Configuration Data Reader ou role attendu
Acces Key Vault pour chaque secret reference
Chemin reseau prive ou public documente
DNS et sortie valides depuis le runtime, pas depuis le poste admin

Signaux de panne
L'application lit une valeur par defaut car App Configuration est inaccessible
Une reference Key Vault echoue et l'application bascule en fallback
Le mauvais label est charge apres changement de slot ou de ring
Une valeur cachee reste active apres toggle d'urgence
Une connection string est encore utilisee par un composant

Un Private Endpoint peut faire partie du design, mais ce n’est qu’un contrôle. Un chemin privé correct ne prouve pas que le workload possède les bons droits App Configuration ou Key Vault.

Corréler les flags avec les symptômes

La décision doit s’appuyer sur une timeline. Corrélez les changements de configuration, erreurs applicatives, appels aux dépendances et dimensions de requête qui correspondent à la règle de ciblage du flag.

let Window = 4h;
let FlagName = "UseNewPaymentAdapter";
let SuspectedPath = "/checkout";
AppConfigurationChangeEvents
| where TimeGenerated > ago(Window)
| where Key has FlagName
| project TimeGenerated, Key, Label, OldValue, NewValue, ETag, Actor, CorrelationId
| order by TimeGenerated desc

Utilisez la télémétrie applicative pour voir si le symptôme suit le flag, la version ou l’environnement.

let Window = 4h;
requests
| where timestamp > ago(Window)
| where url has "/checkout"
| extend FeatureFlag = tostring(customDimensions["UseNewPaymentAdapter"])
| summarize Requests=count(),
          Failures=countif(success == false),
          P95=percentile(duration, 95)
by bin(timestamp, 10m), FeatureFlag, cloud_RoleName
| order by timestamp asc

Si l’échec apparaît seulement lorsque le flag vaut true, rollbackez le flag ou la règle de ciblage. S’il apparaît sur les deux valeurs après un déploiement, traitez la release applicative comme suspect principal. Si la télémétrie ne contient pas l’état du flag, ajoutez-le avant de rendre le prochain rollout plus autonome.

Vérifier le refresh avant de croire le toggle

Un rollback de feature flag n’est utile que si le runtime l’observe. Les applications mettent souvent les valeurs App Configuration en cache, déclenchent le refresh sur une clé sentinel ou exigent un middleware explicite. Pendant un incident, vérifiez le contrat de refresh.

refresh_contract:
provider: azure-app-configuration
watched_keys:
  - FeatureManagement:UseNewPaymentAdapter
  - AppConfig:Sentinel
expected_refresh_interval: 30s
required_runtime_evidence:
  - current_etag
  - loaded_label
  - last_refresh_timestamp
  - refresh_result
  - fallback_used
block_rollout_when:
  - flag_state_not_logged
  - label_not_visible_in_telemetry
  - refresh_result_unknown
  - emergency_toggle_requires_restart

Si l’application doit redémarrer pour observer un changement de flag, écrivez-le dans le chemin de rollback. Sinon, les opérateurs peuvent croire avoir désactivé une fonctionnalité alors que l’ancienne valeur reste active.

Décider le plus petit rollback

Le rollback doit correspondre à la panne prouvée. Ne désactivez pas tous les feature flags quand un seul label de ring est faux. Ne redéployez pas l’application si la valeur App Configuration précédente est disponible et si le runtime rafraîchit correctement.

Rollback du flag
Les erreurs correlent avec flag=true
Le bon label est prouve
Le refresh runtime est observable
L'ETag ou la valeur precedente est connue

Rollback du label ou du ciblage
Un seul ring, region ou groupe utilisateur est touche
La valeur globale du flag est correcte
Les conditions de ciblage ont change recemment
La version applicative est saine par ailleurs

Corriger identite ou acces dependance
L'acces App Configuration ou Key Vault echoue
L'application utilise des valeurs de fallback
Les logs montrent 401, 403, DNS ou timeout avant l'erreur metier

Rollback de la release applicative
Les erreurs apparaissent dans les deux etats du flag
La telemetrie lie la panne a la version, pas a la configuration
Le code interprete mal un parametre valide
Le rollback configuration ne restaure pas le parcours

Pour App Configuration, un rollback sain est souvent un nouveau changement contrôlé : restaurer l’ancienne valeur, l’ancien label ou l’ancien ciblage. Même sous pression, une édition portail doit laisser une trace exploitable.

Automatiser le paquet de preuves

L’automatisation utile n’est pas un rollback automatique qui part à l’aveugle. C’est un paquet de preuves répétable qui donne à l’opérateur l’état nécessaire pour décider.

evidence_pack:
collect:
  - app_configuration_keys_and_labels
  - feature_flag_definitions
  - etag_and_last_modified
  - runtime_identity
  - key_vault_reference_status
  - application_version
  - telemetry_by_flag_state
  - last_refresh_timestamp
propose:
  - restore_previous_key_value
  - restore_previous_targeting_rule
  - restart_only_if_refresh_contract_requires_it
require_human_validation:
  - production_label_change
  - global_flag_disable
  - secret_reference_change
  - application_release_rollback

Cela garde l’automatisation utile sans lui permettre de masquer la cause. L’opérateur doit voir le rollback proposé et les preuves qui le justifient.

Valider après rollback

Après rollback, validez depuis le parcours applicatif, pas seulement depuis App Configuration. La preuve attendue est simple : la valeur effective a changé, le runtime l’a rafraîchie, le parcours en échec récupère, et aucun autre ring n’a été modifié par erreur.

Validation
La valeur App Configuration ou la regle de ciblage correspond a la decision
Les logs runtime montrent le nouvel ETag et le label attendu
Le taux d'erreur et la latence recuperent sur le parcours touche
Les rings non touches gardent leurs valeurs precedentes
Les references Key Vault resolvent encore
Le dossier incident contient les snapshots avant et apres

Rollback incomplet quand
Seule la valeur portail a change
Le runtime n'a pas rafraichi
L'etat du flag est absent de la telemetrie
Un autre label porte encore la valeur risquee
L'application echoue toujours apres rollback configuration

Conclusion

Azure App Configuration rend les changements runtime plus sûrs seulement si l’équipe peut expliquer ce que l’application a réellement lu. Feature flags, labels, références Key Vault et refresh sont des contrôles de production, pas de simples interrupteurs pratiques.

La décision pratique consiste à rollbacker l’objet le plus étroitement prouvé : le flag, le label, la règle de ciblage, le chemin d’identité ou la release applicative. Quand le paquet de preuves existe, la configuration cesse d’être un canal invisible et devient une partie exploitable du runbook de production.