Monitoring & incidents

Supervision, logs, sauvegardes, runbook incident. La règle : aucune donnée financière n'est jamais perdue silencieusement. Un soldat manquant en monnaie locale déclenche une investigation immédiate.

Logs Monolog

Tous les logs partent vers var/log/, segmentés par channel :

Channel	Fichier	Niveau prod
app	var/log/prod.log	warning
sepa	var/log/sepa.log	info
ssa	var/log/ssa.log	info
helloasso	var/log/helloasso.log	info
payzen	var/log/payzen.log	info
doctrine	var/log/prod.log	error
deprecation	var/log/deprecation.log	info

Rotation par logrotate (config /etc/logrotate.d/kohinos), rétention 90 jours minimum.

Supervision

• Disponibilité : ping HTTP régulier sur /health (Uptime Kuma self-host, ou équivalent).
• Erreurs applicatives : GlitchTip self-host (compatible API Sentry), DSN dans .env.local.
• Métriques système : Netdata, Prometheus + Grafana, ou htop + fail2ban selon échelle.
• Mail bounces : suivi côté SMTP (Postfix logs) — un bounce sur un envoi SEPA est toujours à traiter.

Vérifications quotidiennes automatisées

# Cron quotidien 04:00 — voir devops/cron.html
0 4 * * * www-data cd /var/www/kohinos && \
    php bin/console kohinos:accounts:check --env=prod \
    || mail -s "[KOHINOS] Anomalie comptes !" tresorier@example.org

kohinos:accounts:check vérifie : somme(débits) = somme(crédits), pas de solde en deçà du découvert autorisé, intégrité des chaînes flux.hash / operation.hash.

Sauvegardes

• Dump quotidien chiffré (gpg ou age) vers stockage déporté self-host (Nextcloud, Borg…).
• Rétention : 7 dumps quotidiens + 4 hebdo + 12 mensuels.
• Test de restauration au moins une fois par trimestre sur un environnement de staging.
• Sauvegarde des secrets : config/secrets/prod/prod.encrypt.public.php (peut être versionné) + clé privée hors du repo (gestionnaire de secrets séparé).

Runbook incident — perte de cohérence financière

1. Geler les écritures : désactiver les crons financiers (kohinos:sepa:*, kohinos:ssa:*) et activer un mode lecture seule si possible.
2. Snapshot DB immédiat : mysqldump --single-transaction --quick.
3. Lancer un diagnostic : php bin/console kohinos:accounts:check et inspecter var/log/ssa.log / sepa.log.
4. Comparer avec la dernière sauvegarde cohérente.
5. Reproduire en environnement de staging avant tout correctif en prod.
6. Communiquer : tenir le trésorier informé, notifier les adhérents impactés si nécessaire (privilégier la transparence).
7. Post-mortem : documenter dans docs/audits/, créer un ADR si une décision durable est prise.

Runbook incident — webhook HelloAsso/PayZen perdu

1. Identifier les PendingPaymentData bloqués (statut pending > 1h).
2. Confronter avec le tableau de bord HelloAsso/PayZen (paiement réellement encaissé ?).
3. Rejouer le webhook côté HelloAsso (UI admin) — les handlers sont idempotents, pas de risque de double crédit.
4. Si rejeu impossible : créer manuellement le Flux avec le bon hash de référence, en transaction atomique.

Healthcheck route applicative

Endpoint /health recommandé (à implémenter si absent) qui vérifie : connexion DB, dernière exécution cron OK, espace disque, file mail non saturée.

Indicateurs à surveiller

Indicateur	Seuil d'alerte
Échecs kohinos:accounts:check	Tout échec → alerte trésorier immédiate
Mandats SEPA pending > 7 jours	Alerte trésorier hebdo
Webhooks HelloAsso/PayZen pending > 1h	Alerte technique immédiate
Bounces mail	> 5 % des envois
Charge MariaDB	Connexions actives > 80 % du max
Espace disque	< 20 % libre