{"id":387,"date":"2026-09-26T19:35:04","date_gmt":"2026-09-26T19:35:04","guid":{"rendered":"https:\/\/wsus.at\/?page_id=387"},"modified":"2026-10-08T09:05:43","modified_gmt":"2026-10-08T09:05:43","slug":"processo-di-aggiornamento","status":"publish","type":"page","link":"https:\/\/wsus.at\/it\/processo-di-aggiornamento\/","title":{"rendered":"Il nostro metodo"},"content":{"rendered":"
Workload & Systems Update Services<\/span>

Pianificare gli aggiornamenti. Verificare le funzioni. Preservare l'operativit\u00e0.<\/h1>

Un aggiornamento \u00e8 concluso quando l'ambiente continua a funzionare. Pianifichiamo patch, upgrade e interventi sul ciclo di vita in base ai sistemi reali, alle dipendenze e ai requisiti operativi.<\/p><\/div><\/section>

Un processo condiviso<\/span>

Nove fasi, dall'inventario alla prossima scadenza del ciclo di vita.<\/h2>

La profondit\u00e0 dei test segue il rischio. Ogni fase ha un risultato, un responsabile e un punto di approvazione definiti. Apri le fasi per i dettagli tecnici.<\/p><\/div>

  1. 01<\/span>

    Censire l'ambiente<\/h3><\/summary>

    Rilevare sistemi operativi, applicazioni, runtime, database, driver, firmware, rete, reverse proxy e container. Includere cluster, componenti di terze parti e software personalizzato. Concordare servizi critici, responsabili e finestre operative.<\/p>

    Risultato:<\/strong> Un inventario verificato con versioni, responsabilit\u00e0 e funzioni critiche.<\/p><\/div><\/details><\/li>

  2. 02<\/span>

    Comprendere le dipendenze<\/h3><\/summary>

    Documentare i collegamenti tra software gestionale, .NET, Java, PHP, Visual C++, ODBC\/OLE DB e database. Considerare TLS, SMB, autenticazione, criteri di sicurezza e reti dei container. Verificare compatibilit\u00e0 del produttore e ordine degli aggiornamenti.<\/p>

    Risultato:<\/strong> Una mappa delle dipendenze che motiva sequenza e test applicativi.<\/p><\/div><\/details><\/li>

  3. 03<\/span>

    Verificare ciclo di vita e percorso del produttore<\/h3><\/summary>

    Confrontare versioni attuale e prevista con supporto, note di rilascio, problemi noti, modifiche incompatibili e funzionalit\u00e0 deprecate. Chiarire versioni intermedie e migrazioni prima della manutenzione. Registrare le scadenze EOL con fonte e data di verifica.<\/p>

    Risultato:<\/strong> Un percorso documentato con passaggi obbligatori e dubbi di compatibilit\u00e0 ancora aperti.<\/p><\/div><\/details><\/li>

  4. 04<\/span>

    Valutare il rischio e classificare l'aggiornamento<\/h3><\/summary>

    Distinguere aggiornamenti ordinari, di sicurezza, funzionali, dei runtime e del firmware da major release e migrazioni del ciclo di vita. Esposizione, criticit\u00e0, impatto, possibilit\u00e0 di test e ripristino determinano priorit\u00e0 e approvazione.<\/p>

    Risultato:<\/strong> Una valutazione tracciabile con criteri di approvazione e arresto.<\/p><\/div><\/details><\/li>

  5. 05<\/span>

    Definire test e progetto pilota<\/h3><\/summary>

    Scegliere staging, VM di test, dispositivi pilota, replica o nodo di cluster adeguato. Verificare attivit\u00e0 aziendali reali, accesso, integrazioni, processi pianificati e carico. Distinguere approvazione tecnica e approvazione delle funzioni aziendali.<\/p>

    Risultato:<\/strong> Casi di test, un pilota limitato e responsabili del collaudo identificati.<\/p><\/div><\/details><\/li>

  6. 06<\/span>

    Preparare rollback e ripristino<\/h3><\/summary>

    Pianificare backup coerenti, prova di ripristino, recupero della configurazione e riavvio dei servizi. Uno snapshot da solo non sostituisce un backup. Le modifiche allo schema possono impedire un semplice downgrade. Definire tempi, perdita di dati accettabile e scelta tra ripristino e correzione in avanti.<\/p>

    Risultato:<\/strong> Un piano di ripristino eseguibile con backup verificato e punti decisionali.<\/p><\/div><\/details><\/li>

  7. 07<\/span>

    Coordinare ed eseguire il rollout<\/h3><\/summary>

    Concordare finestre di manutenzione, gruppi, sequenza, riavvii, comunicazione ed escalation. Approvare il rilascio esteso dopo il pilota. Verificare ogni fase e arrestarsi alle condizioni concordate. Considerare disponibilit\u00e0 del cluster, storage e database.<\/p>

    Risultato:<\/strong> Un rollout graduale con approvazioni documentate e responsabilit\u00e0 chiare.<\/p><\/div><\/details><\/li>

  8. 08<\/span>

    Controllare funzioni e operativit\u00e0<\/h3><\/summary>

    Confrontare servizi, log, monitoraggio, funzioni utente e prestazioni con la situazione iniziale. Testare applicazioni aziendali, integrazioni, processi in background, backup e replica. Il messaggio di installazione riuscita non basta al collaudo.<\/p>

    Risultato:<\/strong> Un collaudo tecnico e funzionale supportato dai risultati dei test.<\/p><\/div><\/details><\/li>

  9. 09<\/span>

    Documentare e proseguire il ciclo di vita<\/h3><\/summary>

    Registrare versioni, eccezioni e rischi residui. Assegnare scadenze EOL, major upgrade, deprecazioni e debito tecnico a un responsabile. Monitorare gli annunci del produttore e programmare le modifiche prima della rimozione delle funzioni.<\/p>

    Risultato:<\/strong> Una documentazione operativa aggiornata e un piano prioritario per il ciclo successivo.<\/p><\/div><\/details><\/li><\/ol><\/div><\/section>

    Test e approvazione<\/span>

    Aggiornamenti diversi richiedono approvazioni diverse.<\/h2>

    Valutare insieme rischio di sicurezza e rischio operativo. L'automazione \u00e8 utile quando limiti, test e ripristino sono definiti.<\/p><\/div>

    Strategia esemplificativa: la decisione concreta dipende dall'ambiente.<\/caption>
    Categoria<\/th>Approccio<\/th>Approvazione<\/th><\/tr><\/thead>
    Ordinario \/ basso rischio<\/td>Rilascio tempestivo o automatizzato secondo regole definite<\/td>Pilota, monitoraggio ed eccezioni documentate<\/td><\/tr>
    Sicurezza \/ vulnerabilit\u00e0 critica<\/td>Valutare esposizione, priorit\u00e0 e manutenzione urgente se necessaria<\/td>Decisione responsabile con test mirato e ripristino<\/td><\/tr>
    Major \/ runtime \/ firmware<\/td>Verificare separatamente percorso, dipendenze e migrazione di test<\/td>Approvazione tecnica e funzionale prima del rollout esteso<\/td><\/tr>
    EOL \/ deprecazione<\/td>Testare l'alternativa e pianificare migrazione e dismissione<\/td>Collaudo prima della fine del supporto o della rimozione<\/td><\/tr><\/tbody><\/table><\/div>

    Nessuna attesa universale per le major release e nessuna approvazione immediata sistematica delle patch di sicurezza: impatto, superficie d'attacco e ripristinabilit\u00e0 determinano il percorso.<\/p><\/div><\/section>

    Esempi tecnici<\/span>

    Le dipendenze determinano i test.<\/h2>

    Questi scenari illustrano il metodo. Versioni e percorsi del produttore vengono verificati nuovamente per ogni progetto.<\/p><\/div>

    Windows e software gestionale<\/h3>

    Dopo una patch verifichiamo Windows insieme all'applicazione aziendale, ai runtime Visual C++ o .NET, ai driver ODBC\/OLE DB, a TLS e all'accesso. Il test segue un'attivit\u00e0 reale: autenticazione, consultazione dei dati e stampa.<\/p><\/article>

    Linux e stack web<\/h3>

    Un upgrade PHP richiede un piano comune per estensioni, dipendenze Composer, server web, reverse proxy, driver del database, cron e servizi in background. Prima staging, poi collaudo funzionale e passaggio in produzione.<\/p><\/article>

    OPNsense e ciclo di vita<\/h3>

    Aggiornamenti minori e major upgrade ricevono valutazioni differenti. Esaminare per tempo note di rilascio, regole, DHCP, VPN e funzioni rimosse. Osservare e testare i nuovi meccanismi, preparando la migrazione prima che i precedenti scompaiano.<\/p><\/article><\/div><\/div><\/section>

    Responsabilit\u00e0 chiare<\/span>

    Chi testa, chi approva, chi verifica l'operativit\u00e0.<\/h2>

    Con il tuo team definiamo esecuzione tecnica, test aziendali, autorit\u00e0 di approvazione ed escalation. Un test fallito sospende la fase successiva fino alla decisione sul ripristino o sulla correzione concordata.<\/p>

    La tua piattaforma non \u00e8 nell'elenco? Analizziamo percorsi del produttore e requisiti operativi per sviluppare un piano individuale. I progetti di infrastruttura o migrazione pi\u00f9 ampi sono coordinati con i servizi DAXS.<\/p><\/div><\/div><\/section>

    Il primo passo<\/span>

    Iniziamo con un pilota gestibile.<\/h2>

    Descrivi i sistemi, il problema e il risultato desiderato. Definiamo insieme il primo test e la relativa approvazione.<\/p><\/div>Parliamo del tuo progetto<\/a><\/div><\/section><\/main><\/div><\/div><\/div><\/div><\/div>","protected":false},"excerpt":{"rendered":"","protected":false},"author":2,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-387","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/wsus.at\/it\/wp-json\/wp\/v2\/pages\/387","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wsus.at\/it\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/wsus.at\/it\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/wsus.at\/it\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/wsus.at\/it\/wp-json\/wp\/v2\/comments?post=387"}],"version-history":[{"count":3,"href":"https:\/\/wsus.at\/it\/wp-json\/wp\/v2\/pages\/387\/revisions"}],"predecessor-version":[{"id":482,"href":"https:\/\/wsus.at\/it\/wp-json\/wp\/v2\/pages\/387\/revisions\/482"}],"wp:attachment":[{"href":"https:\/\/wsus.at\/it\/wp-json\/wp\/v2\/media?parent=387"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}