SYSADMIN · QUOTIDIEN

Ce qu'un sysadmin fait réellement chaque semaine dans monsys.ai

Cinq actions concrètes qui reviennent chaque semaine. Avec la requête SQL, l'appel curl ou le chemin de clic qui fait le travail en quelques secondes — pas dans un thread de ticket.

Docs complètes
01

Lundi matin — qu'est-ce qui a changé pendant le weekend

Personne ne vous a appelé, mais cela ne veut pas dire que tout est resté tranquille. Drift, fixes ad-hoc, exécutions d'EAT — vous voulez une vue d'ensemble en 30 secondes.

  1. Sidebar → Audit-log
  2. Filtre : dernières 72h + groupe par event_type
  3. Cliquez chaque ligne drift_event pour operator + raison
  4. Drift inexpliquée ? → agent → Inventaire → Restore

L'Audit Pack du mois prochain contient le même aperçu, signé Ed25519.

Idem via API (sql) — pour automatisation
SELECT a.hostname, l.event_type,
       l.event_data->>'reason' AS reason,
       u.email AS actor, l.created_at
  FROM audit_log l
  LEFT JOIN agents a ON a.id = l.agent_id
  LEFT JOIN users  u ON u.id = l.user_id
 WHERE l.tenant_id = $1::UUID
   AND l.created_at >= NOW() - INTERVAL '72 hours'
 ORDER BY l.created_at DESC;
02

Patcher une CVE noyau sur 80 hôtes prod — sans coupure

USN-2026-1234 touche toute votre flotte Ubuntu. Apt-get install manuel sur 80 hôtes n'est pas une option ; tout redémarrer en même temps non plus.

  1. Sidebar → CVE noyau → onglet Batches actifs
  2. Bouton 'Nouveau batch' → tag-selector 'production' + noyau cible
  3. Saisir TOTP → Démarrer canary
  4. Suivre canary → primary → completed dans la même vue

Chaque EAT noyau atterrit dans audit_log + transparency_log. Client + auditeur peuvent vérifier hors-ligne avec le CLI monsys-verify-eat.

Idem via API (bash) — pour automatisation
curl -X POST https://app.monsys.ai/api/v1/kernel-updates/batches \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-TOTP-Code: 123456" \
  -d '{
    "title":           "USN-2026-1234 — kernel 6.8.0-49.49",
    "target_kernel":   "6.8.0-49.49",
    "package_manager": "apt",
    "reboot_strategy": "auto-at-window",
    "selector_kind":   "tag",
    "selector_value":  {"tag":"production"}
  }'
03

Pourquoi ai-je reçu 438 alertes cette nuit

Le dédup d'alertes échoue généralement parce qu'un titre contient une valeur variable (compteur, pourcentage, timestamp) — chaque nouvelle valeur = nouvelle clé dédup = nouvelle alerte.

  1. Sidebar → Alertes → onglet 'Grouped by title'
  2. Trier descending par count
  3. Cliquer sur le plus grand groupe — y a-t-il une valeur dans le titre ?
  4. /settings/alert-rules → corriger la règle pour mettre la valeur en description

L'helper InsertAlert déduplique 30 min par (tenant, agent, category, title). Les fenêtres de maintenance silencent automatiquement pendant l'entretien.

Idem via API (sql) — pour automatisation
SELECT title, COUNT(*),
       MIN(created_at), MAX(created_at)
  FROM alerts
 WHERE tenant_id = $1::UUID
   AND created_at >= NOW() - INTERVAL '24 hours'
 GROUP BY title
 ORDER BY 2 DESC LIMIT 10;
04

Employé parti — trouvez chaque système où il avait accès

Alice démissionne demain. Vous devez savoir : quels serveurs, quelles clés SSH, quels sièges Copilot/OpenAI, quels droits sudo — sur tous les tenants.

  1. Sidebar → Identity surface → rechercher 'alice@'
  2. Voir systèmes liés (hosts, SSH keys, sièges Copilot)
  3. Par système, bouton 'Revoke' → TOTP
  4. Audit-log montre 'identity_revoked' comme preuve

Les actions via run_playbook EAT sont dans audit_log par hôte + une ligne parent qui lie tous les child-EATs pour la traçabilité.

Idem via API (bash) — pour automatisation
# Identity surface — search across systems
curl 'https://app.monsys.ai/api/v1/identity/persons?email=alice@acme.com' \
  -H "Authorization: Bearer $TOKEN"

# Bulk revoke via a playbook EAT (TOTP required)
curl -X POST https://app.monsys.ai/api/v1/agents/<id>/emergency \
  -H "X-TOTP-Code: 123456" \
  -d '{"actions":[{"kind":"run_playbook","id":"revoke-user"}]}'
05

Les backups DB de production fonctionnent-ils toujours

Les outils de backup rapportent succès/échec à monsys. Un outil qui n'a plus tourné depuis 18 jours ne rapporte pas non plus d'échec — juste du silence.

  1. Sidebar → Inventaire → onglet Backups
  2. Filtre sur tag 'production-db'
  3. Trier 'Last successful' ascending
  4. Cliquer 'Create alert rule' sur host stale → seuil 25h

Les preuves de backup (90 derniers jours de runs réussis par hôte) apparaissent automatiquement dans l'Audit Pack mensuel sous NIS2 §2(c) continuité d'activité.

Idem via API (sql) — pour automatisation
SELECT a.hostname, b.tool, b.destination,
       b.last_successful_run,
       NOW() - b.last_successful_run AS age,
       b.last_failure_message
  FROM backup_configs b
  JOIN agents a ON a.id = b.agent_id
 WHERE b.tenant_id = $1::UUID
   AND 'production-db' = ANY(a.tags)
 ORDER BY b.last_successful_run NULLS FIRST;

Autres rôles

Lire la doc pratique détaillée