Runbook de mise à jour

Ce runbook couvre une mise à jour en place d'un cluster Scrydon en cours d'exécution. Pour les mises à jour de versions majeures incluant des changements incompatibles, suivez les notes de version en plus de ce runbook.

Avant la mise à jour

1. Lisez les notes de version. Notez les changements incompatibles, les modifications requises des valeurs Helm ou les migrations de schéma nécessitant des étapes manuelles.
2. Vérifiez les artefacts. Exécutez cosign verify sur les nouvelles images et le nouveau chart. Voir Vérification de la chaîne d'approvisionnement.
3. Prenez un snapshot PostgreSQL. En cas de problème, c'est votre chemin de restauration. Voir Sauvegarde et restauration.
4. Vérifiez la licence. Confirmez que votre licence dispose d'au moins 90 jours restants via Paramètres → Licence dans l'interface de la plateforme. Sinon, renouvelez-la en premier. Voir Renouvellement de licence.
5. Confirmez que le redirecteur d'audit est sain. Les mises à jour émettent une quantité importante d'événements ; vous souhaitez qu'ils soient capturés.

Commande de mise à jour

Scrydon est distribué sous forme d'un chart Helm unique (oci://scrydonops.azurecr.io/scrydon/charts/scrydon). Une seule commande helm upgrade met à jour tous les services. Les Jobs de hook pré-mise à jour du chart gèrent l'ordre des migrations (db-ensure-databases au poids 1, auth-migration au poids 5, tous les autres Jobs de migration au poids 6) — les opérateurs n'ont pas à séquencer les sous-charts manuellement.

helm upgrade scrydon oci://scrydonops.azurecr.io/scrydon/charts/scrydon \
  --version <new-version> \
  --namespace scrydon-platform \
  --values values.customer.yaml \
  --wait --timeout 15m

# Verify rollout
kubectl rollout status deployment/api-platform -n scrydon-platform
kubectl rollout status deployment/agentic -n scrydon-platform     # (or scrydon-agentic if you split namespaces)
kubectl rollout status deployment/analytics -n scrydon-platform   # if analytics.enabled

Si vous avez explicitement séparé les espaces de noms via les surcharges namespaces.*, pointez chaque kubectl rollout status vers l'espace de noms correspondant. La configuration par défaut du chart regroupe tout dans scrydon-platform.

Surveiller la migration

Les migrations s'exécutent sous forme de Jobs de hook pré-mise à jour Helm (auth-migration-<rev>, agentic-migration-<rev>, analytics-migration-<rev>, cortex-migration-<rev>, api-ontology-migration-<rev>). Ils ont un BackoffLimit: 3 et écrivent des journaux structurés.

kubectl get jobs -n scrydon-platform | grep migration
kubectl logs job/auth-migration-<rev> -n scrydon-platform

La table de suivi des migrations dans chaque base de données est drizzle.__drizzle_migrations :

kubectl exec -it deploy/db -n scrydon-platform -- \
  psql -U postgres -d auth \
  -c "SELECT id, hash, created_at FROM drizzle.__drizzle_migrations ORDER BY id DESC LIMIT 5;"

En cas d'échec d'une migration, consultez Migrations de bases de données → Gestion d'un échec de migration.

Vérification après la mise à jour

Une fois tous les déploiements terminés, vérifiez que la plateforme est saine :

1. Connectez-vous. Confirmez que le SSO fonctionne toujours.
2. Ouvrez un workflow. Confirmez que l'éditeur se charge et que la liste des intégrations est correcte.
3. Exécutez un workflow connu. Confirmez que l'exécution se termine avec la même sortie qu'avant.
4. Consultez le journal d'audit. Confirmez que de nouveaux événements arrivent.
5. Vérifiez le SIEM. Confirmez que le transfert a repris après le déploiement.
6. Vérifiez les métriques. Comparez les tableaux de bord post-mise à jour avec la situation pré-mise à jour — les changements significatifs nécessitent une investigation.

Restauration

Pour une restauration propre :

# Roll the single Scrydon release back to the previous revision
helm rollback scrydon <previous-revision> -n scrydon-platform

# Confirm the revision moved
helm list -n scrydon-platform

Si les migrations ont modifié le schéma d'une manière que la version précédente de l'application ne peut pas lire, restaurez depuis le snapshot PostgreSQL pris avant la mise à jour.

Validez toujours la restauration avec les mêmes étapes de vérification post-mise à jour avant de déclarer la restauration terminée.

Voir aussi

• Mises à jour — la page de niveau supérieur sur les mises à jour.
• Migrations de bases de données — les mécanismes internes des migrations.
• Sauvegarde et restauration — le chemin de reprise après sinistre.