Opérations
Runbooks J+2 pour opérer Scrydon — sauvegarde, restauration, migrations, rotation de licence, observabilité, transfert SIEM, vérification de la chaîne d'approvisionnement et mises à niveau.
Le J+1 couvre l'installation de Scrydon. Le J+2 couvre son exploitation — sauvegarde, restauration, migrations, rotation de licence, observabilité et les runbooks dont votre équipe d'astreinte a besoin.
Récupérez l'accès administrateur après un mot de passe perdu, et comment rouvrir l'assistant de configuration initiale.
Ce qu'il faut sauvegarder, où se trouve l'état canonique et comment le restaurer.
Comment les migrations de schéma sont appliquées lors des mises à niveau.
Appliquez une licence renouvelée sans interruption de service.
Consultez la mesure horaire, le rapport quotidien, la confidentialité et les mappings GPU.
Métriques de la plateforme, tableaux de bord et SLO à suivre.
Connectez le journal d'audit à Splunk, Datadog, Elastic, Sumo ou Sentinel.
Vérifiez les charts Helm signés, les images signées et le SBOM.
L'ordre des opérations pour une mise à niveau en place.
Attentes J+2
Pour un déploiement Scrydon en état stable, planifiez :
| Activité | Cadence |
|---|---|
| Vérification de l'état du heartbeat de licence | Quotidienne (automatisée) |
| Révision du journal d'audit (événements ciblés) | Hebdomadaire |
| Vérification des sauvegardes (exercice de restauration depuis la veille) | Mensuelle |
| Exercice de reprise après sinistre | Trimestrielle |
| Mise à niveau de version mineure | Trimestrielle |
| Mise à niveau de version majeure | Annuelle |
| Cycle d'analyse des vulnérabilités + correctifs | Continue |
Ce qui nécessite une interruption planifiée
La plupart des opérations sont non-disruptives. Les exceptions :
- Les mises à niveau de version majeure touchant l'entrepôt OLAP (StarRocks) nécessitent généralement une brève fenêtre en lecture seule pendant la reconstruction des index.
- Les changements de stratégie de chiffrement (LOCAL → BYOK → HYOK) nécessitent un rechiffrement des secrets en place — typiquement quelques minutes pour des coffres-forts de taille normale.
- Le remplacement de PostgreSQL par une instance gérée nécessite une fenêtre de migration ponctuelle.
Chacun est couvert dans le runbook correspondant avec la durée estimée.
Où chercher en cas de problème
- Vérifiez d'abord le journal d'audit — la plupart des échecs y apparaissent avec un événement structuré
*_FAILED. - Vérifiez le tableau de bord des métriques de la plateforme pour le sous-système concerné.
- Vérifiez les journaux du sous-système concerné (runtime de workflow, analytique, ontologie, copilote).
- Si le problème n'est visible dans aucun de ces éléments, contactez le support Scrydon avec le journal d'audit et des captures d'écran du tableau de bord.