Exploitation · Opérations

Runbook de mise à jour

L'ordre des opérations pour une mise à jour en place d'un cluster Scrydon.

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

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.
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.
Prenez un snapshot PostgreSQL. En cas de problème, c'est votre chemin de restauration. Voir Sauvegarde et restauration.
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.
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.

Si la version cible inclut 0102_remove_legacy_chat, comptez et exportez public.chat depuis la base de données Agentic avant d'exécuter Helm. Cette migration pré-mise à jour destructive retire l'ancien chat hébergé Agentic. Suivez la procédure requise d'export et de retour arrière.

Si la version cible inclut 0171_ba175_account_issuer_relax (Better Auth 1.7.5), exécutez cette requête en lecture seule sur la base de données auth avant d'exécuter Helm, puis à nouveau une fois le déploiement terminé :

sql

SELECT provider_id, account_id, count(*) FROM account
  GROUP BY provider_id, account_id HAVING count(*) > 1;

Elle ne doit renvoyer aucune ligne. Chaque ligne est une identité de connexion que la nouvelle version refuse de résoudre : l'utilisateur concerné ne peut plus se connecter avec ce fournisseur tant que le doublon n'est pas supprimé. Conservez le compte avec lequel l'utilisateur se connecte réellement. Ne fusionnez pas les comptes sur l'adresse e-mail. Le retour arrière de cette version passe par la restauration du snapshot pris avant la mise à jour (voir Restauration ci-dessous).

Si la version cible fait passer Better Auth de la version 1.7.6 ou antérieure à la version 1.7.7 ou ultérieure, les liens magiques et les connexions par authentification unique en cours pendant le remplacement des pods ne peuvent pas aboutir. Aucune action n'est requise avant la mise à jour et aucune migration de schéma n'est nécessaire. Les utilisateurs concernés demandent un nouveau lien magique ou relancent la connexion.

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, propres à chaque service, gèrent l'ordre des migrations (db-ensure-databases au poids 1, auth-migration et events-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.

bash

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>, events-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.

bash

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 :

bash

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 :

Connectez-vous. Confirmez que le SSO fonctionne toujours.
Ouvrez un workflow. Confirmez que l'éditeur se charge et que la liste des intégrations est correcte.
Exécutez un workflow connu. Confirmez que l'exécution se termine avec la même sortie qu'avant.
Consultez le journal d'audit. Confirmez que de nouveaux événements arrivent.
Vérifiez le SIEM. Confirmez que le transfert a repris après le déploiement.
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

Les migrations de schéma ne sont pas rétrogradées. Si la mise à jour a appliqué une migration, restaurer l'application est nécessaire mais pas suffisant — vous devrez peut-être restaurer le snapshot de base de données pris avant la mise à jour. En particulier, 0102_remove_legacy_chat supprime une table et rend l'ancien code du chat public inutilisable jusqu'à la restauration du snapshot Agentic complet. Après 0171_ba175_account_issuer_relax, la version précédente ne trouve pas les comptes créés par la nouvelle : restaurez le snapshot auth plutôt que de revenir seulement à l'application précédente.

Pour une restauration propre :

bash

# 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.

Exploitation · Opérations

Runbook de mise à jour

L'ordre des opérations pour une mise à jour en place d'un cluster Scrydon.

Avant la mise à jour

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.
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.
Prenez un snapshot PostgreSQL. En cas de problème, c'est votre chemin de restauration. Voir Sauvegarde et restauration.
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.
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.

sql

SELECT provider_id, account_id, count(*) FROM account
  GROUP BY provider_id, account_id HAVING count(*) > 1;

Commande de mise à jour

bash

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

bash

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 :

bash

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 :

Connectez-vous. Confirmez que le SSO fonctionne toujours.
Ouvrez un workflow. Confirmez que l'éditeur se charge et que la liste des intégrations est correcte.
Exécutez un workflow connu. Confirmez que l'exécution se termine avec la même sortie qu'avant.
Consultez le journal d'audit. Confirmez que de nouveaux événements arrivent.
Vérifiez le SIEM. Confirmez que le transfert a repris après le déploiement.
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 :

bash

# 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.