Runbook d'exploitation

Ce guide rassemble les gestes d'exploitation de Telaria en production (VPS Ubuntu + Apache). Il complète le guide de déploiement en se concentrant sur le maintien en condition opérationnelle.

Stack de production complète : stack-production.md.

Déployer une mise à jour

Ordre sûr — un faux pas sur l'OPcache casse le web alors que le CLI reste vert :

git pull
composer install --no-dev --optimize-autoloader
php bin/console doctrine:migrations:migrate --no-interaction
php bin/console cache:clear && php bin/console cache:warmup
sudo systemctl reload php8.5-fpm ← indispensable
sudo systemctl restart telaria-messenger-async telaria-veille-scheduler ← les workers ne rechargent pas automatiquement le code

⚠️ Le piège OPcache. En prod, opcache.validate_timestamps=0 impose le rechargement de PHP-FPM après tout changement de code ou de schéma. Sans lui, le CLI et les tests sont verts mais le web (FPM) sert l'ancien code — vécu : SQLSTATE[42S22] Unknown column 't0.username' après un drop de colonne. Détail : deployment.md §5.

⚠️ Le piège workers Messenger. Les workers telaria-messenger-async et telaria-veille-scheduler ne rechargent pas le code PHP au git pull — ils tournent sur la version compilée au démarrage. Un déploiement sans redémarrage des workers laisse la veille tourner sur l'ancien code silencieusement. Vécu 2026-06-02 : 12 jours de veille silencieuse suite à un déploiement sans redémarrage des workers — zéro token consommé, 5500 items en backlog.

Superviser

Consommation API IA et coûts : back-office /admin/metrics (usage et coût par modèle, projection, alertes e-mail). Voir ../specs/telaria-admin.md.
Veille agentique : une source qui échoue plusieurs fois passe en standby automatique (seuil de 3 échecs consécutifs) ; à surveiller dans le back-office veille.
Logs : Apache (/var/log/apache2/), application (var/log/), sudo fail2ban-client status sshd.
Certificats TLS : renouvellement Certbot automatique ; contrôler avec certbot renew --dry-run. Voir ssl-tls.md.

Sauvegarder

Base de données : sauvegarde régulière (mysqldump) — c'est la seule donnée non régénérable.
Index vectoriel RAG : artefact dérivé, non sauvegardé — se régénère avec php bin/console app:rag:ingest.
Documentation : versionnée dans telaria-doc (git) — pas de sauvegarde séparée nécessaire.

Incidents courants

Symptôme	Cause probable	Geste
Web KO mais CLI vert après un déploiement	OPcache sert l'ancien code	`sudo systemctl reload php8.5-fpm`
`SQLSTATE … Unknown column`	migration appliquée sans reload FPM	recharger FPM ; vérifier `doctrine:schema:validate`
Source de veille muette	passée en standby après 3 échecs	lever le standby dans le back-office veille
Veille tourne mais 0 token / 0 résumé	workers Messenger sur ancien code après déploiement	`sudo systemctl restart telaria-messenger-async telaria-veille-scheduler` puis vérifier `php bin/console app:rag:stats`
0 token depuis plusieurs jours	workers arrêtés silencieusement (crash non signalé)	`systemctl is-active telaria-messenger-async` → si failed : `journalctl -u telaria-messenger-async -n 30`
503 sur tous les domaines après upgrade PHP	vhosts manuels ont le socket php8.X-fpm.sock hardcodé	`sudo sed -i 's/php8.X-fpm/php8.Y-fpm/g' /etc/apache2/sites-enabled/*.conf && sudo a2disconf php8.X-fpm && sudo a2enconf php8.Y-fpm && sudo systemctl reload apache2`
Certificat expiré	renouvellement Certbot en échec	`certbot renew --force-renewal` puis recharger Apache

Voir aussi