7 signaux d'alerte en revue d'architecture

La même poignée de problèmes revient dans presque chaque revue d'architecture que je mène, quelle que soit la taille de l'entreprise ou la stack. Voici les sept que je signale le plus souvent, avec la façon dont je les vérifie et ce que je ferais pour les corriger, puis le processus que j'utilise pour mener la revue elle-même.

1. Pas de standby pour la base principale, et de l'analytique qui tourne dessus

Une seule instance de base de données managée, sans standby Multi-AZ (ou HA régionale), porte à la fois le trafic transactionnel et les requêtes analytiques. Les répliques de lecture aident à absorber les lectures, mais en promouvoir une reste un basculement manuel avec perte de données possible, ce qui ne fait pas de la haute disponibilité. Une panne de zone ou d'instance se traduit par une indisponibilité totale, et un seul rapport lourd peut priver le tunnel de paiement d'I/O et de connexions.

Comment le repérer. Vérifiez si l'instance a un standby :

# AWS RDS : existe-t-il un standby synchrone ? (Aurora : cherchez une réplique dans une autre AZ)
aws rds describe-db-instances \
  --query 'DBInstances[].[DBInstanceIdentifier,Engine,MultiAZ]' --output table
 
# Cloud SQL : REGIONAL signifie HA avec standby, ZONAL signifie aucun
gcloud sql instances list --format="table(name,databaseVersion,settings.availabilityType)"

Regardez ensuite qui interroge la base principale. Sur PostgreSQL, pg_stat_activity regroupé par application_name montre généralement l'outil de BI juste à côté de l'application.

La correction. Activez le Multi-AZ (multi_az = true sur aws_db_instance) ou la HA régionale (availability_type = "REGIONAL" sur google_sql_database_instance) dans Terraform. Déplacez l'analytique vers une réplique de lecture, ou de préférence vers un export dans un entrepôt de données. Pour le basculement inter-régions, voir le basculement PostgreSQL multi-régions.

2. Des droits IAM accordés au niveau du projet ou du compte

Des rôles larges (roles/owner, roles/editor, AdministratorAccess) sont attribués aux humains, aux pipelines de CI et aux workloads, alors que chacun devrait avoir un accès au moindre privilège, limité aux ressources dont il a besoin. Un seul token de CI qui fuite ou un pod compromis donne alors accès à tout.

Comment le repérer. Listez qui détient les rôles larges :

# GCP : qui détient des rôles de base sur le projet ?
gcloud projects get-iam-policy my-project \
  --flatten="bindings[].members" \
  --filter="bindings.role:roles/owner OR bindings.role:roles/editor" \
  --format="table(bindings.role,bindings.members)"
 
# AWS : qui a AdministratorAccess attaché ?
aws iam list-entities-for-policy \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

La correction. Définissez les bindings dans Terraform au niveau de la ressource (un bucket, un secret, une file), avec un compte de service ou un rôle par workload. L'IAM Recommender de GCP et les constats d'accès inutilisés d'AWS IAM Access Analyzer montrent quelles permissions ne servent jamais, et vous pouvez les retirer dans une PR.

3. Pas d'objectifs RTO/RPO, ni de test de restauration pour les prouver

Personne ne peut me dire combien de temps il faudrait pour redémarrer après la perte de la base (RTO) ni combien de données seraient perdues (RPO), et personne n'a restauré une sauvegarde depuis plus d'un an. Savoir que les sauvegardes sont « activées » ne répond à aucune de ces deux questions. Sans test, c'est lors de la première vraie restauration qu'on découvre les permissions manquantes, ou qu'elle prend tout l'après-midi.

Comment le repérer. Demandez les objectifs et la date du dernier test de restauration, puis vérifiez la rétention et le point de restauration :

aws rds describe-db-instances \
  --query 'DBInstances[].[DBInstanceIdentifier,BackupRetentionPeriod,LatestRestorableTime]' \
  --output table

La correction. Fixez un RTO et un RPO par service, validés avec le métier. Vérifiez-les ensuite avec un test de restauration planifié dans un environnement isolé :

target="restore-test-$(date +%Y%m%d)"
start=$(date +%s)
aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier prod-db \
  --target-db-instance-identifier "$target" \
  --use-latest-restorable-time \
  --db-subnet-group-name restore-test   # un subnet group isolé, pas celui de la prod
aws rds wait db-instance-available --db-instance-identifier "$target"
echo "Restauration : $(( ($(date +%s) - start) / 60 )) minutes"

Votre RTO mesuré correspond au temps de restauration, plus le temps de pointer une application sur l'instance restaurée et de passer un smoke test. Votre RPO correspond à l'écart entre LatestRestorableTime et maintenant. Comparez les deux aux objectifs, consignez le résultat, puis supprimez l'instance de test.

4. Un cron job ou une VM « temporaire » qui fait tourner quelque chose de critique

Une VM créée à la main il y a deux ans fait tourner la facturation depuis une crontab, en dehors de l'infrastructure-as-code. Le jour où elle meurt, personne ne sait ce qu'elle faisait ni comment elle était configurée, et souvent personne ne savait qu'elle existait.

Comment le repérer. Taguez tout ce que Terraform crée (par exemple managed-by = "terraform" via les default_tags du provider AWS ou les labels GCP), puis listez ce qui ne porte pas le tag :

gcloud compute instances list --filter="-labels.managed-by:terraform"

Sur AWS, la règle managée AWS Config required-tags remonte les ressources non taguées. Sur chaque machine trouvée, crontab -l et systemctl list-timers montrent ce qu'elle exécute.

La correction. Déplacez le job vers un service planifié et défini en code (Cloud Scheduler plus Cloud Run jobs, EventBridge Scheduler plus Lambda ou ECS, ou un CronJob Kubernetes). Alertez quand il ne tourne pas, en plus de quand il échoue.

5. Des chaînes d'appels synchrones qui devraient être des événements

Une requête utilisateur traverse quatre ou cinq services en série, chacun attendant le suivant, même pour du travail que l'utilisateur n'a pas besoin d'attendre (emails, notifications, analytique). Les disponibilités se multiplient le long de cette chaîne. Cinq dépendances à 99,9 % chacune donnent environ 99,5 % de bout en bout, avant même que les retries n'amplifient la charge.

Comment le repérer. Ouvrez la carte des services dans votre outil de tracing (Cloud Trace, X-Ray, ou n'importe quel backend OpenTelemetry) et regardez la profondeur du chemin critique. Pour chaque saut, demandez ensuite ce qui casse si ce service tombe dix minutes.

La correction. Ne gardez un appel synchrone que si la réponse en dépend, et placez le reste derrière une file ou un bus d'événements. Architecture événementielle avec Lambda et EventBridge détaille une façon de le construire.

6. Pas de timeouts, de circuit breakers ni de load shedding

Les clients HTTP gardent des timeouts par défaut (souvent infinis), les retries n'ont pas de backoff, et rien en bordure ne rejette l'excès de charge. Une seule dépendance lente bloque alors tous les workers en amont.

Comment le repérer. Cherchez dans le code l'endroit où les clients HTTP sont créés et vérifiez la présence de timeouts explicites, puis regardez la configuration de la gateway ou du mesh. Si vous utilisez Istio, kubectl get destinationrules -A revient souvent vide.

La correction. Mettez un timeout explicite sur chaque appel sortant, des retries avec jitter et un budget de retries, et du circuit breaking. Avec Istio, l'outlier detection éjecte les endpoints défaillants :

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: payments
  namespace: prod
spec:
  host: payments.prod.svc.cluster.local
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 100
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

Associez-le à du rate limiting sur le load balancer ou l'API gateway, pour que les requêtes en trop soient rejetées vite au lieu de s'accumuler en file d'attente.

7. Des diagrammes d'architecture qui ne correspondent plus à la réalité

La documentation décrit le système tel qu'il était il y a un ou deux ans.

Comment le repérer. Comparez le diagramme à un inventaire généré depuis le cloud lui-même, par exemple avec gcloud asset search-all-resources --scope=projects/my-project ou AWS Resource Explorer, et à terraform state list.

La correction. Gardez les diagrammes sous forme de code (Mermaid ou équivalent) dans le même dépôt que le Terraform, et mettez-les à jour dans la PR qui change l'architecture.

Un cadre pour mener votre propre revue

Je mène chaque revue en quatre passes :

1. Inventaire. Générez la liste de ce qui existe à partir des API du cloud plutôt que de mémoire ou du wiki, et comparez-la à l'état IaC et aux diagrammes (signaux 4 et 7).
2. Parcours des domaines de défaillance. Pour chaque composant du chemin critique, demandez-vous ce qui se passe s'il tombe, si sa zone tombe ou s'il ralentit. Notez ce que fait le système aujourd'hui, qui peut différer de ce qui était prévu (signaux 1, 5 et 6).
3. Test de restauration. Restaurez le stockage de données le plus important en chronométrant l'opération par rapport aux objectifs RTO/RPO (signal 3).
4. Vérification des coûts et de la responsabilité. Chaque ressource doit avoir un label de propriétaire et une équipe alertée en cas de problème, et chaque droit IAM large une justification nominative (signal 2).

Classez vos constats par rayon d'impact et probabilité, attribuez à chacun un responsable et un ticket, et refaites la revue deux fois par an ou après tout changement majeur. Dans mes revues, l'écart entre les diagrammes et ce qui est réellement déployé revient le plus souvent, et c'est le genre de problème qu'un regard extérieur repère facilement.