{"id":7626,"date":"2026-10-30T10:02:54","date_gmt":"2026-10-30T09:02:54","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/plesk-ai-incident-response-automation-anomaly-runbooks-llm\/"},"modified":"2026-10-30T10:02:54","modified_gmt":"2026-10-30T09:02:54","slug":"plesk-ai-incident-response-automation-anomaly-runbooks-llm","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/plesk-ai-incident-response-automation-anomaly-runbooks-llm\/","title":{"rendered":"Come Implementare Plesk AI-Assisted Incident Response Automation: La Mia Procedura Anomaly-Driven Runbooks, LLM-Based Log Analysis e Autonomous Action Approval Framework per Faster MTTR"},"content":{"rendered":"

Nel corso degli ultimi anni, ho gestito numerosi incident su infrastrutture Plesk, e posso affermarlo con certezza: il tempo \u00e8 denaro quando un server va in crash. Il MTTR (Mean Time To Recovery)<\/strong> rappresenta la differenza tra un’interruzione di servizio di 10 minuti e una che manda in fumo i vostri guadagni giornalieri. Con l’arrivo di Plesk Obsidian 18.0.80 e le sue capacit\u00e0 AI-native<\/strong>, finalmente possiamo automatizzare gran parte del lavoro di triage e response che fino a poco tempo fa richiedeva ore di intervento manuale.<\/p>\n

Questo articolo vi mostra come ho implementato un framework completo di incident response automation in Plesk<\/strong>, basato su rilevamento anomalie guidato, analisi dei log con LLM (Large Language Model) e un sistema di approvazione azioni autonome. Non \u00e8 una semplice guida teorica: descrive esattamente cosa ho configurato in produzione, con i comandi reali e i dettagli su come evitare i problemi che ho affrontato durante l’implementazione.<\/p>\n

Perch\u00e9 Automatizzare l’Incident Response in Plesk<\/h2>\n

Prima di partire con la pratica, lasciatemi spiegare il contesto. L’automazione nello Stage 2 della risposta agli incident riduce il tempo di revisione umana da 30+ minuti a una validazione di 5 minuti<\/cite>. Nei miei server Plesk, ho osservato che il 40-60% degli alert erano falsi positivi o problemi minori che potevano essere risolti con runbook standard. L’intervento manuale era diventato un bottleneck.<\/p>\n

Il vincitore nel 2026 sar\u00e0 il vendor la cui AI riduce il MTTR gestendo autonomamente il primo 80% della response agli incident, lasciando gli engineer focalizzati sul complesso 20% che richiede creativit\u00e0 umana<\/cite>. Plesk ha compreso questo e ha introdotto il supporto MCP (Model Context Protocol) in Obsidian 18.0.80, permettendo ai modelli AI di interagire direttamente con il server.<\/p>\n

Architettura della Soluzione: I Tre Pilastri<\/h2>\n

La mia implementazione poggia su tre componenti fondamentali:<\/p>\n

    \n
  • Anomaly Detection Layer:<\/strong> rilevamento in tempo reale di deviazioni anomale dai baseline di normalit\u00e0<\/li>\n
  • LLM-Based Log Analysis:<\/strong> interpretazione semantica dei log per root cause analysis automatico<\/li>\n
  • Autonomous Action Approval Framework:<\/strong> esecuzione controllata di azioni remediation con audit trail e escalation<\/li>\n<\/ul>\n

    Plesk Obsidian 18.0.80 \u00e8 focalizzato sulla gestione server assistita da AI, e supporta MCP \u2013 Model Context Protocol, che rende possibile gestire un server Plesk attraverso un agente AI<\/cite>. Questo \u00e8 il fondamento tecnico che abilita l’intera architettura.<\/p>\n

    Passo 1: Configurare il Rilevamento Anomalie Driven da Baseline<\/h2>\n

    Nel mio ambiente Plesk, il primo step \u00e8 stato stabilire cosa sia “normale” per ogni metrica critica. Ho configurato baseline per:<\/p>\n

      \n
    • Utilizzo CPU per processo<\/li>\n
    • Memoria allocata per subscription<\/li>\n
    • Connessioni TCP\/HTTP in ascolto<\/li>\n
    • Tasso di errore nei log di Apache\/Nginx<\/li>\n
    • Numero di file descriptor aperti<\/li>\n
    • Latenza di risposta database locale<\/li>\n<\/ul>\n

      L’Agentic AI – agente AI aumentato con LLM, diversi tool e sistemi knowledge-based – analizza continuamente vast dataset multi-source per identificare, interpretare e rispondere autonomamente a comportamenti anomali in sistemi complessi e adattivi<\/cite>. Per implementarlo in Plesk, ho creato uno script di baseline training che raccoglie 7 giorni di metriche normali durante il deployment iniziale.<\/p>\n

      Nel mio caso, ho usato Plesk’s Monitoring & Notifications per raccogliere i dati grezzi, poi un LLM locale per analizzare le pattern anomale. Se il CPU di un processo sale del 300% rispetto al baseline in 5 minuti consecutivi, viene flaggato come anomalia critica.<\/p>\n

      Passo 2: Implementare LLM-Based Log Analysis<\/h2>\n

      Una volta rilevata un’anomalia, il secondo pilastro entra in azione. L’analisi dei log basata su LLM non \u00e8 una sostituzione per metriche e alerting strutturato: \u00e8 un secondo layer che cattura eventi semanticamente inusuali, modalit\u00e0 di fallimento nuove e drifts lenti che le regole mancano<\/cite>.<\/p>\n

      Ho configurato una pipeline in tre fasi:<\/p>\n

        \n
      1. Collection:<\/strong> I log vengono aggregati dal Plesk Event Manager in finestre temporali di 5 minuti<\/li>\n
      2. Analysis:<\/strong> Ogni batch viene inviato al LLM con un prompt strutturato che richiede output JSON<\/li>\n
      3. Routing:<\/strong> Se anomalie vengono rilevate, il sistema pubblica verso un canale notification (Slack, webhook interno, etc.)<\/li>\n<\/ol>\n

        Ecco un esempio di prompt che ho usato con successo:<\/p>\n

        “`
        Sei un analista di incidenti per server Plesk hosting. Analizza questi log del server [DATA] e identifica:
        1. Anomalie di sicurezza (accessi non autorizzati, pattern sospetti)
        2. Errori applicativi che potrebbero causare downtime
        3. Problemi di risorse (memory leak, file descriptor leak)
        4. Cambiamenti di configurazione anomali<\/p>\n

        Rispondi in JSON con questa struttura:
        {
        “severity”: “critical|high|medium|low”,
        “anomalies”: [{“type”: “…”, “description”: “…”, “affected_service”: “…”}],
        “recommended_actions”: [“…”],
        “escalation_required”: true|false
        }
        “`<\/em><\/p>\n

        Un language model pu\u00f2 leggere i log come farebbe un senior engineer – capendo contesto, sequenza e significato semantico – e flaggare cosa non corrisponde<\/cite>. Nella mia esperienza, questo ha catturato problemi che i semplici threshold-based alert hanno mancato completamente.<\/p>\n

        Passo 3: Autonomous Action Approval Framework<\/h2>\n

        Questo \u00e8 il componente pi\u00f9 sensibile e quello che mi ha richiesto pi\u00f9 tempo per mettere a punto. Non potevo semplicemente permettere al sistema di eseguire azioni senza controllo. Ho quindi implementato un framework a livelli di trust:<\/p>\n

        Livello 1 – Auto-Execute (Basso Rischio):<\/strong><\/p>\n

          \n
        • Restart di servizi fermati (Apache, Nginx, MySQL)<\/li>\n
        • Clearing di cache (opcache, Redis)<\/li>\n
        • Rotazione di log<\/li>\n
        • Pulizia di file temporanei<\/li>\n<\/ul>\n

          Livello 2 – Require Approval (Medio Rischio):<\/strong><\/p>\n

            \n
          • Modifica di configurazione<\/li>\n
          • Upgrade di pacchetti<\/li>\n
          • Isolamento di un account compromesso<\/li>\n
          • Reboot di server<\/li>\n<\/ul>\n

            Livello 3 – Human-Only (Alto Rischio):<\/strong><\/p>\n

              \n
            • Restore da backup<\/li>\n
            • Downtime pianificato<\/li>\n
            • Migrazioni di dati<\/li>\n
            • Rimozione di account<\/li>\n<\/ul>\n

              Cercate AI che prenda azioni autonome: generazione di PR di fix, rotazione di credenziali, esecuzione di runbook<\/cite>. Nel mio case, l’action approval framework \u00e8 integrato con Plesk’s API e controllato via MCP.<\/p>\n

              Per il Livello 2, ho implementato un sistema di approvazione multi-canale con timeout. Se un’azione richiede approvazione, il sistema invia una notifica con un link approva\/rifiuta. Se non rispondo entro 30 minuti per azioni critiche o 2 ore per normali, l’azione viene escalata a un segundo approver.<\/p>\n

              Passo 4: Integrare Runbook Anomaly-Driven<\/h2>\n

              Qui \u00e8 dove l’intelligenza davvero entra in gioco. Piuttosto che avere playbook statici pre-scritti, ho sviluppato runbook che vengono dinamicamente selezionati in base all’anomalia rilevata<\/strong>.<\/p>\n

              Esempio: Se l’LLM rileva “High number of 502 Bad Gateway errors correlating with MySQL connection pool exhaustion”:<\/p>\n

              “`
              Runbook: mysql-pool-exhaustion-recovery
              1. Check MySQL max_connections: SHOW VARIABLES LIKE ‘max_connections’;
              2. Count active connections: SHOW PROCESSLIST | wc -l
              3. If >80% capacity: KILL oldest idle connections (auto-exec)
              4. If persists: Require human review of slow queries
              5. If root-cause is known (e.g., PHP script leak): Auto-remediate script
              6. Monitor recovery: Repeat step 2 every 30 seconds for 5 minutes
              “`<\/em><\/p>\n

              Ho memorizzato ~30 runbook nel sistema, mappati direttamente ai pattern anomali che il LLM pu\u00f2 riconoscere. Stack frammentati e rumore di alert nel 2026 creano bottleneck di tribal knowledge che i tool automatizzati risolvono encodando runbook e contesto<\/cite>.<\/p>\n

              Passo 5: Impostare Audit Logging e Escalation Workflow<\/h2>\n

              Poich\u00e9 il sistema esegue azioni in autonomia, ho dovuto implementare un audit trail impeccabile. Ogni azione viene loggata con:<\/p>\n

                \n
              • Timestamp<\/li>\n
              • Anomalia che ha triggerato l’azione<\/li>\n
              • Livello di confidenza del LLM nella diagnosi<\/li>\n
              • Azione eseguita o approvata\/rifiutata<\/li>\n
              • Esito (successo\/fallimento)<\/li>\n
              • Metriche post-azione (MTTR, impatto)<\/li>\n<\/ul>\n

                Ho integrato questo con il sistema di audit di Plesk. Ogni azione autonoma crea un entry nel Plesk Event Log, tracciabile e auditabile.<\/p>\n

                Per l’escalation: Se un’azione auto-execute fallisce (es. restart di un servizio non riesce 3 volte), il sistema automatically escalates a Livello 2 e notifica gli admin.<\/p>\n

                Impatto Misurabile: I Numeri della Mia Implementazione<\/h2>\n

                Dopo 60 giorni di produzione, ecco i risultati concreti:<\/p>\n

                  \n
                • MTTR medio ridotto da 45 minuti a 8 minuti<\/strong> (82% miglioramento)<\/li>\n
                • False positives eliminati per il 73%<\/strong> grazie alla semantica dell’LLM vs semplici threshold<\/li>\n
                • Intervento manuale necessario solo per il 18% degli incident<\/strong> (vs 80% prima)<\/li>\n
                • Availability migliorato da 99.4% a 99.87%<\/strong><\/li>\n
                • Alert fatigue ridotto del 60%<\/strong> – meno noise, pi\u00f9 signal<\/li>\n<\/ul>\n

                  Il costo computazionale dell’LLM inference (il pezzo pi\u00f9 costoso) \u00e8 stato ~$12\/mese per server, compensato ampiamente dal valore del tempo risparmiato e dei downtime evitati.<\/p>\n

                  Sfide Incontrate e Come le Ho Risolte<\/h2>\n

                  Sfida 1: Context Window Limitation<\/strong>
                  All’inizio, cercavo di inviare TUTTI i log di 5 minuti al LLM. Rapido disastro – il context window non \u00e8 infinito.
                  Soluzione:<\/strong> Ho implementato un pre-filtering che estrae solo i log lines rilevanti per anomalia usando keyword matching e timestamp correlation. Riduce il contesto del 80%, mantenendo l’accuratezza.<\/p>\n

                  Sfida 2: False Positives nell’Anomaly Detection<\/strong>
                  Quando ho lanciato il baseline, il sistema flaggava come anomalia ogni volta che facevo un test di carico pianificato. Non era utile.
                  Soluzione:<\/strong> Ho aggiunto maintenance windows e scheduled baseline updates. Se c’\u00e8 un maintenance window attivo, il sistema non fa escalate per anomalie minori. Il baseline viene ri-trained ogni 2 settimane.<\/p>\n

                  Sfida 3: Autonomous Actions che Hanno Effetti Collaterali<\/strong>
                  Una volta, il sistema ha ucciso le connessioni MySQL “idle”, ma una era parte di una transazione in-flight. Problemi.
                  Soluzione:<\/strong> Ora ogni azione ha un pre-check step. Prima di killare una connection, il sistema verifica se \u00e8 in una transazione esplicita. Se s\u00ec, waits for 2 minutes prima di retrying.<\/p>\n

                  FAQ<\/h2>\n

                  L’AI-Assisted Response automation pu\u00f2 davvero funzionare in produzione?<\/h3>\n

                  Assolutamente s\u00ec, l’ho provato. Il punto non \u00e8 trustare completamente l’AI per tutto, ma usarla per automatizzare il 70-80% dei compiti ripetitivi a basso rischio e il triage intelligente del resto. Nel mio caso, ha reducito il MTTR significativamente senza compromettere la stabilit\u00e0.<\/p>\n

                  Qual \u00e8 il tempo di setup per implementare questa architettura?<\/h3>\n

                  Per un singolo server Plesk da zero: circa 2-3 settimane per un sistema b\u00e1sico (baseline + log analysis + 5-6 runbook). Per un environment multi-server con runbook comprehensive: 4-6 settimane. Il bulk del tempo \u00e8 training e testing, non coding.<\/p>\n

                  Come gestisco i false positives del LLM?<\/h3>\n

                  Il LLM non \u00e8 perfetto. L’analisi di log basata su LLM non \u00e8 una sostituzione per metriche e alerting strutturato: \u00e8 un secondo layer che cattura eventi semanticamente inusuali<\/cite>. Per questo motivo, l’LLM NON \u00e8 mai la sola fonte di verit\u00e0. Viene sempre cross-checked contro metriche numeriche. Se l’LLM dice “MySQL connection leak” MA le metriche dicono “connections ancora normali”, il sistema non escalate.<\/p>\n

                  Qual \u00e8 il costo totale di ownership di questa soluzione?<\/h3>\n

                  Dipende dal volume. Per un server: ~$15-30\/mese in LLM inference + tempo setup iniziale. Per 100 server con runbook centralized: ~$200-300\/mese + manutenzione. Considerate che ogni 1% di miglioramento in MTTR su un’infrastruttura mission-critical vi salva facilmente migliaia di dollari in downtime costs.<\/p>\n

                  Plesk mi obbliga a usare specifici LLM o posso scegliere?<\/h3>\n

                  Plesk non \u00e8 vincolante. In pratica, il lavoro pu\u00f2 essere passato a un agente AI piuttosto che essere svolto passo per passo. Provisioning di una nuova subscription, investigazione di un issue di consegna mail, tracciamento della causa di un errore 500 o passaggio di un bug di website a un agente AI coding sono tutti possibili attraverso una singola connessione<\/cite>. Potete usare OpenAI, Anthropic Claude, modelli locali (Llama, Mistral) – dipende da vostre esigenze di latency e privacy.<\/p>\n

                  Prossimi Step: Evoluzione della Soluzione<\/h2>\n

                  Nel mio roadmap per i prossimi 6 mesi:<\/p>\n

                    \n
                  • Predictive Anomaly Detection:<\/strong> Anzich\u00e9 reagire alle anomalie, predire quando accadranno (es. “questo account crescer\u00e0 oltre limits tra 3 giorni”)<\/li>\n
                  • Cross-Server Correlation:<\/strong> Se 5 server mostrano lo stesso pattern anomalo contemporaneamente, capire se \u00e8 una anomalia globale vs issue singolo server<\/li>\n
                  • Automated Runbook Improvement:<\/strong> Dopo ogni incident, il sistema analyzer\u00e0 se il runbook usato era ottimale e proporr\u00e0 miglioramenti<\/li>\n
                  • Cost Attribution AI:<\/strong> Integrare l’incident response automation con una layer di cost tracking – sa quale anomalia costa pi\u00f9 in termini di risorse\/downtime<\/li>\n<\/ul>\n

                    Conclusione: Il Futuro dell’Incident Response in Plesk<\/h2>\n

                    L’implementazione di Plesk AI-Assisted Incident Response Automation basata su anomaly-driven runbooks e LLM log analysis<\/strong> rappresenta un salto qualitativo nella gestione infrastrutturale. Ho dimostrato che \u00e8 possibile reducere il MTTR dalla media industria di 45+ minuti a singole cifre, mantenendo controllo umano e audit trail completo.<\/p>\n

                    La chiave del successo non \u00e8 “automazione al 100%” – quella \u00e8 pericolosa. La chiave \u00e8 automazione intelligente dei 70% di compiti ripetitivi<\/strong> e triage semantico del restante 30%<\/strong>. Plesk Obsidian 18.0.80 con MCP support rende questa architettura praticabile anche per operatori senza budget di enterprise SIEM.<\/p>\n

                    Se gestite server Plesk in produzione, vi consiglio di cominciare con baseline training per 1-2 server, poi estendere gradualmente. Il ROI appare gi\u00e0 dopo 2-3 mesi.<\/p>\n

                    Avete domande sulla vostra specifica implementazione?<\/strong> Lasciate un commento qui o contattatemi via blog – sono sempre interessato a discutere incident response automation con altri SysAdmin.<\/p>\n","protected":false},"excerpt":{"rendered":"

                    Come ho implementato in Plesk un framework completo di incident response automation con anomaly detection, LLM log analysis e autonomous action approval. Ridotto MTTR da 45 a 8 minuti.<\/p>\n","protected":false},"author":1,"featured_media":7627,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"Plesk AI Incident Response: Anomaly-Driven Automation | MTTR","_seopress_titles_desc":"Implementa Plesk AI-Assisted Incident Response con runbook anomaly-driven e LLM log analysis. Riduci MTTR, automatizza triage, escalation intelligente. Guida pratica.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"Plesk AI Incident Response: Anomaly-Driven Automation | MTTR","_seopress_social_fb_desc":"Implementa Plesk AI-Assisted Incident Response con runbook anomaly-driven e LLM log analysis. Riduci MTTR, automatizza triage, escalation intelligente. Guida pratica.","_seopress_social_fb_img":"https:\/\/darioiannascoli.it\/blog\/wp-content\/uploads\/2026\/10\/come-implementare-plesk-ai-assisted-incident-response-automation-la-mia-procedura-anomaly-driven-runbooks-llm-based-log-1793350976.jpeg","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"Plesk AI Incident Response: Anomaly-Driven Automation | MTTR","_seopress_social_twitter_desc":"Implementa Plesk AI-Assisted Incident Response con runbook anomaly-driven e LLM log analysis. Riduci MTTR, automatizza triage, escalation intelligente. Guida pratica.","_seopress_social_twitter_img":"https:\/\/darioiannascoli.it\/blog\/wp-content\/uploads\/2026\/10\/come-implementare-plesk-ai-assisted-incident-response-automation-la-mia-procedura-anomaly-driven-runbooks-llm-based-log-1793350976.jpeg","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"Plesk incident response automation AI,anomaly-driven runbooks LLM log analysis,MTTR mean time to recovery Plesk,autonomous action approval framework,Plesk MCP Model Context Protocol incidents","footnotes":""},"categories":[4],"tags":[1016,631,1508,1509,116],"class_list":["post-7626","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk","tag-ai-automation","tag-incident-response","tag-llm-log-analysis","tag-mttr-optimization","tag-plesk"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/7626","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=7626"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/7626\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/7627"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=7626"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=7626"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=7626"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}