Aller au contenu principal

Fiabilité et reprise après sinistre

La plateforme QALITA stocke certaines données critiques qui doivent être sauvegardées et restaurées en cas de sinistre.

🧩 Sauvegarde​

La sauvegarde de la plateforme est effectuée par l’administrateur système en assurant la persistance des éléments suivants :

ÉlémentNiveau de criticitéFréquence recommandée de sauvegarde
Postgresql➕➕➕ ⚠️ Critique ⚠️Quotidienne
Seaweedfs➕➕ ModéréeHebdomadaire
Agents➕➕ Modérée(Peut être sauvegardé par PVC pour garantir une continuité de service optimale)
RedisNulle (stateless)Aucune
FrontendNulle (stateless)Aucune
BackendNulle (stateless)Aucune

📦 Postgresql​

La sauvegarde peut être configurée via la fonctionnalité de backup du chart Helm Bitnami.

attention

Par défaut avec le Helm QALITA, cette sauvegarde n’est pas activée. Une fois activée, la sauvegarde est effectuée dans un PVC qui doit lui-même faire l’objet d’une sauvegarde dans un stockage à froid ou semi-froid.

🗃️ Seaweedfs​

Le stockage Seaweedfs est moins critique car il contient uniquement :

  • Des logs
  • Des archives de packs dont le code est versionné dans un VCS (ex : GitLab)
info

Dans Kubernetes, sauvegardez le PVC contenant les données. Si vous n’avez pas la gestion de votre cluster, assurez-vous que les PVC sont inclus dans la stratégie de sauvegarde (contactez l’administrateur du cluster).

🛰️ Agent​

Les agents stockent des informations importantes pour leur fonctionnement :

  • Sources (qalita-conf.yaml)
    Ce fichier contient les définitions de sources. Il est important de le sauvegarder.
    Dans le déploiement QALITA, un agent local peut être déployé avec persistance du dossier ~/.qalita/.

  • Connexion à la plateforme (.agent)
    Contient les infos de connexion récentes.

    attention

    ⚠️ Ces fichiers ne doivent pas être sauvegardés. Utilisez les variables d’environnement pour l’authentification. Les fichiers .env-<login> sont temporaires et sensibles.

  • Résultats des exécutions (~/.qalita/agent_temp_run/)
    Peut être configuré pour être persistant et sauvegardé.

💾 Restauration​

PostgreSQL​

Suivre la documentation Bitnami PostgreSQL

Seaweedfs​

Voir la documentation officielle SeaweedFS

Agents​

  1. Réenregistrement de l’agent :
    Lancer qalita agent login et copier le dossier ~/.qalita/.

  2. Restauration des sources :
    Restaurer le fichier qalita-conf.yaml.

  3. Synchronisation des IDs de sources :
    Utiliser qalita source push pour réaligner les sources locales avec celles de la plateforme.

⚠️ Mode dégradé​

En cas de perte partielle d’un composant, la plateforme peut continuer à fonctionner en mode dégradé. Voici les principaux scénarios :

Composant manquantImpactContournement possible
PostgreSQLBlocage complet de la plateformeAucune, restauration obligatoire
SeaweedfsPerte temporaire des logs et archivesFonctionnement partiel possible
Agent indisponibleLes exécutions planifiées ou manuelles échouentRelancer l’agent ou utiliser un agent local
Plateforme web (frontend)Accès en lecture impossibleUtiliser l’API REST ou CLI (si backend toujours actif)
Backend indisponibleTous les accès API et exécutions sont bloquésAucune, nécessite redéploiement ou restauration
RedisPerte de performance sur certaines opérationsRéexécutions manuelles, fonction partiellement stable

🔭 Supervision et SRE​

🧠 Observabilité​

Outils recommandés :

ComposantOutil recommandé
LogsLoki + Grafana / ELK
MétriquesPrometheus + Grafana
Uptime / probesUptime Kuma / Blackbox
TracingJaeger / OpenTelemetry

📢 Alerte proactive​

Définir des seuils critiques :

  • Backend > 2s de latence
  • Taux HTTP 5xx > 2%
  • PVC PostgreSQL > 85% d’occupation

Envoi via :

  • Email
  • Slack / MS Teams
  • Opsgenie / PagerDuty

🛡️ Résilience recommandée​

DomainePratique SRE recommandée
DBBackups + tests de restauration réguliers
StockageSauvegardes hebdomadaires, monitoring du volume
RéseauLB avec healthchecks + retries dans les ingress
DéploiementRolling update
IncidentsRunbooks + postmortems
AgentsDéploiement avec PVC, cronjob pour relance automatique

🔁 Tests de résilience​

  • Suppression volontaire d’un pod
  • Crash simulé sur DB
  • Test failover si réplicas
  • Simulation de coupure réseau
  • Restauration réelle d’un backup

📚 Runbooks​

1. 🔥 Backend ne répond plus​

Symptômes​

  • API REST indisponible (5xx, timeout)
  • Interface web ne charge pas (erreur 502/504)

Diagnostic​

kubectl get pods -n qalita
kubectl logs <pod-backend> -n qalita

Actions immédiates​

  • Supprimer le pod fautif :
    kubectl delete pod <pod-backend> -n qalita
  • Vérifier les ressources :
    kubectl top pod <pod-backend> -n qalita
  • Si l'erreur vient d’une DB inaccessible :
    kubectl exec <pod-backend> -- psql <url>

Rétablissement​

  • Pod recréé automatiquement ? ✅
  • Tests API : curl <backend-url>/health
  • Tester un appel d’API métier

Postmortem​

  • Raison de la chute ? (OOM, crash, erreur logique)
  • Besoin d’augmenter les ressources ? d’ajouter un readiness probe ?

2. 📉 PostgreSQL down​

Symptômes​

  • Backend crash en boucle
  • Logs contenant could not connect to server: Connection refused
  • kubectl get pvc indique un problème d’attachement

Diagnostic​

kubectl get pods -n qalita
kubectl describe pod <postgresql-pod>
kubectl logs <postgresql-pod> -n qalita

Actions immédiates​

  • Supprimer le pod : kubectl delete pod <postgresql-pod> -n qalita
  • Vérifier le PVC :
    kubectl describe pvc <postgresql-pvc> -n qalita

Restauration​

  • Si les données sont perdues → restauration à partir du backup : 
    helm install postgresql bitnami/postgresql \
      --set postgresql.restore.enabled=true \
      --set postgresql.restore.backupSource=<source>

Postmortem​

  • Pourquoi le pod est-il tombé ?
  • Sauvegardes récentes valides ?
  • Tests de restauration automatisés à planifier ?

3. 🧊 SeaweedFS inaccessible​

Symptômes​

  • Les téléchargements d’archives échouent
  • Impossible d’afficher les logs des tâches

Diagnostic​

kubectl logs <seaweedfs-pod> -n qalita
kubectl describe pvc <seaweedfs-pvc> -n qalita

Actions immédiates​

  • Vérifier l'état du PVC
  • Supprimer puis relancer le pod
  • Redémarrer le volume si CSI driver (EBS, Ceph...)

Rétablissement​

  • Valider que les objets sont accessibles via la plateforme
  • Relancer une tâche qui génère un log

Postmortem​

  • Est-ce un souci de saturation du PVC ?
  • L'absence d’alerting a-t-elle allongé la panne ?

4. ⏳ Agent bloqué ou offline​

Symptômes​

  • Tâches ne s’exécutent plus
  • L’agent n’apparaît plus dans l’interface

Diagnostic​

kubectl logs <agent-pod> -n qalita
qalita agent ping

Actions immédiates​

  • Redémarrer l’agent local : qalita agent restart
  • Réenregistrer : qalita agent login
  • Vérifier les accès réseau (peut-il atteindre l’API ?)

Rétablissement​

  • Test d’une tâche simple via qalita task run
  • Vérifier la réception du résultat sur la plateforme

Postmortem​

  • Agent trop vieux ? Problème de DNS ?
  • Superviser les agents via un heartbeat régulier

5. 🟣 Mémoire ou CPU saturés​

Symptômes​

  • Pod redémarre en boucle (CrashLoopBackOff)
  • Latence de l’API élevée

Diagnostic​

kubectl top pod -n qalita
kubectl describe pod <pod-name>

Actions immédiates​

  • Augmenter les ressources dans les values.yaml
  • Vérifier si un processus consomme anormalement (profiling via pprof)

Rétablissement​

  • Appliquer les nouveaux paramètres de ressources : 
    helm upgrade qalita-platform ./chart --values values.yaml

Postmortem​

  • Le HPA est-il activé ?
  • Y a-t-il un pic lié à une tâche spécifique ?

6. 🚧 Certificat TLS expiré​

Symptômes​

  • Impossible d’accéder à l’interface
  • Erreur navigateur "connexion non sécurisée"

Diagnostic​

kubectl describe certificate -n qalita
kubectl get cert -n qalita

Actions immédiates​

  • Renouveler manuellement : 
    kubectl cert-manager renew <cert-name>
  • Forcer le redeploy de Traefik/Ingrédients

Rétablissement​

  • Attendre que le certificat soit "Ready" : 
    kubectl get certificate -n qalita -o wide

Postmortem​

  • Cert-manager fonctionne-t-il correctement ?
  • Alerte sur expiration à J-15 à mettre en place

7. 🔒 Problème de licence​

Symptômes​

  • Messages Licence invalide ou expirée
  • API retourne 401 à la connexion

Diagnostic​

  • Vérifier la variable QALITA_LICENSE_KEY
  • Test de vérification : 
    curl -H "Authorization: Bearer <token>" \
      https://<registry>/v2/_catalog

Actions immédiates​

  • Vérifier la date d’expiration (contenue dans le token JWT)
  • Prolonger via le portail ou contacter le support

Rétablissement​

  • Redéploiement du backend avec nouvelle licence (si variable montée via secret/env)

Postmortem​

  • Le renouvellement est-il automatisé ou surveillé ?
  • Alerte déclenchée à l’avance ?

🔁 Suggestion d’automatisation​

IncidentAutomatisation possible
Agent offlineCron job de qalita agent ping avec alerte
Cert TLS expiréScript qui scrute les certificats à J-30
PostgreSQL saturéAlertes Prometheus sur pg_stat_activity
PVC presque pleinAlerting sur occupation disque via kubelet ou metrics

🗂️ Astuce : Classer les incidents dans Grafana OnCall / Opsgenie​

  • Categorie : backend, db, network, tls, storage
  • Priorité : P1 (bloquant), P2 (dégradé), P3 (mineur)
  • Responsable : infra, dev, data