Aller au contenu principal

Exploitation

La règle qui prime sur toutes les autres​

N'installez pas Kastell dans le périmètre qu'il doit secourir

Même hyperviseur, même domaine Active Directory, même sauvegarde, même fournisseur d'identité : le jour où ce périmètre tombe, Kastell tombe avec lui.

Un hébergeur distinct, un DNS distinct, un canal d'alerte distinct. C'est la seule contrainte d'exploitation qui ne se négocie pas.

Sauvegarde​

Aucun mécanisme de sauvegarde n'est intégré au produit. La console root l'annonce plutôt que d'afficher un état rassurant sans fondement.

Trois volumes à sauvegarder : la base, le stockage objet, les enregistrements.

docker compose -f docker/compose.yaml --env-file .env exec -T postgres \
  pg_dump -U kastell --format=custom kastell > kastell-$(date +%F).dump
Une restauration jamais éprouvée est une hypothèse

Éprouvez-la trimestriellement. Une base restaurée doit passer la vérification d'intégrité de la console root — sinon la sauvegarde n'en était pas une.

Supervision​

GET /api/etat

Sonde publique, sans compte, volontairement pauvre : elle dit si le service fonctionne, jamais qui s'en sert.

Hébergez la page d'état ailleurs

Une page d'état servie par le service qu'elle surveille ne dit rien le jour où celui-ci tombe. Cette sonde est ce qu'interroge une page hébergée ailleurs.

GET /api/administration/metriques

Les mêmes chiffres au format Prometheus, réservés au root : la volumétrie d'une instance dit combien de crises y sont ouvertes.

La console root offre aussi un diagnostic qui interroge réellement chaque brique — base, stockage, média, antivirus, temps réel — avec leur latence. La sonde antivirale présente le fichier d'essai EICAR et exige le verdict « infectée » : un analyseur qui répond « saine » à tout est plus dangereux qu'un analyseur absent, puisqu'il rassure.

Montée de version​

git pull
KASTELL_REVISION=$(git rev-parse HEAD) \
  docker compose -f docker/compose.yaml --env-file .env up -d --build
docker compose -f docker/compose.yaml --env-file .env logs app | head -30

Les migrations s'appliquent au démarrage. L'application ne se déclare prête qu'après migration réussie.

Le compte root​

Il administre l'instance et ne lit pas le contenu des crises. Le passage d'un registre à l'autre existe — un exploitant doit pouvoir aider un client dont la main courante est illisible après restauration — mais c'est un bris de glace : motivé, borné à huit heures, tracé, et visible de l'organisation concernée.

Un root unique enferme dehors

Accordez le droit à un second compte dès que possible. Un root qui perd son téléphone bloque l'exploitant, et le produit refuse de retirer le dernier.

Si vous modifiez Kastell​

L'AGPL, en sa section 13, dit que faire tourner une version modifiée sur un réseau vaut distribution : vos utilisateurs distants ont droit au code de cette version.

KASTELL_SOURCE_URL=https://git.exemple.org/notre-kastell

Un dépôt interne accessible à vos utilisateurs suffit ; il n'a pas à être public. Voir Licence.

Ce qui vous incombe, et que le produit ne fera pas​

  • Tenir le dossier de préparation à jour. L'indicateur le mesure, personne ne le remplira à votre place.
  • Imprimer l'export papier. C'est ce qui reste quand tout est chiffré.
  • Faire ouvrir l'outil à chacun au moins une fois. Un outil découvert le jour de la crise n'est pas utilisé.