“Questi clienti non hanno dovuto aspettare l\u2019arrivo di una nuova funzionalit\u00e0 per risolvere i problemi di patching. Hanno utilizzato gli strumenti che NinjaOne gi\u00e0 mette a disposizione, come scripting, API, campi personalizzati, criteri dinamici, e hanno potuto fare esattamente ci\u00f2 che il loro ambiente richiedeva. Questa \u00e8 la forza di una piattaforma progettata per essere estesa: quando hai bisogno di qualcosa di specifico, hai gi\u00e0 a disposizione gli elementi per realizzarlo immediatamente, non nel prossimo trimestre.”<\/p>\n
Per la maggior parte delle organizzazioni, il patching non \u00e8 un processo semplice. Hanno comitati consultivi per le modifiche, rollout graduali, finestre di manutenzione guidate dal CMDB, periodi di pausa annuali e calendari di conformit\u00e0 che rendono i Patch Tuesday tristemente inadeguati. Quando i loro strumenti non riescono a tenere il passo, i team IT finiscono per collegare i fogli di calcolo ai processi manuali e sperare che nulla vada perso.<\/p>\n
NinjaOne ha lavorato con clienti enterprise che si sono rifiutati di accettare questo compromesso. Invece di aspettare una richiesta di funzionalit\u00e0, hanno utilizzato il motore di scripting, l’API, i campi personalizzati e i criteri dinamici di NinjaOne per creare esattamente i flussi di lavoro di patching di cui avevano bisogno. Ecco due di queste storie.<\/p>\n
Una grande azienda enterprise ha utilizzato per anni una piattaforma legacy per la gestione della configurazione. Funzionava, ma il costo dell’infrastruttura era enorme con server dedicati, punti di distribuzione, backend di database e dipendenze VPN per i dispositivi remoti.<\/p>\n
L’azienda voleva passare a NinjaOne, ma pensava che il suo processo di patching potesse rappresentare un ostacolo insormontabile all’adozione. Avevano progettato un modello di rollout graduale in cui le patch venivano distribuite all’interno dell’organizzazione in pi\u00f9 fasi. Il processo sarebbe iniziato con un piccolo gruppo di prova, per poi espandersi agli early adopters, in seguito agli uffici aziendali e infine, settimane dopo, alle sedi sul campo. Ogni fase aveva un ritardo specifico legato ai tempi di rilascio delle patch da parte di Microsoft, e in alcune fasi e installazioni potevano avvenire solo durante le finestre di manutenzione notturna per evitare di interrompere le operazioni.<\/p>\n
Questo tipo di logica “giorno di rilascio pi\u00f9 N giorni” non esiste in modo nativo nella maggior parte degli strumenti di gestione degli endpoint. Non esisteva nemmeno nelle ultime tre piattaforme valutate prima di NinjaOne.<\/p>\n
Utilizzando il motore di scripting NinjaOne, il cliente ha creato uno script di gating che viene eseguito automaticamente prima di ogni ciclo di patch. Esegue il calcolo della data, determina l’ancora di rilascio del mese corrente, aggiunge il ritardo appropriato per la fase del dispositivo e decide se oggi \u00e8 il giorno giusto. In caso affermativo, il patching procede. In caso contrario, lo script indica a NinjaOne di saltare il ciclo e di riprovare la volta successiva.<\/p>\n
Lo script ha semplificato la gestione quotidiana delle patch da parte del team. Gli amministratori non devono toccare alcun codice. Devono semplicemente scegliere la fase di distribuzione da un menu a tendina in NinjaOne e lo script gestisce il resto. Se l’organizzazione decide di regolare il ritardo per un particolare gruppo, deve modificare solo un valore del menu a tendina. Tutto qui.<\/p>\n
Oggi, questa azienda ha completamente smantellato la propria infrastruttura di patching legacy. Niente pi\u00f9 server dedicati. Niente pi\u00f9 requisiti VPN per i portatili remoti. L’intero ambiente riceve le patch direttamente dal fornitore via Internet e continua a seguire la stessa disciplina di rollout graduale su cui ha sempre fatto affidamento, ma senza tutto il lavoro manuale e le spese di gestione associati<\/p>\n
Una grande azienda enterprise gestisce una flotta di server su pi\u00f9 sistemi operativi. Ogni server nel loro ambiente ha una finestra di manutenzione definita nel CMDB. Questa finestra di manutenzione \u00e8 un record che specifica il tipo di ambiente, il giorno della settimana e la finestra temporale in cui \u00e8 consentito il patching. Per l’intera flotta di server dell’organizzazione, si tratta di decine di combinazioni uniche di finestre di manutenzione.<\/p>\n
Un’ulteriore complicazione \u00e8 rappresentata dal fatto che il calendario del patching non si basa su schemi ricorrenti. Ogni mese, in date specifiche, vengono applicate le patch, pianificate con un anno di anticipo. Inoltre, durante la stagione pi\u00f9 impegnativa, viene applicato un periodo di pausa in cui nessuna patch arriva in produzione. I singoli server hanno ognuno le proprie regole: alcuni non possono essere riavviati durante il patching, altri possono essere riavviati solo senza patch e altri ancora richiedono un intervento manuale completo.<\/p>\n
Prima di NinjaOne, il team IT gestiva tutto questo manualmente. I fogli di calcolo tenevano traccia di quali server erano stati patchati in quale momento. Le conoscenze tribali dovevano colmare le lacune di processo, ma non sempre ci riuscivano. Alcuni dispositivi venivano quindi dimenticati. Alcune patch mancate.<\/p>\n
NinjaOne ha eliminato tutta questa complessit\u00e0 collegando il CMDB direttamente al motore dei criteri di NinjaOne utilizzando tre livelli di automazione:<\/p>\n
Grazie a queste automazioni, l’organizzazione \u00e8 in grado di applicare le patch all’intero parco server alla data corretta, all’ora corretta e nell’ordine corretto, in modo automatico. Il CMDB rimane l’autorit\u00e0 principale per le finestre di manutenzione e NinjaOne le esegue senza alcun intervento manuale. Ci\u00f2 che prima richiedeva fogli di calcolo e chiamate di coordinamento ora si gestisce da solo.<\/p>\n
Nessuno di questi clienti ha chiesto a NinjaOne di creare una nuova funzionalit\u00e0. Non hanno presentato una richiesta e non hanno aspettato il rilascio. Hanno esaminato gli strumenti che NinjaOne gi\u00e0 mette a disposizione, come scripting, API, campi personalizzati, criteri dinamici, e hanno realizzato gli script necessari per il loro ambiente.<\/p>\n
Questa \u00e8 la differenza tra uno strumento e una piattaforma. Uno strumento fa quello per cui \u00e8 stato progettato. Una piattaforma ti permette di realizzare ci\u00f2 che ti serve.<\/p>\n
Per i team IT enterprise che hanno a che fare con calendari di patching complessi, integrazioni CMDB, rollout graduali e vincoli operativi che non si adattano perfettamente a un menu a tendina, NinjaOne offre gli elementi costitutivi per farli funzionare. Non in futuro, chiss\u00e0 quando. Oggi.<\/p>\n