“Questi clienti non hanno dovuto aspettare l’arrivo di una nuova funzionalità per risolvere i problemi di patching. Hanno utilizzato gli strumenti che NinjaOne già mette a disposizione, come scripting, API, campi personalizzati, criteri dinamici, e hanno potuto fare esattamente ciò che il loro ambiente richiedeva. Questa è la forza di una piattaforma progettata per essere estesa: quando hai bisogno di qualcosa di specifico, hai già a disposizione gli elementi per realizzarlo immediatamente, non nel prossimo trimestre.”
Per la maggior parte delle organizzazioni, il patching non è 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à 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.
NinjaOne ha lavorato con clienti enterprise che si sono rifiutati di accettare questo compromesso. Invece di aspettare una richiesta di funzionalità, 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.
Creare uno script per migliorare il patching con NinjaOne
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.
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ù 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.
Questo tipo di logica “giorno di rilascio più 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.
Risolvere i problemi di patching: un patch management semplificato senza costi aggiuntivi
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 è 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.
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.
Oggi, questa azienda ha completamente smantellato la propria infrastruttura di patching legacy. Niente più server dedicati. Niente più 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
Collegamento di un CMDB a NinjaOne in modo che il patching venga eseguito da solo
Una grande azienda enterprise gestisce una flotta di server su più sistemi operativi. Ogni server nel loro ambiente ha una finestra di manutenzione definita nel CMDB. Questa finestra di manutenzione è un record che specifica il tipo di ambiente, il giorno della settimana e la finestra temporale in cui è consentito il patching. Per l’intera flotta di server dell’organizzazione, si tratta di decine di combinazioni uniche di finestre di manutenzione.
Un’ulteriore complicazione è 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ù 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.
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.
NinjaOne ha eliminato tutta questa complessità collegando il CMDB direttamente al motore dei criteri di NinjaOne utilizzando tre livelli di automazione:
- Sincronizzazione automatizzata: Uno script viene eseguito in base a una pianificazione, legge la finestra di manutenzione di ciascun server dal CMDB e scrive i relativi dettagli nei campi personalizzati del dispositivo NinjaOne corrispondente. Quando la finestra di un server cambia nel CMDB, NinjaOne la rileva automaticamente. Nessuno deve riassegnare manualmente i criteri.
- Gestione del calendario: Una volta all’anno, un amministratore inserisce le date di inizio dei cicli di patching di ogni mese nei campi personalizzati di NinjaOne. Uno script giornaliero controlla la data rispetto a questi campi e imposta un singolo valore che determina se la patch procederà o meno. Quando si tratta di una settimana di patch non di produzione, solo i server non di produzione sono idonei. Quando si tratta di una settimana di produzione, solo i server di produzione sono idonei. Quando c’è una pausa o una settimana in cui non si lavora, tutto si ferma. Un valore controlla l’intero ambiente.
- Criteri dinamici con target a livelli: Ogni singola finestra di manutenzione riceve un proprio criterio dinamico. I criteri utilizzano diverse condizioni di targeting, tra cui l’ambiente del dispositivo, il giorno assegnato, l’ora assegnata e lo stato corrente del calendario. Tutti questi elementi devono essere allineati prima che un dispositivo corrisponda. Quando le regole di calendario sono disattivate, nessun dispositivo corrisponde a un criterio. Quando vengono attivate, solo i server giusti vengono selezionati.
Grazie a queste automazioni, l’organizzazione è 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à principale per le finestre di manutenzione e NinjaOne le esegue senza alcun intervento manuale. Ciò che prima richiedeva fogli di calcolo e chiamate di coordinamento ora si gestisce da solo.
Il quadro generale
Nessuno di questi clienti ha chiesto a NinjaOne di creare una nuova funzionalità. Non hanno presentato una richiesta e non hanno aspettato il rilascio. Hanno esaminato gli strumenti che NinjaOne già mette a disposizione, come scripting, API, campi personalizzati, criteri dinamici, e hanno realizzato gli script necessari per il loro ambiente.
Questa è la differenza tra uno strumento e una piattaforma. Uno strumento fa quello per cui è stato progettato. Una piattaforma ti permette di realizzare ciò che ti serve.
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à quando. Oggi.
Per saperne di più, visitate il sito https://www.ninjaone.com/it/gestione-patch/
