NIS2 Agile
Cybersecurity Compliance NIS2
Standard OperativoContinuita di Servizio
Strategia di Continuita di Servizio
Architettura di resilienza, monitoraggio, auto-recovery e protezione dei dati
Aprile 2026 PHP+MySQL+Qdrant Hetzner CPX31 99.9% SLA Target

1. Architettura di Servizio

NIS2 Agile e composto dai seguenti servizi gestiti sulla piattaforma Hetzner condivisa con gli altri prodotti della suite Agile Technology.

ServizioStackHealthcheck
nis2-appPHP+MySQL+Qdrant/health
MySQL/PostgreSQLDatabase condivisoping
QdrantVector DB (embeddings)HTTP 200
AgileHub (NEXUS)Ticket + AI + Notifiche/health
Deploy a caldo: le modifiche al codice sorgente vengono applicate via bind mount Docker o PM2 reload. Nessun rebuild necessario per aggiornamenti ordinari.

2. Strategia di Resilienza a 7 Livelli

L1

Auto-Restart Container / PM2

Ogni servizio ha restart: unless-stopped (Docker) o pm2 --watch (Node.js). Se un processo crasha, viene riavviato automaticamente entro 10-30 secondi.

Tempo di recovery: < 30 secondi

L2

Healthcheck Nativo

Ogni servizio espone un endpoint /health o /api/health verificato ogni 30 secondi. Se il check fallisce 3 volte consecutive, il container/processo viene ricreato automaticamente.

Rileva: crash applicativo, memoria esaurita, deadlock, loop infinito.

L3

Database Retry con Reconnect

Tutti i servizi implementano retry automatico su errori transitori del database (MySQL/PostgreSQL):

  • 2006 — Server has gone away (reconnect)
  • 2013 — Lost connection during query (retry)
  • 1213 — Deadlock found (retry con backoff)

Strategia: 2 retry con backoff esponenziale + reconnect automatico.

L4

Resilienza API Esterne

Le chiamate ad API esterne (Claude AI, ElevenLabs TTS, Voyage embeddings) hanno protezione a 3 livelli:

  1. Retry con backoff: 3 tentativi su errori transitori (429, 500, 502, 503)
  2. Degradazione graceful: se l'AI non risponde, il prodotto funziona con i dati locali
  3. Frontend fallback: messaggio "AI temporaneamente non disponibile" con suggerimenti alternativi
L5

Error Alerting in Tempo Reale

Ogni errore critico genera una notifica AgileHub (campanella) per l'admin e, se configurato, un'email di alert. L'admin vede l'errore entro 30 secondi via polling badge.

L6

Monitoraggio Esterno AgileHub

Il cron AgileHub (ticket-agent-cron.sh) verifica lo stato di tutti i container ogni 2 minuti. Se un prodotto non e raggiungibile, viene segnalato nel log e inviata notifica.

Complementare ai healthcheck interni: rileva problemi di rete, proxy Apache, DNS.

L7

Manutenzione Preventiva

Script automatici prevengono il degrado:

OperazioneFrequenzaFunzione
Disk monitorOgni 6 oreAlert email se disco > 85%
CleanupSettimanaleElimina file temporanei, Docker prune
SSL renewalSettimanaleRinnovo automatico Let's Encrypt
Claude authOrarioRefresh token OAuth Claude Code

3. Protezione da Abuso

Rate Limiting

EndpointLimiteFinestraTipo
Login5 tentativi15 minPer IP + lockout
API generiche100 req1 oraPer chiave/utente
Password reset3 req1 oraPer email
Webhook esterni50 req1 minPer IP

4. Modalita Manutenzione

Quando il sistema AgileHub applica un fix approvato, il maintenance mode si attiva automaticamente:

  1. Il cron agent crea il flag /tmp/maintenance-NIS2.flag
  2. Apache rileva il flag e mostra la pagina di manutenzione a tutti gli utenti
  3. Il fix viene applicato (Claude nel container DevEnv)
  4. Il flag viene rimosso — il prodotto torna online
  5. La pagina di manutenzione si auto-aggiorna e reindirizza gli utenti
Nessun intervento manuale richiesto: il maintenance mode e completamente automatico. L'utente vede un messaggio professionale e il sistema torna online da solo.

5. Matrice Rischi e Mitigazione

ScenarioProbabilitaImpattoMitigazioneRecovery
Crash singolo servizioMediaMedioAuto-restart Docker/PM2< 30s
Database restartBassaAltoDB retry + reconnect< 5s
AI non disponibileMediaBasso3 retry + gracefulFunzioni base intatte
Disco pienoBassaAltoMonitor 6h + cleanupAlert prima del 85%
SSL scadutoBassaAltoAuto-renewal certbotRinnovo 30gg prima
Attacco brute forceMediaMedioRate limit + lockoutBlocco 15 min
Errore deploymentMediaAltoMaintenance mode + git revert< 2 min rollback

6. Service Level Agreement

MetricaTargetMisurazione
Uptime servizio99.9% (8.7h downtime/anno)Health monitor + log
Recovery da crash< 30 secondiDocker restart + healthcheck
Recovery da aggiornamento< 5 minutiMaintenance mode + deploy
Rilevamento downtime< 5 minutiCron monitor + email alert
Tempo risposta API (p95)< 500msHealth endpoint response time

7. Checklist Operativa

Verifica automatica (quotidiana)

Prima di un aggiornamento manuale

  1. Verificare che non ci siano utenti attivi (o attivare maintenance mode)
  2. Eseguire l'aggiornamento
  3. Verificare tutti i servizi: docker compose ps o pm2 list
  4. Controllare i log per errori