Runbooks

Objectif

Procédures opérationnelles pour opérer Finoptika en production. Public : SRE, platform, support enterprise. Ces pages résument les runbooks du dépôt (docs/guides/RUNBOOK_*.md) — reportez-vous à la source pour les commandes exactes.

Incident

1. Constater — vérifier la Santé plateforme et l'Ingress.
2. Isoler — API ? Worker ? DB ? Redis ? (voir l'architecture cible dans Déploiement production).
3. Diagnostiquer — logs API/worker, statut des jobs d'ingest, connectivité DB/Redis.
4. Rétablir — redémarrer le composant fautif ; rejouer un job d'ingest si nécessaire.
5. Journaliser — l'audit trail trace connexions et mutations.

Référence : docs/guides/RUNBOOK_INCIDENT.md.

Restauration base (restore)

• Sauvegardes PostgreSQL régulières (cron / snapshot managé).
• Restaurer sur une instance saine, appliquer alembic upgrade head.
• 🔒 Après restore, vérifier que la RLS est bien active sur toutes les tables tenant.

Référence : docs/guides/RUNBOOK_RESTORE.md.

Observabilité & déploiement

• Vérifier l'état des composants via /health/capabilities et Santé plateforme.
• Suivre le pipeline de déploiement (tag vX.Y.Z → GitHub Actions kustomize).
• Surveiller workers Celery (ingest, alertes budget), latence API, saturation DB/Redis.

Référence : docs/guides/RUNBOOK_OBSERVABILITY_DEPLOY.md.

Park / Wake (environnement démo)

Mettre en veille / réveiller un environnement de démonstration pour maîtriser les coûts.

Référence : docs/guides/RUNBOOK_PARK_WAKE_DEMO.md.

Bonnes pratiques opérationnelles

• 🔒 Ne jamais désactiver la RLS en dehors des migrations Alembic.
• Tester les restores régulièrement (un backup non testé n'est pas un backup).
• Documenter chaque incident (post-mortem) et alimenter les runbooks.

Voir aussi

• Déploiement production
• Santé plateforme
• Référence dépôt : docs/guides/RUNBOOK_*.md, docs/deploy/INFRA_REVIEW.md