Definizione di job scheduling

Solutions for Automating
IT Job Scheduling
Soluzioni per l'automazione
del job scheduling
ORSYP Italia
Sommario
Capitolo 1: Perché dotarsi di una soluzione di job scheduling - Dieci domande da porsi
Cosa comporta avere infrastrutture IT eterogenee
Criticità di un sistema complicato
Definizione di job scheduling
Dieci domande da porsi
Capitolo 2: Sette casi d'uso di job scheduling
Sette storie di job scheduling
Sette storie, sette esempi di valore aggiunto del job scheduling
Capitolo 3: Analizziamo nel dettaglio un flusso di processi IT
Un flusso di lavoro è un'attività IT
Flussi di job e pianificazione dei processi
Librerie di job e valore aggiunto dei trigger
Capitolo 4: Enterprise job scheduling: una lista di requisiti da controllare
Creazione dei requisiti specifici per il job scheduling
Vincere nel mercato globale: il job scheduling alla base del successo
© ORSYP 2012 ▪
2 / 40
Capitolo 1: Perché dotarsi di una
soluzione di job scheduling - Dieci
domande da porsi
Ricordo ancora il giorno in cui il mio capo mi chiamò nel suo ufficio e mi convinse ad
intraprendere un nuovo progetto, il progetto che cambia ogni cosa. Disse: "Tu sei il mago
degli script, saprai farlo funzionare ". Accettai la sfida e il resto è storia.
La maggior parte dei grandi progetti nel settore IT inizia in questo modo, per cui forse
conoscete già storie simili. Si tratta di progetti che sembrano validi sulla carta, ma poi
diventano difficili e complessi quando si cerca di realizzarli, a causa della presenza di
diverse applicazioni e piattaforme che richiedono tempo e risorse per integrarsi tra loro.
Questa storia però non riguarda solo ciò che mi fu affidato quel giorno. Parla anche di
tutte le piccole automazioni che vanno a comporre nel corso del tempo ogni infrastruttura
informatica, come gli script per Windows, Oracle, Active Directory (AD), SQL, processi di
sistema e così via. Sono automazioni in grado di risolvere esigenze immediate di
business, ma che senza una gestione centralizzata rappresentano anche un centro di
costo; un costo che aumenta quando la tecnologia diventa ormai obsoleta o gli
sviluppatori lasciano l'azienda e si trasferiscono altrove.
Allora ero stato riconosciuto come il “mago degli script”. Se aveste avuto bisogno di
elaborare velocemente i dati, o di trasferire i file da un sistema all'altro, sarei stato la
persona giusta da contattare. Avevo una perfetta padronanza del linguaggio di
programmazione più importante del momento, e di tanti altri componenti aggiuntivi.
Questo mi rendeva appunto il “mago” cui si era rivolto il mio capo. Avevo acquisito
esperienza e abilità nel corso degli anni, ampliando la mia sfera di competenza fino ad
includere tecnologie specifiche per piattaforme e applicazioni come WMI, ADSI, SQL, poi
Oracle, Linux e IBM AIX.
Per realizzare il progetto che mi era stato chiesto, ho messo in campo tutta la
conoscenza del mestiere di cui disponevo. Nel corso degli anni avevo automatizzato gran
parte delle mie attività. Certo, non sempre ogni cosa funzionava alla perfezione. A volte
le automazioni venivano accidentalmente cancellate durante l'aggiornamento del
datacenter, o non erano più necessarie e andavano riconfigurate.
In altre parole, il meccanismo dell'automazione poteva essere migliorato. Infine, è venuto
il giorno in cui ho cambiato lavoro, e quello è stato il problema maggiore per il sistema di
automazione. Infatti, avevo sviluppato diversi script distribuiti in tutta l'azienda, senza
alcun sistema centrale che li gestisse in modo unitario. Potevano perfino verificarsi
criticità nei processi, senza che nessuno se ne accorgesse e potesse intervenire...
© ORSYP 2012 ▪
3 / 40
Mancava qualcosa, questo era certo, e precisamente ciò che chiamiamo “job
scheduling”, o meglio l'automazione del job scheduling. Lo scopo di questo documento è
spiegare il significato della schedulazione delle elaborazioni e restituire il valore che essa
può offrire in un contesto aziendale. Nelle pagine che seguono intendo illustrare più in
dettaglio il grande progetto che il mio capo decise di affidarmi quel giorno di cui ho
parlato all'inizio, fornendo alcuni esempi che chiariscono ulteriormente perché il “job
scheduling” e l'automazione sono davvero centrali per il business di un'azienda.
Cosa comporta avere infrastrutture IT eterogenee
Questo documento non esisterebbe se ogni tecnologia IT comunicasse perfettamente
con le altre, se il trasferimento dei dati, il controllo degli eventi e i comandi su piattaforme
e applicazioni fossero perfettamente integrati tra loro o con sistemi diversi.
La schedulazione delle elaborazioni aziendali (o “job scheduling”) è un'esigenza comune
a tutte le imprese, trasversale ai settori di business e alle dimensioni delle imprese. I “job”
del job scheduling sono gli script di automazione. Alcuni funzionano con una sola
applicazione, altri invece integrano servizi su più sistemi per creare un workload “misto”,
in grado di soddisfare quelle che normalmente sono le esigenze aziendali immediate in
un contesto cross-platform e cross-application.
Tra i casi più comuni di job vi sono:
 Report sulle attività di utilizzo della posta elettronica, che devono essere resi
disponibili a chi si occupa di sicurezza
 File trasferiti dai client in ingresso, per esempio ad un server FTP Linux, e che
devono essere inseriti immediatamente in un database SQL
 Applicazioni di posta elettronica e database per semplificare l'utilizzo di sistemi
specifici
 Nuovi record, ad esempio in un database Microsoft SQL o Oracle che innescano
azioni in uno o più sistemi middleware
Queste elaborazioni potrebbero essere più semplici e sicure se vi fosse un solo sistema o
una sola applicazione di riferimento, in grado di gestire le diverse fasi di monitoraggio e
verifica dei job.
La complessità degli ambienti IT è dovuta anche al proliferare di differenti tecnologie che
vi risiedono. Tali differenze rappresentano un problema all'interno dei datacenter di oggi.
La vostra infrastruttura IT ha sicuramente sistemi Windows, ma forse anche Oracle, HPUX, Solaris e altri.
È probabile che sia necessario trasferire documenti XML, file DOCX, XLSX e fogli di
calcolo su protocolli multipli come SMB, FTP e SSH. Anche i vostri sistemi di controllo e
monitoraggio sono probabilmente disponibili su diverse tecnologie: SNMP per switch e
router, WMI per i sistemi Windows, e tutti i vari widget UNIX e Linux per tenere sotto
controllo le attività.
© ORSYP 2012 ▪
4 / 40
Si possono immaginare alcune criticità che potrebbero sorgere in seguito alle differenze
tra applicazioni e piattaforme negli ambienti ibridi di oggi:
 Ogni sistema operativo (OS) possiede un linguaggio diverso dagli altri, e lo stesso
vale per le applicazioni
 Ciascuno di questi elementi utilizza il proprio modello di sicurezza, che non si
integra con quello degli altri
 Il trasferimento dei dati o le pianificazioni all'interno e tra i vari ambienti a volte
risulta difficile, se non impossibile con gli strumenti nativi
 Soprattutto, con gli strumenti nativi non è possibile gestire in modo centralizzato
tutti i job
La funzione principale di una soluzione di job scheduling è risolvere questi cinque
problemi. Un unico pannello di controllo centrale permette di avere visibilità su tutte le
elaborazioni del sistema, creando una singola piattaforma per l'automazione. Questo
evita che singoli script per eseguire i job vengano distribuiti su sistemi differenti.
Utilizzando una soluzione centralizzata è possibile controllare e armonizzare, ad
esempio, le elaborazioni su database con job di sistema UNIX/Linux e job FTP.
Le esecuzioni sono avviate dallo stesso punto, e tutti i sistemi sono gestiti e monitorati da
un’unica postazione.
Job scheduling per centralizzare job su qualsiasi piattaforma e applicazione
Una soluzione di automazione di job scheduling deve essere eccezionalmente completa.
Non basta che supporti la gestione, il monitoraggio e il flusso delle elaborazioni. Deve
anche implementare le integrazioni con i diversi sistemi operativi, le piattaforme e le
tecnologie incorporate dai processi aziendali. Per questo, trovare la giusta soluzione è
importante e al tempo stesso impegnativo.
Si può considerare questo documento come una “fabbrica di idee per l'automazione”. Nel
prosieguo di questo lavoro verranno proposte alcune domande di auto-valutazione, che vi
aiuteranno a capire meglio le esigenze a cui una soluzione di job scheduling risponde.
Vedremo una serie di casi reali di utilizzo e potremo analizzare il meccanismo di un job
informatico, in modo da comprendere appieno la potenza di una soluzione centralizzata.
Questo documento si conclude con una lista di requisiti da prendere in considerazione
nella scelta del software adatto a soddisfare le necessità aziendali.
Cercherò di essere la vostra guida, e durante il viaggio che stiamo per iniziare
condividerò alcune delle mie storie per dimostrare con esperienze reali la validità di
quello che sosterrò.
Nota:
© ORSYP 2012 ▪
5 / 40
Nel presente documento utilizzerò il termine “job scheduling”. Un altro termine
comunemente impiegato per indicare la pianificazione dei processi è “automazione del
carico di job”. Ai fini di questo lavoro, si possono intendere i due come equivalenti.
Criticità di un sistema complicato
Torniamo ora alla mia storia di tanto tempo fa. Ogni applicazione e ogni sistema
operativo sono in grado di eseguire le rispettive funzioni in diversi modi; ad esempio, un
sistema operativo può includere uno o più linguaggi per scrivere e leggere i dati, così
come ogni database moderno è dotato di funzioni di automazione e pianificazione per
l'inserimento o la selezione dei dati. Anche le tecnologie middleware e varie applicazioni
sono dotate di API proprietarie, che possono essere utilizzate come interfaccia all'esterno
dell'applicazione.
Tuttavia, queste funzionalità, insieme alle automazioni già presenti nei prodotti,
raramente sono in grado di gestire le interazioni al di fuori dei prodotti stessi. Avete mai
provato ad utilizzare un documento XML per indicare ad un server SQL che deve
aggiornare una riga di database Oracle, in modo che un'applicazione SAP possa
eseguire il controllo di un processo su un server AIX? Tutto questo assomiglia alla
situazione in cui mi sono trovato all'inizio del progetto che mi aveva affidato il mio capo.
Il motivo per il quale quel progetto era necessario, in fondo non conta molto. L'importante
è invece sapere che il nostro sistema era costituito da una miriade di elementi disparati,
con diverse applicazioni in esecuzione all'interno del sistema operativo, e con database
anch'essi diversi, alimentati da dati provenienti sia dall'interno che dall'esterno della
compagnia. E tutto questo era solo l'inizio...
Per cominciare, ho cercato lo schema dei componenti del sistema. Ad un livello alto, esso
era stato costruito per aggregare dati esterni all'azienda con dati provenienti dall'interno.
Il nostro problema era che i dati dovevano essere trasferiti in molti luoghi diversi...
Com'era gestito il flusso di dati nel sistema dell'azienda dove lavoravo
Il flusso di dati nel sistema della mia azienda veniva gestito tramite FTP da una sorgente
esterna. Questi dati e tutti i metadati relativi dovevano essere depositati in un unico
database centralizzato SQL. Alcuni erano disponibili in base ai profili di utenza, mentre
non si poteva avere accesso ad altri. Le informazioni contenute all'interno del flusso di
dati FTP erano utili ad identificare chi poteva avere accesso a cosa.
Gli utenti erano in grado di interagire con i dati tramite un server Microsoft IIS che
eseguiva un'applicazione Web realizzata internamente. Tale applicazione utilizzava il
formato XML per trasferire dati da e verso il database SQL. A volte, i dati venivano
elaborati da un server UNIX, che effettuava il consolidamento con le informazioni
provenienti da altre sorgenti o da aree aziendali diverse. Un server di posta garantiva
© ORSYP 2012 ▪
6 / 40
l'inoltro di notifiche agli utenti sugli aggiornamenti, lo stato dei set di nuovi dati o altri
eventi.
Vi erano quindi di numerose correlazioni, con le relative integrazioni che andavano
gestite in modo adeguato per garantire il funzionamento di tutto il sistema. I processi
dovevano essere avviati in sequenza, armonizzando per esempio le elaborazioni sui
server e sui database. In una situazione del genere, risultava complesso e impegnativo
anche solo pianificare le integrazioni di ogni correlazione di job.
Vi sembra per caso di vedere qualcosa di simile anche nel vostro datacenter?
Potrebbero esserci situazioni analoghe se si elaborano o si trasferiscono grandi volumi di
dati all'interno dell'azienda. È bene quindi valutare i seguenti quattro punti critici:




Sistemi interconnessi come questo esistono ovunque, in qualsiasi compagnia.
Altri hanno quindi già avuto a che fare con gli stessi problemi d'integrazione in
diversi contesti, ed è consigliabile trarre vantaggio dalla loro esperienza.
Costruire e gestire un sistema simile non è necessariamente un'attività per soli
sviluppatori. Io stesso non lo sono. Il mio ruolo è quello di amministratore di
sistema, cui è capitato di essere considerato “Il mago del computer”, e perciò il
candidato ideale cui affidare questo progetto. Gli amministratori devono costruire
sistemi composti da molte parti, in grado di “parlarsi” tra loro. Programmare le
attività è solo il primo passo di questo cammino.
È possibile realizzare un sistema completo e funzionale utilizzando gli strumenti di
automazione specifici di ogni singolo componente, ma questa non è una buona
idea. Le mie elaborazioni producevano VBScript e cron job, file SSIS-SQL e ciò
non è mai stato utile ai fini della gestione complessiva; al contrario, ha solo creato
confusione e problemi. La programmazione delle attività è efficace a lungo
termine solo se centralizzata, e la manutenzione delle automazioni è più semplice
e sicura se le attività sono ridotte di numero.
Azioni semplici all'interno di sistemi semplici possono funzionare bene con
null'altro che ora e data di pianificazione. Ma sistemi più complessi o che
presentano più dipendenze hanno bisogno di mezzi potenti per determinare
quando fare qualcosa. Queste decisioni possono essere prese in base alla
ricezione di dati o a modifiche nel database, alla lettura di file log o ad un altro
evento che può verificarsi nel sistema. Una buona soluzione di job scheduling
offrirà diverse condizioni personalizzabili per definire quando un'azione dev'essere
eseguita.
L'insieme di questi quattro elementi mi suggerì di guardare a soluzioni per la
pianificazione delle attività attraverso tutte le piattaforme e tutte le applicazioni. È stato
allora che ho iniziato a cercare soluzioni di pianificazione dei processi IT.
© ORSYP 2012 ▪
7 / 40
Definizione di job scheduling
Facciamo ora un passo indietro, e riflettiamo sul significato di “job scheduling”. Ho
cercato di spiegare che un “job” è una sorta di automazione, che si verifica all'interno di
un'infrastruttura IT. Una definizione più tecnica è che esso rappresenta l'azione da
compiere: potrebbe essere l'esecuzione di un file batch o di uno script, di un comando
“shell”, di un processo su un database, o l'elaborazione di una serie di dati. In sostanza,
tutto ciò che produce un cambiamento in un sistema è collegato a un'entità che
chiameremo “job”.
Nell'utilizzare un approccio informatico orientato agli oggetti, è opportuno consolidare le
singole azioni in job separati. Questo approccio singola-azione-per-job garantisce che i
processi siano riutilizzabili altrove e per altri scopi. In sostanza, che sia possibile creare
un processo chiamato ad esempio "Connessione al database Oracle", ed utilizzare quel
job ogni volta che si ha bisogno di fare una connessione al database Oracle.
Se ogni job compie una semplice azione, è possibile unire più job per completare un
processo. Chiameremo questo processo “IT plan”, ovvero una pianificazione che
rappresenta una serie di job correlati, i quali possono essere eseguiti per raggiungere
l'obiettivo voluto: l'effettuazione di modifiche strutturali all'interno di un sistema.
Creare dei buoni job è quasi un'arte, perché essi non devono necessariamente contenere
informazioni specifiche memorizzate all'interno dello script, come il nome del server o la
cartella a cui si fa riferimento. Un approccio migliore è quello di utilizzare una variabile.
Gli sviluppatori utilizzano la parametrizzazione per generalizzare gli oggetti contenuti nei
job, e questi parametri vengono successivamente applicati in fase di esecuzione.
Scegliere i parametri giusti rende possibile collegare diversi job generici. Nel momento in
cui viene eseguito l'“IT plan” frutto di tale collegamento, vengono inoltrate ai job le
informazioni sulle variabili di cui hanno bisogno, ad esempio per la connessione al
database, al fine di estrarre da esso i dati corretti e trasferire altrove i file in formato FTP.
Riutilizzazione e pianificazione dei job
Tramite la parametrizzazione dinamica della pianificazione, si rendono riusabili tutti i
processi. Ad esempio: occorre cambiare il database a cui connettersi, o estrarre un
gruppo di dati diverso, o ancora inviare questi dati ad un altro server FTP? È possibile
fare tutto ciò semplicemente modificando le informazioni contenute nelle variabili. Questo
è quanto si definisce riusabilità.
Si potrebbe parlare molto più a lungo di job e pianificazioni. Nel Capitolo 3, cercheremo di
capire meglio le varie caratteristiche che può avere un job, e approfondiremo la
conoscenza degli altri oggetti che vengono impiegati in una tipica soluzione di “job
scheduling”.
© ORSYP 2012 ▪
8 / 40
Prima di proseguire, vi è però un aspetto che merita maggiore attenzione: quello della
schedulazione. Essa definisce quando un job deve essere eseguito. La schedulazione
dei sistemi richiede una certa flessibilità. Non può essere legata strettamente ad un
tempo determinato in cui avviare l'elaborazione. Piuttosto, i job sono legati ad eventi o
cambiamenti di stato che si verificano all'interno dell’infrastruttura informatica.
Supponiamo di dover trasferire dati da SQL Server ad un server UNIX. Potrebbero
essere definite tre diverse schedulazioni dell'IT plan che abbiamo elaborato per realizzare
il processo:
 Eseguire il trasferimento alle 3:00 PM
 Eseguire il trasferimento quando arrivano nuovi dati
 Eseguire il trasferimento quando l’utilizzo del processore è inferiore al 30%
Uno qualsiasi di questi tre tipi di schedulazione può essere adeguato, dipende dalle
esigenze. Il primo soddisferebbe le richieste di una “raccolta dati giornaliera”. In questo
caso, la schedulazione con data/ora sarebbe adatta allo scopo e molto semplice.
Nel secondo caso, il processo si attiva solo quando vengono ricevuti nuovi dati. Questa
soluzione è interessante quando si vogliono mantenere i database sincronizzati tra loro,
in particolare se si considera la difficoltà di ottenere un risultato simile nel caso venissero
utilizzati unicamente il SQL nativo e gli strumenti del sistema UNIX.
La terza soluzione è ingegnosa perché potrebbe venire impiegata sia da sola, sia in
combinazione con il secondo caso appena visto. Le elaborazioni si attivano solo se il
server non è molto utilizzato. Combinato con la seconda modalità, ciò permette di
mantenere la sincronizzazione tra i componenti del sistema senza però sovraccaricare il
server. Una buona soluzione di job scheduling include una vasta gamma di condizioni
applicabili alle pianificazioni dei job, in modo che le elaborazioni vengano avviate quando
e come previsto, in base alle necessità aziendali.
Dieci domande da porsi
Avremo nuovamente occasione di immergerci nel funzionamento dei componenti di un
flusso di job nel capitolo 3.
Ma prima di poter veramente apprezzare la potenza di questo approccio modulare, forse
è il caso di rispondere ad alcune domande che vi starete probabilmente ponendo. E se
non lo state facendo, lasciate che io stesso vi aiuti con un elenco di dieci quesiti che
ognuno dovrebbe porsi sulla propria infrastruttura IT.
I. Quanto tempo
manualmente?
© ORSYP 2012 ▪
avete
perso
per
completare
i
processi
9 / 40
Non molti anni fa, tra i miei compiti vi era l'aggiornamento di una serie di server. Questa
attività era mensile e obbligatoria, e richiedeva di essere svolta in modo sempre più
rapido. Ogni aggiornamento andava eseguito in una finestra temporale molto breve. Il
problema era che questi aggiornamenti richiedevano un riavvio del server per diventare
effettivi.
All'epoca la nostra finestra di riavvio era configurata nelle prime ore del mattino.
Effettuare un giro di aggiornamenti una volta al mese comportava alcuni disagi. Per
questo avevo creato uno script di automazione che includesse l'installazione degli
aggiornamenti. La soluzione prevedeva che essi fossero implementati a partire dalla data
valida successiva. Nel caso si fossero verificati problemi, avrei ricevuto notifiche tramite
messaggi sul cellulare.
In tal modo, gli aggiornamenti erano diventati più semplici da gestire. L'unica cosa a cui
dovevo stare attento era di avere sempre il cellulare a portata di mano per essere
informato su eventuali criticità. A volta capitava che qualcosa andasse storto, ma spesso
era risolvibile con un sessione di controllo remoto. Gli aggiornamenti eseguiti con
successo mi permettevano di non perdere tempo - né sonno durante la notte.
A prescindere dal mio caso specifico, ciò che conta è il risparmio di tempo e denaro. I
computer sono stati progettati per essere macchine automatiche, e ogni attività manuale
andrebbe essa stessa ottimizzata attraverso l'automazione. Ci si può permettere il lusso
di errori umani nelle attività critiche di un'azienda? Se la risposta è negativa, allora la
soluzione può davvero risiedere nella creazione di flussi di job flessibili e riutilizzabili,
attraverso un sistema di job scheduling adatto alle esigenze specifiche di un'impresa.
II. Qual è il costo degli errori che si commettono durante un
processo manuale?
Questa domanda introduce alle principali categorie di rischio presenti in qualsiasi sistema
manuale.
La prima categoria è quella delle esecuzioni inappropriate. Ogni compito che richieda un
intervento manuale implica il rischio che potrebbe venire eseguito in un momento
inopportuno. O peggio, che tale compito possa essere ri-parametrizzato inviando i dati
dove non devono essere inviati, o eseguito in modo improprio. Simili errori comportano
un costo.
Ricordo ad esempio una situazione in cui era stato creato uno script che si applicava ad
una serie di dati all'interno di un server specifico al momento dell'esecuzione. Lo script
aveva come parametro un elenco di server a cui inviare i dati. Un giorno, un
amministratore non molto esperto eseguì accidentalmente lo script con il carattere jolly "*"
al posto di un elenco specifico di server. Come risultato, i dati furono distribuiti a tutti i
server dell'azienda. Quella singola operazione ha creato un danno economico alla
società, comportando alcuni costi per cancellare i dati inviati.
© ORSYP 2012 ▪
10 / 40
Oltre alle esecuzioni inappropriate, tra gli altri rischi che possono essere indirizzati da una
soluzione di job scheduling vi sono ad esempio dimenticanze ed errori umani di vario
tipo. Ma grazie a questa soluzione, i job ed i flussi di elaborazione vengono eseguiti
correttamente entro i confini del sistema e del suo perimetro di sicurezza, garantendo il
controllo sulle operazioni rischiose, per esempio rendendo impossibile l'esecuzione a
determinati profili di utenza.
Centralizzare la sicurezza delle esecuzioni dei job assicura la protezione dell'ambiente
elaborativo contro queste categorie di errori manuali.
III. In che modo è possibile visualizzare le attività di un server?
Probabilmente avrete già uno strumento di monitoraggio dei server, così come un
sistema di controllo dei componenti di rete. Ma nel vostro datacenter esiste anche una
vista centralizzata per il controllo dei processi? Un errore legato ai job può causare
interruzioni o problemi di servizio, analogamente ad un guasto della rete o dei server. Se i
vostri sistemi aziendali utilizzano programmi di pianificazione attraverso più prodotti e
piattaforme, non state centralizzando tutte le attività in un'unica schermata.
Centralizzare è possibile, e diventa semplice e funzionale se viene fatto con gli strumenti
giusti. Ogni attività in qualunque sistema e applicazione può essere centralizzata in un
unico schermo. In questo modo si può verificare lo stato di ogni job gestendo tutto da un
unico punto.
IV. Come si può migliorare la comunicazione tra i server?
I moderni datacenter sono già dotati di strumenti di pianificazione, e molti tool aziendali
possiedono sistemi di scheduling delle proprie attività. Il problema è che ognuno di questi
strumenti e sistemi utilizza linguaggi diversi, per cui in pratica è molto difficile che
possano efficacemente comunicare e scambiarsi dati tra loro. SQL, per esempio, è
dotato di una vasta gamma di strumenti per modificare i dati del proprio sistema e di SQL
Server, ma questo basta per l'inoltro di dati ad un server UNIX?
Spesso, gli strumenti nativi non sono sufficienti e c'è bisogno di una soluzione diversa per
ottenere le performance desiderate. Questa soluzione può essere sia un singolo "script di
automazione" - come gli script di cui abbiamo parlato all'inizio di questo capitolo - oppure
una pianificazione olistica, globale dei job. Nel capitolo 4 vedremo più da vicino le
funzionalità che dovrebbe offrire la soluzione migliore per ogni esigenza aziendale.
V. È possibile gestire meglio i tempi di inattività del sistema?
Piattaforme e applicazioni di norma utilizzano specifici strumenti di pianificazione, cosa
che tuttavia non le mette in grado di eseguire elaborazioni sulla base di azioni o
© ORSYP 2012 ▪
11 / 40
cambiamenti di stato. In particolare, la verifica del tempo impiegato per effettuare le
elaborazioni è un elemento difficile da misurare per tutte le piattaforme.
Flussi di dati che non vengono processati come dovrebbero, o che risultano difficili da
trasferire all'interno di un sistema, possono causare criticità all'intera pianificazione
aziendale. Quando i processi non vengono completati nel modo corretto, allora si
producono effetti a catena sulle attività a valle: questi effetti possono includere tempi di
attesa nelle elaborazioni o altre conseguenze nel sistema della pianificazione.
La durata di un processo non costituisce un problema se è prevista all'interno delle
attività, o se non è ancora stato definito quando una persona dovrà inviare file o quando i
dati saranno pronti per la fase successiva nel processo di elaborazione.
Tuttavia, gli stati di inattività sono difficili da gestire al meglio in assenza di uno strumento
di schedulazione adeguato, che comprenda la pianificazione degli eventi.
Con una schedulazione solamente temporale, i job vengono definiti senza possibilità di
gestire i cambiamenti che possono verificarsi all'interno del sistema. Semplicemente, le
elaborazioni verranno eseguite quando era stato pianificato. Una soluzione completa di
job scheduling, invece, soddisfa veramente le esigenze aziendali perché include la
gestione degli eventi (“on event scheduling”), le variazioni di stato o la possibilità di
schedulare a richiesta le elaborazioni (“trigger-based scheduling”). Il sistema “on event”,
per esempio, riconosce quando un cambiamento è stato effettuato e avvia la fase
successiva di elaborazione.
VI. Quante attività sono in corso nel vostro datacenter?
Se non avete ancora implementato o standardizzato la schedulazione dei vostri processi,
siete in grado di conoscere quante attività sono in corso nel vostro datacenter?
Io sapevo dove si trovavano i processi che avevo creato, ma un giorno ho cambiato
lavoro, e quella conoscenza è venuta via con me. Come ho già accennato, quei job sono
stati ritrovati anni dopo, spesso in seguito a criticità nelle elaborazioni o a tempi di fermo
del servizio. Inoltre, mi sono riferito solo ai miei script, ma vi erano anche altre persone
che avevano creato i loro script. Così, alla fine, ulteriori informazioni sono andate
probabilmente perse.
Una soluzione centralizzata di job scheduling permette di definire un unico punto di
controllo per tutta l'automazione. Mette in grado i team IT e il personale specializzato di
sapere dove sono state apportate modifiche ai processi, e chi lo ha fatto. In questo modo
tutto è più chiaro e i flussi elaborativi scorrono meglio all'interno del sistema.
VII. Si possono monitorare i flussi di lavoro suddividendoli per
tipologia, piattaforma e applicazione?
Se non è possibile implementare una soluzione di questo tipo, si corre il rischio di creare
solo confusione. E nella confusione, ognuno tende a scaricare la responsabilità sugli altri.
© ORSYP 2012 ▪
12 / 40
Una volta mi hanno raccontato la storia di una società che aveva bisogno del job
scheduling. Il loro sistema assomigliava al progetto che il mio capo mi aveva affidato, in
quanto includeva tecnologie e piattaforme diverse tra loro. La gestione del sistema non
era unificata nemmeno in quel caso, bensì distribuita: un team era dedicato a SQL
Server, un altro alla piattaforma SAP e così via. Anche l'AD aveva il suo proprio gruppo di
addetti. Il problema in quel caso non risiedeva nell'applicazione di strumenti specifici di
pianificazione, ma nel personale.
I vari team nutrivano una certa diffidenza verso la centralizzazione su cui si fonda una
soluzione di job scheduling. Vi era il timore di dover ricreare i job SQL, SAP, AD e altri su
un sistema nuovo, diverso da quello cui si era abituati, e fuori dal controllo dei vari gruppi.
Per essere davvero efficiente e semplice da utilizzare, in una parola funzionale, una
soluzione di job scheduling non deve richiedere la completa ri-creazione di job esistenti
su ogni piattaforma o applicazione.
Il job stesso rappresenta infatti il cambiamento che dev'essere fatto, o lo script individuale
che dev'essere eseguito. Una soluzione di job scheduling rappresenta il wrapper
centralizzato che permette di richiamare tutte le elaborazioni.
Questa storia si conclude con la scoperta, da parte dell'azienda, che la centralizzazione è
proprio ciò che serve. Un problema apparentemente minuscolo in un sistema si era infatti
trasformato in qualcosa di ben più grande, perché l'azienda non era ancora in grado di
gestire le elaborazioni in modo unitario. L'esperienza è servita per abbracciare la logica
del controllo globale d'impresa nella schedulazione dei job.
VIII. Costruire o acquistare?
Avevo scritto il mio sistema di schedulazione nell'ormai datato linguaggio di VBScript,
ampiamente utilizzato in molti sistemi ma noto per non avere strumenti di pianificazione
ad alto livello. Lo schedulatore ha funzionato bene per il compito che gli era stato
assegnato. Tuttavia, la volta dopo mi serviva esattamente quel tipo di schedulazione
complessiva che il mio strumento non poteva offrire. Dovetti perciò riscrivere il
programma, ma anche con la modularizzazione del codice VBScript la riusabilità del mio
scheduler era molto limitata.
Immaginate di dover replicare la pianificazione su tutte le applicazioni e le piattaforme
aziendali, che utilizzano linguaggi diversi. Gli script creati dal team IT possono gestire le
esigenze di attivazione dei singoli job, ma ad un livello più alto solo uno scheduler è in
grado di lavorare bene in tutti gli ambienti e con tutte le applicazioni.
Inoltre, per realizzare uno scheduler sono necessarie molte più risorse di quello che si
potrebbe immaginare. È infatti necessario controllare gli script che devono essere
eseguiti, anche in base a dove li si vuole eseguire. Vi sono poi una serie di costi
aggiuntivi, inclusi il tempo che implica la scrittura del programma. Tutto questo viene
ovviamente sottratto ad altre attività a maggior valore aggiunto, cui le risorse potrebbero
invece essere destinate.
© ORSYP 2012 ▪
13 / 40
IX. Come si possono collegare i ri sultati di un job alle elaborazioni
di quello successivo?
In ogni sistema distribuito, i job dipendono l'uno dall'altro. Un job elabora una serie di dati
che poi saranno necessari per l'attività successiva.
La condivisione di dati può essere gestita da file scambiati tra job, oppure da meccanismi
più complessi come Microsoft Message Queue o da trigger del database. Analogamente
a quanto avviene per il problema di più linguaggi diversi tra i sistemi e le piattaforme, i
metodi basilari per condividere i dati possono risolvere criticità contingenti, ma
normalmente non sono adeguati a gestire la comunicazione tra piattaforme differenti.
Diventa ad esempio difficile quando si utilizza un trigger di database richiamare un'azione
in AD. Al contrario, una soluzione centralizzata per la pianificazione delle elaborazioni
diventerà il punto centrale di controllo di tutte le interazioni e le dipendenze tra processi.
X. Come si gestiscono gli errori in un processo personalizzato?
La gestione dei messaggi di errore degli script è un processo delicato, che richiede
tempo in fase di sviluppo e design dello stesso script. Gli errori sono difficili da
individuare, soprattutto quando gli script sono distribuiti su piattaforme e applicazioni
diverse.
Gestire gli errori richiede competenze specifiche nell'intercettazione e verifica delle
variabili, oltre alla determinazione dei loro valori presunti e reali. Il quadro si complica
ulteriormente quando gli script vengono eseguiti in modalità automatica, perché spesso le
criticità non vengono rilevate. Nel capitolo 2 cercheremo di illustrare meglio la gestione di
errori e funzionalità all'interno di un job scheduler. Per ora, limitiamoci a rilevare che
questo ambito è fondamentale per la risoluzione dei problemi che possono verificarsi
durante l'esecuzione di uno script.
È bene quindi dotarsi di soluzioni IT per indirizzare tali necessità. Con le nozioni di base
esposte in precedenza e le risposte alle domande iniziali, il prossimo capitolo introdurrà
sette casi d'usi reali di automazione IT e di pianificazione dei processi. Questo dovrebbe
fornirvi spunti interessanti, in quanto i casi d'uso che verranno descritti sono
probabilmente simili alla vostra situazione attuale.
© ORSYP 2012 ▪
14 / 40
Capitolo 2: Sette casi d'uso di job
scheduling
L'unico business che non ha bisogno di automazione dei processi IT è quello che utilizza
una sola applicazione. Tutte le altre aziende ne hanno bisogno. La maggior parte dei
datacenter usa molto più di una singola applicazione su un'unica istanza.
Un datacenter di medie dimensioni esegue applicazioni per la gestione dei propri
database, e si avvale di sistemi middleware per l'elaborazione dei dati. In una simile
struttura le elaborazioni vengono eseguite su sistemi operativi (OS), mainframe e pc: tutti
elementi che hanno bisogno di comunicare tra loro, pur non condividendo lo stesso
sistema operativo e utilizzando set di strumenti specifici.
Oggi, alcune tecnologie si automatizzano da sole, ma è raro che due o più applicazioni
siano in grado di comunicare tra loro. Ancora più raro è che il singolo prodotto possa
definire e pianificare automaticamente i flussi di lavoro che soddisfano le esigenze di
business. È perciò necessario integrare tra loro le diverse tecnologie, e si può fare questo
solo attraverso una soluzione centrale che armonizzi tutte le applicazioni.
Quello di cui abbiamo bisogno è una soluzione di job scheduling che faccia da “Rosetta
Stone” - Stele di Rosetta - tra diverse piattaforme, sistemi operativi e applicazioni: una
soluzione per il datacenter finalizzata a convertire i dati grezzi nei processi aziendali, in
modo da estrarre reale valore per il business consegnando le informazioni giuste alle
persone giuste. In questo documento, tenterò di mostrare come sia possibile integrare
una soluzione simile nella propria azienda.
Abbiamo visto in precedenza come potrebbe funzionare una schedulazione IT, per
dimostrare come tali soluzioni siano necessarie alla vostra infrastruttura informatica.
Tuttavia, non abbiamo ancora esaminato approfonditamente caratteristiche e potenzialità
del job scheduling per qualsiasi tipo di azienda.
Non ne tratteremo in questo capitolo, perché il modo migliore per illustrare il meccanismo
della schedulazione dei job è di far luce sulle criticità che può risolvere. Una volta
compreso come è possibile utilizzarlo per migliorare i processi aziendali, si può davvero
apprezzare la logica in base alla quale funziona la soluzione. Mi auguro che possiate
comprendere come il progetto che mi affidò il mio capo possa essere utile anche a voi, e
che vi stiate convincendo della necessità di adottare una soluzione di automazione nel
vostro datacenter.
© ORSYP 2012 ▪
15 / 40
Sette storie di job scheduling
Quello che voglio fare ora è tentare di fornire alcune idee per aiutarvi a capire meglio
cosa può essere più adatto alle vostre esigenze. Presenterò queste idee nella forma di
sette casi d'uso, in sostanza sette piccole “storie” sulle criticità che sono state risolte
grazie ad una soluzione di job scheduling.
Queste storie sono in parte fittizie, tuttavia si basano su necessità reali e offrono soluzioni
anch'esse reali ai problemi che affrontano. Per mantenere la narrazione interessante,
utilizzerò nomi falsi.
Caso 1: Cinque
differenziate
amministratori
di
sistema
-
cinque
gestioni
La prima storia illustra la situazione amministrativa dell'Azienda A, una società matura e
affermata sul mercato, che però non possiede un'organizzazione IT altrettanto solida.
Manca infatti un controllo centralizzato dei processi, e le configurazioni del sistema sono
gestite da cinque diversi amministratori. Il datacenter stesso è composto da differenti
aree e silos, che però hanno bisogno di comunicare tra loro. I cinque amministratori IT
sono John, Bob, Jane, Sara, e Jim . Ognuno di loro gestisce una parte dell'infrastruttura
del datacenter, e le responsabilità di ciascuno si sovrappongono in qualche modo a
quelle degli altri. I cinque addetti hanno creato script e applicativi per i flussi di lavoro
della propria area di competenza, ma queste automazioni non sono connesse tra loro.
Automazioni non connesse
Manca in sostanza un contesto generale che organizzi le varie automazioni. Per
esempio, se John crea un processo, i suoi dati non possono essere basati su quelli di un
altro processo creato da Sara. Come risultato, non c'è modo di orchestrare le attività di
tutti gli amministratori, né di pianificare le elaborazioni in modo che non siano in conflitto,
né di definire un processo a conclusione dei risultati di un processo precedente eseguito
da un amministratore diverso.
Soluzione: un sistema unico per consolidare le automazioni
La soluzione risiede nel consolidamento delle automazioni di queste cinque persone in
un sistema unico e centralizzato. Solo così i job di ognuno possono essere visti anche
dagli altri. Le elaborazioni di ciascun singolo amministratore possono inoltre venire
allineate alle esigenze di tutti, per garantire una gestione più equilibrata ed efficiente delle
risorse. Infine, grazie al fatto che tutti i processi risiedono in un unico luogo, è semplice
riutilizzare i dati e gli strumenti di ogni automazione anche nelle pianificazioni future per
effettuare altre elaborazioni.
Una soluzione di job scheduling è quindi adatta a pianificazioni di natura amministrativa
oltre a quelle legate ad altri aspetti del business.
© ORSYP 2012 ▪
16 / 40
Caso 2: Conflitto tra le attività dei sistemi
Una soluzione di schedulazione informatica non si basa esclusivamente sugli operatori,
anzi ha più a che fare con i dati di un datacenter. È per questo che la seconda storia si
riferisce alle diverse applicazioni utilizzate dall'Azienda B.
In particolare, il caso d'uso riguarda la linea di business di un'organizzazione (Line-ofBusiness, LOB), intesa come le applicazioni essenziali che compongono il sistema
dell'azienda. La LOB è formata da diversi componenti, la comunicazione tra i quali viene
regolata attraverso un'attenta orchestrazione a livello di attività, processi e flussi di lavoro.
Il sistema nel suo complesso comprende sistemi operativi differenti, Windows e UNIX, e
diverse tipologie di database, middleware e altri componenti.
Sistemi e applicazioni differenti
Tutti questi elementi attivano funzionalità messe a disposizione dalla LOB. Oltre a ciò,
utilizzano il proprio set di strumenti per svolgere le attività pianificate: il server SQL
esegue i pacchetti SSIS, il server Linux SAP esegue i propri processi ed i job di tipo
Crontab, e anche il server “Informatica” esegue i suoi flussi di lavoro.
In questa configurazione, uno schedulatore per componente può funzionare per la
maggioranza delle LOB. I dati e le elaborazioni relative ad Informatica possono essere
definiti in base al tempo e ad altre caratteristiche di pianificazione, il database SQL può
eseguire i suoi pacchetti SSIS grazie alle proprie impostazioni personalizzate, e così via.
Ma, analogamente a quanto abbiamo visto nel primo racconto, in questo ambiente è
probabile che si verifichino problemi di conflitto delle attività individuali con quelle di altri
sistemi.
Soluzione: un unico pannello per pianificare i job
Una soluzione centralizzata di schedulazione delle elaborazioni è la risposta a questi
problemi, perché sostituisce con un unico pannello la pianificazione individuale di
ciascuna applicazione, e armonizza lo scambio di dati tra le piattaforme all'interno del
sistema.
Grazie alla centralizzazione dei dati e delle elaborazioni, viene migliorata la pianificazione
delle attività e le varie fasi di acquisizione e trasformazione dei dati si collegano meglio
tra loro. Il sesto caso che verrà presentato in questo capitolo illustrerà più in dettaglio
come i processi innescati in modalità automatica migliorino sensibilmente le prestazioni
del servizio. Per ora evidenziamo invece come la scelta di centralizzare la pianificazione
porti a gestire meglio tutti i job all'interno dell'infrastruttura.
© ORSYP 2012 ▪
17 / 40
Caso 3: Riutilizzo dei job per nuove attività di business
John è un DBA Oracle che ha sempre lavorato presso l'Azienda C, dove si trova
attualmente. Nella sua veste di amministratore di database, ha costruito per la società
l'infrastruttura IT quasi da zero. Conosce quindi molto bene l'intero sistema, e col tempo
ha apportato miglioramenti per aumentare le prestazioni ed eliminare i colli di bottiglia.
Ha realizzato numerosi script e diverse automazioni per raccogliere ed elaborare i dati
delle varie applicazioni, presentando poi i risultati nella forma di report destinati ai
manager. Il sistema che John ha costruito è fondamentale per la società, e l'importanza
del suo lavoro è stata ampiamente riconosciuta da tutti.
L'azienda adesso è cresciuta. Ha acquisito un business nuovo, e come risultato i suoi
sistemi informatici non sono più adeguati.
Semplice replica di un sistema precedente?
John è stato contattato dai vertici della compagnia per costruire un altro sistema. Gliene
avevano chiesto uno “...proprio come il primo, ma questa volta per la vendita di ruote
dentate invece che di ingranaggi". John ha accettato l'incarico, ma si è reso subito conto
che replicare semplicemente il sistema originale non sarebbe stato un compito così
semplice. I suoi script erano infatti Hardcoded, contenevano cioè componenti specifici
non modificabili di quel sistema. L'architettura del database che aveva realizzato era
specificamente progettata per trattare ingranaggi. I nomi dei server e degli script erano
codificati in ogni singolo script, attività e processo, e vi erano moltissime automazioni
basate sul business degli ingranaggi diffuse in tutta l'infrastruttura aziendale. Tradurre
anche un job semplice del database da ingranaggi a ruote dentate, avrebbe richiesto
mesi di investigazione, ricodifica e test di regressione. John aveva di fronte un gran
numero di applicazioni, e il risultato finale del suo lavoro avrebbe potuto non essere
all'altezza del suo sistema precedente.
Soluzione: centralizzare la gestione dei job
La soluzione ideale sarebbe stato disporre di un sistema centrale di gestione dei job,
all'interno del quale controllare tutti gli script, le attività e i processi aziendali. Questo
avrebbe potuto diminuire molto i rischi dell'attività di John, fino ad annullarli.
Si è già rilevato come un buon job sia ri-utilizzabile. In esso, le variabili vengono
impiegate per astrarre elementi come i nomi dei server o degli script richiamati (nel nostro
esempio, ruote dentate o ingranaggi), in modo che le pianificazioni possano venire
ridefinite sulla base di eventuali nuove richieste, con il minimo di lavoro investigativo,
ricodifica e test. Una buona soluzione di job scheduling prevede la possibilità di
espansione del business, e di conseguenza l'aumento di servizi per soddisfare le
esigenze dell'azienda.
© ORSYP 2012 ▪
18 / 40
Caso 4: La raccolta dati è più di una semplice
La Società D vende un prodotto di successo. Aveva iniziato in origine come una piccola
azienda, ma nel corso degli anni si è ampliata ed ha incrementato il giro d'affari.
La crescita ha posto alcuni problemi, tra cui una proliferazione di applicazioni che in
realtà solo pochi utilizzano all'interno dell'azienda, e situazioni di disordine nella gestione
delle soluzioni informatiche, alcune delle quali erano state create per risolvere problemi
specifici o rispondere a determinate esigenze.
Crescita del business e applicazioni differenti
La Società D è costituita da tante piccole realtà, con una moltitudine di applicazioni che
non sono omogenee. Per esempio, un'applicazione che si occupa del budget potrebbe
archiviare i propri dati in SQL, un'altra in Oracle, una terza invece in qualche linguaggio
ormai obsoleto o conosciuto soltanto da pochi specialisti. Armonizzare tra loro queste
applicazioni e integrare i dati è un'attività fondamentale per la Società.
Molte aziende utilizzano differenti database e applicazioni di Business Intelligence (BI),
come i Crystal Report. Queste soluzioni aggregano dati provenienti da diverse
architetture, trasformandoli per esempio da un formato Oracle ad uno SQL. Gli strumenti
di BI sono in grado di realizzare integrazioni di dati collegando diversi database. La
Società D utilizza Crystal Report proprio per raccogliere i dati di bilancio delle varie unità
di business.
Soluzione: creare un flusso di lavoro automatizzato
Una struttura aziendale complessa, come nel caso della Società del nostro esempio, è
costituita normalmente da diverse unità di business, e ciò comporta la necessità di
orchestrare i processi e sincronizzare i database per disporre di informazioni
costantemente aggiornate sulla base delle quali prendere le decisioni.
Le soluzioni di Business Intelligence sono spesso dotate di una vista unificata su
piattaforme diverse, ma non offrono strumenti per unificare le operazioni tra i sistemi. Ciò
di cui la Società D ha realmente bisogno è una pianificazione del sistema informatico
aziendale per gestire al meglio i job e creare un flusso di lavoro automatizzato. Le
operazioni per la raccolta dei dati possono essere più complesse di quanto si pensi, ma
anche in questo caso un sistema di pianificazione delle elaborazioni costituisce la
soluzione giusta per soddisfare le esigenze del business.
Caso 5: Controllo del trasferimento dati nell'e -commerce
Da quando ha iniziato l'attività di e-commerce, la Società E si è resa conto che le
transazioni e la comunicazione on-line con i clienti generano grandi volumi di dati, ed è
© ORSYP 2012 ▪
19 / 40
tutt'altro che semplice creare un sistema complessivo in grado di gestirli, ottenendo
informazioni strategiche per guidare lo sviluppo dell'azienda.
I dati grezzi si presentano in vari formati. La Società mette infatti a disposizione dei clienti
servizi web per informazioni sui prodotti, con la possibilità di effettuare acquisti on-line.
Formati diversi in contesti non strutturati
La varietà dei formati di dati crea problemi quando si lavora in contesti non strutturati, in
quanto spesso non è possibile integrare le informazioni tra sistemi diversi o all'interno dei
flussi di elaborazione aziendali.
La Società E aveva bisogno di un sistema informatico in grado di svolgere le operazioni
richieste nel commercio elettronico, per esempio registrare gli ordini effettuati dai clienti,
garantire la sicurezza dei dati e notificare agli utenti quando la transazione è andata a
buon fine.
Soluzione: piattaforma comune e automazione del flusso di lavoro
Queste operazioni presuppongono una piattaforma comune per gestire i differenti formati
di file. Una soluzione di job scheduling comprende il trasferimento dei file in un flusso di
lavoro aziendale complessivo, in cui possono essere presenti, ad esempio, formati XML,
SMTP, FTP e SFTP. Nelle soluzioni di e-commerce in particolare, deve inoltre essere
garantita la sicurezza delle transazioni. Da qui l'ulteriore complessità di gestire anche
protocolli come SSH, o di scambiare informazioni strutturate attraverso l'implementazione
di Web Service tramite il protocollo SOAP.
La risposta più funzionale e sicura a questo insieme di esigenze è rappresentata, ancora
una volta, dall'automazione delle elaborazioni, che costituisce un sistema di alto livello
per gestire ed integrare i flussi di dati.
Caso 6: Flussi di lavoro complessi e trigger per le elaborazioni
Il sesto esempio ci riporta alla storia iniziale del progetto per la mia azienda. Ho cercato
di spiegare come un processo di pianificazione fosse l'unico sistema per conseguire in
modo rapido ed efficiente gli obiettivi di quel progetto. Lasciate che vi racconti ora, un po'
più in dettaglio, come si è sviluppata quella storia.
Avevamo bisogno che i dati aziendali esterni, dopo essere stati ricevuti dal server FTP,
fossero trasferiti al server SQL il più velocemente possibile, quasi in tempo reale.
© ORSYP 2012 ▪
20 / 40
Difficoltà nell'integrazione dei dati
L'ipotesi di realizzare ciò con il solo FTP aveva dato luogo ad un lavoro incredibilmente
complicato, perché si doveva costruire una sessione di trasferimento dati sempre attiva.
Questa idea è stata subito scartata in quanto, tra l'altro, non garantiva la sicurezza dei
dati. Abbiamo quindi pensato di installare un tipo di agente, o meglio ancora di
implementare una soluzione che in realtà non prevedesse alcun tipo di agente, la quale
semplicemente rilevasse l'arrivo dei dati. Le informazioni potevano poi essere trasferite
dal server FTP al database SQL.
Questo era solo uno dei problemi, ma ne esistevano anche altri. I nostri sistemi SQL e
Oracle dovevano infatti rimanere sincronizzati. Modifiche a valori specifici in uno
dovevano essere replicati sull'altro praticamente in tempo reale. Tale sincronizzazione
comportava il trasferimento di metadati con SAP.
Anche una sola di queste esigenze poteva essere difficile da soddisfare per gli
sviluppatori. Cercando di ottenere il massimo dalle risorse a disposizione, avevamo
scelto di implementare un sistema che indirizzasse le necessità restando ad un livello di
pianificazione alto.
Soluzione: pianificazione e trigger per qualsiasi esigenza
Ciò di cui avevamo bisogno erano i trigger (letteralmente “grilletti”). I trigger sono la base
di una soluzione di pianificazione dei processi informatici, e ne esistono di diversi tipi.
Il nostro progetto richiese una vasta gamma di essi. Ad esempio, il job FTP per gestire il
flusso di dati verso SQL ha bisogno di un sistema basato su file, in grado di gestire le
elaborazioni sul server FTP. Inoltre, erano necessari trigger innescati da un messaggio
per integrare SQL con Oracle, consentendo alle due applicazioni di comunicare tra loro
per effettuare la sincronizzazione dei dati. Trigger a evento sono invece necessari per
gestire la comunicazione tra sistemi Oracle e SAP. Analogamente, servono trigger per il
corretto funzionamento dell’Active Directory e dei sistemi che permettono l'accesso ai
dati. Infine, il nostro progetto prevedeva “grilletti” a tempo per trasferire dati dal database
SQL al mainframe UNIX.
Avevamo poi bisogno di collegare gli eventi in un unico processo. Esistono trigger di
concatenamento proprio per queste esigenze, i quali permettono di accelerare i processi
e di mantenere una vista unica su tutto il sistema. Vedremo meglio questo tipo di
meccanismo nel prossimo capitolo.
Ai fini della scelta da parte vostra della migliore soluzione di pianificazione dei processi
informatici, in base all'esperienza personale e ai risultati di quell'importante progetto che
avevo realizzato per la mia azienda, posso consigliare di orientarsi verso il sistema che
offre la più ricca suite di trigger, per soddisfare il maggior numero di esigenze che la
vostra azienda potrebbe avere.
© ORSYP 2012 ▪
21 / 40
Caso 7: Protezione del datacenter da esecuzioni improprie
La Società F è un'azienda di medie dimensioni, con un dipartimento IT ben organizzato e
che offre servizi di buona qualità. Tuttavia, come vedremo in questo esempio, nemmeno
l'infrastruttura informatica meglio strutturata è completamente al riparo da errori. I quali, a
volte possono avere conseguenze significative sul business.
In questo esempio il problema si presenta quando due amministratori di sistema
condividono una varietà di script, attività e processi.
Protezione degli script e sicurezza del sistema
Abbiamo già visto che uno dei principali vantaggi dell'automazione basata su script è la
coerenza nel riutilizzo. Per gestire una serie di attività attraverso uno script, questo può
essere eseguito più volte e produrre un risultato noto. Parametrizzare gli script migliora
ulteriormente il loro utilizzo. Una volta creato, è possibile impiegare più volte lo stesso
codice per soddisfare esigenze diverse. Tuttavia, a volte questa stessa riusabilità può
trasformarsi in un rischio. Ciò capita quando è sufficiente che una persona clicchi su uno
script per attivarlo, iniziando un processo per errore, o se ne utilizza uno pur non essendo
autorizzata a farlo.
La Società F ne sa qualcosa. Un giorno Sara ha “preso in prestito" uno degli script di
Jane utilizzati in un altro sistema. Gli script di Jane sono brillantemente progettati e
parametrizzati. Ogni cosa è ben documentata in modo che siano presenti tutte le
informazioni necessarie ad un altro amministratore per riutilizzare lo script altrove. E poi,
in questo esempio lo script di Jane è esattamente ciò che serve a Sara.
Sara non è però autorizzata a eseguire i codici degli altri amministratori, in quanto
nessuno può lavorare negli ambienti altrui.
Perciò, quando Sara ha eseguito lo script di Jane, il sistema si è paralizzato.
Soluzione: controllo e automazione centralizzata
La Società F ha fatto tesoro di quest'esperienza, implementando poco dopo una
soluzione di schedulazione delle elaborazioni per concentrare le sue automazioni in un
unico punto. Il nuovo sistema ha permesso all'azienda di definire una serie di privilegi
d'accesso per gestire meglio i propri script, le variabili ad essi associate, i job e le
pianificazioni. Centralizzare gli accessi al sistema riduce drasticamente il rischio che
qualcuno possa eseguire impropriamente delle elaborazioni, o che possa collegare le
variabili errate allo script giusto, o viceversa, le variabili giuste allo script sbagliato.
La pianificazione dei job permette di avere una vista completa degli script all'interno
dell'azienda, gestendo in modo più efficiente tutte le automazioni. Come l'esempio
dimostra, questo produce vantaggi anche in termini di sicurezza perché l'ecosistema IT
viene protetto meglio.
© ORSYP 2012 ▪
22 / 40
Sette storie, sette esempi di valore aggiunto del job scheduling
Queste sette storie dovrebbero aiutare ad apprezzare il valore aggiunto che una
soluzione di pianificazione dei processi informatici offre. Il job scheduling è ideale per
organizzare e controllare processi aziendali complessi, orchestrandoli ad alto livello.
La pianificazione dei processi supporta inoltre la gestione della sicurezza, permettendo
all'azienda di avere il quadro complessivo e di dettaglio delle elaborazioni in esecuzione,
con ovvi vantaggi anche in sede di audit.
© ORSYP 2012 ▪
23 / 40
Capitolo 3: Analizziamo nel dettaglio un
flusso di processi IT
È giunto il momento di analizzare più in profondità il meccanismo interno dei job.
Abbiamo parlato poco sopra di alcuni casi d'uso e delle esigenze che spingono ad
adottare soluzioni di pianificazione dei processi IT; ora proveremo a vedere da vicino
come funziona un flusso di job. Alla fine di questo capitolo sarà possibile apprezzare
ancora di più la logica dell'automazione e comprendere come essa si adatti
perfettamente alle esigenze del business.
Uno dei motivi per cui è comodo e utile impiegare un computer per eseguire un'attività un
numero indefinito di volte, risiede nel fatto che basta “dire” alla macchina esattamente
cosa fare.
Mi auguro che il capitolo 2 sia stato piacevole da leggere così come lo è stato da
scrivere. Anche se mi sono concesso alcune licenze letterarie, ho comunque cercato di
evidenziare quali possono essere alcune esigenze reali di business che spesso si
riscontrano nelle aziende, portando esempi di utilizzo in cui la pianificazione dei processi
informatici si traduce in vantaggi concreti e misurabili. Nell'amministrazione di un
datacenter, elementi come il coordinamento delle attività amministrative, il
consolidamento dei processi e la creazione di trigger, insieme agli aspetti relativi alla
sicurezza, svolgono una funzione fondamentale.
Tuttavia, troppo spesso le aziende adottano approcci non scalabili, con la conseguenza
di aumentare il rischio di errori o di non garantire il collegamento con altre attività. Le
diverse storie raccontate nel capitolo 2 hanno un elemento in comune: la necessità di
creare un flusso di lavoro che coinvolga tutti gli attori e tutti i dati che vengono elaborati.
In fondo, sia questi flussi, sia i job e le pianificazioni sono aspetti diversi della stessa
esigenza: “dire” ad un computer cosa deve fare.
Nei primi due capitoli di questo documento abbiamo visto perché gli script di automazione
rappresentano una buona soluzione per il vostro datacenter.
Ora tenterò di chiarire come queste soluzioni possano essere implementate e gestite.
Osserveremo quindi come un flusso di lavoro realizza un'attività IT, anche attraverso
alcuni esempi di schedulazione. In questo modo cercheremo di capire meglio come una
soluzione di job scheduling può essere implementata nel modo corretto.
Analizziamo ora i flussi di lavoro che danno luogo ad un'attività informatica.
© ORSYP 2012 ▪
24 / 40
Un flusso di lavoro è un'attività IT
Un flusso di lavoro è descritto come una sequenza di passi collegati e rappresenta
un'astrazione del job vero e proprio. Si tratta di un modello che definisce in che modo
vengono elaborati i dati, e specifica il loro ciclo di vita all'interno dell'azienda.
Si trovano flussi di lavoro in tutte le tipologie di business, e non sono necessariamente di
natura tecnica. Per esempio, l'ultima volta che avete preso un giorno di riposo avrete
dovuto presentare una richiesta. Tale richiesta richiede l'approvazione, che una volta
ottenuta dev'essere comunicata ai colleghi.
Questo processo è fondamentale, soprattutto se sono previsti giorni di permesso con
retribuzione. Ci sono poi casi in cui le persone sono impossibilitate ad avvertire l'azienda,
a causa di malori improvvisi, incidenti o perché gli strumenti di comunicazione
semplicemente sono fuori uso.
In questi casi il flusso di lavoro viene interrotto perché il processo non è seguito
correttamente, e ciò comporta confusione sul “dove” si trovasse la persona quando non
ha potuto raggiungere l'ufficio, e quali attività avrebbe dovuto svolgere.
In qualche modo, l'esempio relativo alle persone può essere applicato anche ai dati. In un
sistema informatico, i dati devono essere gestiti in modo efficiente, e le attività di
elaborazione vanno definite con precisione. Il trasferimento tra sistemi diversi va
effettuato in modo tempestivo, e occorre prevedere possibili errori. Il risultato di questo
procedimento è la creazione di un flusso di dati in cui le azioni sono pianificate e viene
virtualmente annullata la possibilità di imprevisti.
Le caratteristiche che qualificano un job sono: integrabilità, monitoraggio, misurabilità,
ripetibilità e riusabilità, infine affidabilità.
Cerchiamo ora di approfondire ognuno di questi singoli aspetti.
Integrabilità
Riteniamo che i computer siano macchine “deterministiche”: dati un input e un insieme di
istruzioni di elaborazione, il risultato sarà sempre identico. Purtroppo invece, a volte non
succede quello che ci aspettavamo. Perché?
La soluzione al problema risiede nell'implementazione di un sistema in grado di utilizzare
le porzioni manuali delle attività IT in un job. Tale acquisizione di dati è possibile solo
grazie ad una soluzione di job scheduling in grado di integrarsi perfettamente con i
sistemi di backup, i database e gli script già in uso all'interno dell'azienda. La vista
complessiva sul sistema, abilitata dall'automazione dei processi, deve tradursi in
informazioni precise e dettagliate su tempi e modalità di esecuzione dei vari job.
© ORSYP 2012 ▪
25 / 40
Monitoraggio e misurabilità
Un buon processo IT dovrebbe essere monitorabile e misurabile. Una soluzione di job
scheduling deve inoltre automatizzare le attività di recovery in caso di errore. Una volta
creato, testato e attivato, un job IT dovrebbe svolgere i suoi compiti senza ulteriore
assistenza.
Questa autonomia implica che, se progettati in modo corretto, i job devono appunto
includere componenti di monitoraggio e misurazione, per garantire la qualità del risultato
finale.
La misurazione può avvenire in più punti del flusso di lavoro. Ad esempio, è possibile
verificare se la connessione dei sistemi al database per l'estrazione e l'elaborazione dei
dati avviene nel modo corretto, o se questo non accade, e in tal caso quali sono i rischi
per il funzionamento del sistema. Monitorare e misurare gli effetti dell'attività è essenziale
per la vita dell'azienda, e solo con un sistema di automatizzazione dei job si può ottenere
questo risultato.
Ripetibilità e riusabilità
Misurabilità e parametrizzazione danno luogo ad un processo riutilizzabile. Il lavoro per
creare uno script continua a creare valore anche quando il codice è già stato utilizzato,
appunto perché lo stesso script può essere reimpiegato altrove.
La riusabilità non si applica solo ai job, ma è valida anche all'interno di ogni
schedulazione. Nel capitolo 1, abbiamo definito un job come “un'azione da compiere”. Il
limite di un job deve dunque rimanere l'esecuzione dell'azione stessa.
Ogni job può essere assegnato ad un flusso di lavoro al fine di portare a termine un
processo. Una volta creati, job e schedulazioni risiedono in una libreria dei processi IT,
dove i codici possono essere riutilizzati più volte. Quindi, se per esempio due nuovi
database devono essere sincronizzati, nel caso si disponga già di una schedulazione per
eseguire questa operazione, il riutilizzo può consistere semplicemente in un drag-anddrop con la creazione di una nuova istanza del piano. A questo punto, non si dovrà fare
altro che modificare i parametri con le caratteristiche dei nuovi server per rendere
effettivo il riutilizzo dello script.
Affidabilità
Abbiamo introdotto sopra la nozione di sicurezza dei job. Nella settima storia, abbiamo
visto come sia possibile implementare misure di sicurezza sia per job singoli che per
intere schedulazioni, al fine di evitare utilizzi impropri dei dati e altre criticità.
© ORSYP 2012 ▪
26 / 40
La sicurezza è un aspetto essenziale di qualsiasi sistema informatico.
Può verificarsi infatti il caso in cui una schedulazione esegua elaborazioni sui dati, ma la
parametrizzazione consente che qualcuno possa avere accesso al sistema per interventi
o modifiche.
Per questo bisogna porre la massima attenzione al problema della sicurezza, sia al fine
di verificare che non venga effettuato nulla di improprio, sia per proteggere istanze o
trigger che quella stessa pianificazione deve attivare.
Ogni piattaforma e applicazione è di solito dotata di un proprio sistema di sicurezza,
come naturalmente lo sono tutte le soluzioni di automatizzazione dei job. Applicare
entrambi questi strati di sicurezza è una buona scelta. L'Active Directory (AD) con il suo
livello di protezione può essere utile per gestire diritti e privilegi di accesso alle
applicazioni.
Flussi di job e pianificazione dei processi
Un flusso di job è una stringa di codice. L'insieme di questi codici rappresenta la libreria
di job della vostra soluzione di job scheduling. Dovrà poi essere creato altro codice per
personalizzare il sistema, dal momento che nessun fornitore può creare oggetti per ogni
situazione.
Esaminiamo ora un ipotetico esempio di costruzione di flusso di lavoro. Il nostro flusso è
composto da una serie di blocchi, ognuno dei quali rappresenta un'attività. I dati del
sistema devono essere monitorati, in modo che i cambiamenti o gli aggiornamenti siano
subito rilevati e venga eseguito l'upgrade dei componenti.
Ammettiamo che in questo esempio sia stata implementata una soluzione di job
scheduling per gestire il flusso dei job.
Non appena si verificano modifiche allo stato del sistema, deve essere invocato un
processo per collezionare tali variazioni, quindi va eseguito uno script con i dati nuovi
rilevati, in modo da poterli trasferire tramite FTP alle altre componenti.
La pianificazione è un elemento essenziale di ogni flusso di lavoro. Essa non va tuttavia
basata – o almeno non esclusivamente - sull'ora in cui in teoria le elaborazioni
dovrebbero iniziare, bensì sul monitoraggio degli stati del sistema, come la presenza di
file, query, modifiche del file di log e altro. Tali eventi attivano le azioni successive.
Questo workflow ad attivazione è il fondamento della pianificazione dei processi IT. In
assenza di un sistema così strutturato, la pianificazione dei processi è poco più di una
funzione di controllo di data e ora. Il requisito per il successo sono i tempi di risposta
rapidi dell'infrastruttura informatica: appena si conclude una fase nel flusso di
elaborazione dati, i risultati danno avvio alla fase che segue.
© ORSYP 2012 ▪
27 / 40
Nel nostro esempio ipotetico, il flusso di lavoro elabora un oggetto Oracle. Questo job è
necessario per eseguire una query sul database.
Le specifiche circa l'uso di questo oggetto saranno aggiunte alla schermata delle
proprietà del blocco SQL. Verranno poi realizzati gli strumenti per connettersi al database
e mantenere la riusabilità dell'oggetto.
Costruire l'oggetto Oracle è il primo passo. Per realizzarlo, occorre creare una o più
istruzioni condizionali. In questo caso, attivando un comando specifico il sistema può
utilizzare le funzionalità dei Web Service per rilevare le modifiche dei dati. Queste
istruzioni sono la base per creare la logica condizionale necessaria al corretto
funzionamento del sistema.
Connessione a Web Service e job di copia file
Approfondiamo ora la logica condizionale per il monitoraggio dei Web Service grazie a
cui è possibile verificare le modifiche dei dati, includendo anche la logica di connessione
per la raccolta di dati da un database Oracle. Il passo successivo nel flusso di lavoro è
l’elaborazione di questi dati attraverso uno script, che può essere inserito nella nostra
soluzione di job scheduling.
Ammettiamo che il codice del nostro esempio sia VBScript, sebbene qualsiasi codice
supportato possa essere usato dallo script. Una volta creato, esso diventa un job del tutto
analogo agli altri compresi nel flusso di lavoro.
Il passo successivo nella costruzione del workflow è duplice. Occorre infatti trasferire i
risultati dell'elaborazione dello script in due sedi differenti del sistema, tramite due diversi
meccanismi. Il primo potrebbe avvenire attraverso un job di copia dei file, contenuto
all’interno di una libreria di processi IT. Una volta aggiunto il job, occorrerà modificare i
parametri associati al trasferimento dei file.
I job di copia dei file in genere effettuano trasferimenti di file tra sistemi operativi. Ma
trasferire i dati, per esempio da un sistema Windows ad uno Linux o UNIX, richiede
protocolli specifici, come job FTP. Nel nostro esempio, possiamo immaginare di creare
un job SFTP, cui vanno aggiunti i nomi dei server e le credenziali richieste.
Il monitoraggio e la misurazione sono componenti essenziali di una buona soluzione di
schedulazione. Un modo per realizzare questo monitoraggio può consistere nell'utilizzo di
un trigger (“grilletto”, come abbiamo visto sopra).
Utilizzo dei trigger e vincoli di file
I trigger scattano quando si verifica un determinato evento all'interno del sistema. In
questo esempio, supponendo che il flusso di lavoro richieda l'utilizzo di un servizio in
particolari condizioni, l'azione associata sarà quella di riavviare il servizio se per qualsiasi
© ORSYP 2012 ▪
28 / 40
motivo questo non dovesse essere disponibile, o di concatenare i processi mantenendo
una vista unica su tutto il sistema.
Una soluzione di job scheduling è quindi in grado di eseguire automaticamente
determinate azioni correttive. L'esecuzione di tali azioni garantisce il funzionamento
continuo del sistema.
Nel flusso di lavoro dell'esempio occorre eseguire due script per manipolare i dati. Non
vedremo nel dettaglio il primo script. Illustreremo invece ora un vincolo che potrebbe
essere applicato per definire quando lo script debba essere eseguito.
La schedulazione non può essere basata semplicemente sul tempo e l’ora. Queste
tipologie di pianificazione sono insufficienti, in quanto soggette a ritardi nell'elaborazione
dei dati. Quello che serve è invece un flusso di lavoro in cui le varie fasi procedono non
appena vengono conclusi i passaggi precedenti.
Vincolare l'esecuzione di un job alla presenza di un file, permette di eseguire
l'elaborazione solo al momento opportuno. Nell'esempio considerato, occorre elaborare il
secondo script dopo che un file viene copiato, quindi si può considerare come vincolo il
fatto che il file debba essere presente sul sistema di destinazione. L'elaborazione viene
pertanto eseguita solo quando si verifica questa condizione, in seguito al completamento
della fase precedente.
Librerie di job e valore aggiunto dei trigger
Qualunque soluzione di job scheduling si scelga, dovrebbe offrire una serie di trigger per
innescare azioni o svolgere funzioni di controllo, semplificare la gestione degli eventi su
sistemi esterni e creare o configurare cambiamenti di stato all'interno delle applicazioni.
I fattori che attivano i trigger dovrebbero includere:








Eventi specifici WMI (utilizzando la sintassi WQL)
Eventi su file (su più piattaforme)
Eventi basati su email (su più sistemi di posta elettronica)
Eventi Microsoft Message Queue
Eventi basati su Web Service
Eventi di avvio dei processi
Eventi SQL, Oracle e relativi ad altri database
Eventi legati all’ambiente virtuale
In questo capitolo si è cercato di illustrare le caratteristiche dei job e come una libreria di
essi crei una serie di azioni potenziali che è possibile aggiungere alla pianificazione del
flusso di lavoro. L'esigenza di “dire” ad un computer cosa fare è davvero un'arte, legata
alla scienza della logica, e l'implementazione di una soluzione di job scheduling crea la
struttura all'interno della quale sviluppare le proprie automazioni.
© ORSYP 2012 ▪
29 / 40
Siamo così giunti quasi alla fine del nostro viaggio verso una più ampia comprensione dei
vantaggi offerti dall'automazione dei sistemi informatici aziendali. Rimane ancora
un'ultima storia da raccontare, ed è quello che vorrei fare nel prossimo capitolo. Cercherò
di mettere in luce le principali funzionalità di una soluzione di automazione, facendo
emergere le caratteristiche fondamentali che dovrebbe avere – ed i vantaggi che può
offrire per vincere le sfide della competizione globale.
© ORSYP 2012 ▪
30 / 40
Capitolo 4: Enterprise job scheduling:
una lista di requisiti da controllare
Una soluzione di IT job scheduling è l'intelaiatura che contiene e ottimizza i sistemi di
automazione aziendale.
Una volta che la soluzione migliore è stata scelta e implementata, essa costituirà la
struttura entro cui collocare job, schedulazioni e script.
Al suo interno si trovano quindi tutte le automazioni di un'azienda, che spetta alla
compagnia stessa ideare e realizzare. In assenza di tali automazioni, la soluzione di job
scheduling non può dare risultati.
La scelta migliore è quella che include tutte le integrazioni per collegarsi al datacenter
della compagnia. Essa consente di realizzare e armonizzare le automazioni in modo
semplice, e comprende gli strumenti per orchestrare i processi. Le tre aree fondamentali
che dovrebbero orientare nella scelta di una soluzione di job scheduling sono
l'integrazione, i trigger e l'amministrazione.
Creazione dei requisiti specifici per il job scheduling
Tre cose solamente, potreste chiedervi? Il mondo reale è ben più complesso, e non si
presta a riduzioni troppo semplicistiche o schematiche. Spesso, i professionisti IT sanno
quasi per “istinto” (un istinto che hanno sviluppato nel corso degli anni) che hanno
bisogno di qualcosa di più, che ancora non hanno, per risolvere i loro problemi. La parte
difficile è formalizzare questa sensazione in una serie di requisiti che descrivano
esattamente ciò di cui hanno bisogno.
E arriviamo all'obiettivo di questo capitolo finale: aiutare i professionisti IT a definire una
specifica formale di tali requisiti. Il metodo seguito è analogo a quello del progetto per la
mia azienda di cui abbiamo parlato all'inizio di questo lavoro, e che ha ispirato la stesura
delle pagine che state leggendo.
Nei prossimi paragrafi cercherò di mettere in luce i requisiti che hanno descritto quel
progetto. Per ogni punto trattato aggiungerò alcuni commenti e tenterò di illustrare una
possibile soluzione ai problemi incontrati.
Requisito 1: Integrazione con tutte le piattaforme e le applicazioni
È bene ricordarlo nuovamente: una buona soluzione di job scheduling dev'essere in
grado di lavorare con qualsiasi tecnologia. Ciò significa che database, query e linguaggi
© ORSYP 2012 ▪
31 / 40
di gestione devono integrarsi con le applicazioni, direttamente o tramite i Web Service
esposti. Si richiede inoltre l'integrazione con tutti i sistemi di trasferimento dei file e la
gestione delle tecnologie per elaborare o convertire i dati in vari formati.
La soluzione di job scheduling deve supportare tutti i prodotti e le tecnologie presenti in
azienda. Se non vi sono garanzie su questo punto cruciale, la soluzione in esame va
esclusa dalla lista delle possibile candidate.
Requisito 2: Documentazione completa dei sistemi aziendali
Piattaforme, applicazioni e tecnologie costituiscono solo il primo livello di integrazione,
ma una soluzione informatica di pianificazione dev'essere in grado di gestire tutti i dettagli
delle applicazioni e delle elaborazioni dei dati.
Altro aspetto importante è la documentazione completa e aggiornata dei vari sistemi
aziendali e delle funzioni che svolgono, in modo anche da individuare eventuali
inefficienze o applicazioni non più indispensabili.
Requisito 3: Indipendenza e flessibilità della soluzione
La soluzione di pianificazione IT che si sceglie dev'essere in grado di organizzare e
gestire le elaborazioni in modalità cross-platform e cross-application, comprendendo
diverse tecnologie e linguaggi di scripting. In questo senso si parla di indipendenza degli
script, se il linguaggio in cui il codice è realizzato è valido per qualsiasi job, applicazione o
piattaforma, senza essere limitato ad un solo sistema.
Questa flessibilità è necessaria per rendere efficace la comunicazione tra la soluzione
adottata da un lato, e tecnologie differenti cui il sistema può connettersi, senza dover
richiedere ulteriori componenti per l'interazione.
Requisito 4: Utilizzo di code per gestire la priorità dei job
Le code in una soluzione di job scheduling rappresentano un meccanismo per la gestione
delle priorità dei job e la pianificazione delle attività. Un'infrastruttura IT efficiente utilizza
una soluzione di schedulazione strutturata su più code con priorità diverse al fine di
garantire le massime prestazioni.
Lavorare con una serie di code di priorità consente una sorta di failover, ovvero se le
risorse necessarie per i job non sono disponibili, i job in ogni caso passano in coda per
l'elaborazione successiva. Tale meccanismo garantisce che il flusso di lavoro non si
interrompa, anche nel caso in cui dovessero verificarsi criticità nel sistema.
© ORSYP 2012 ▪
32 / 40
Requisito 5: Supporto dei trigger basati su file
La soluzione di job scheduling deve comprendere un ampio ventaglio di trigger, per
garantire da un lato la flessibilità a seconda delle esigenze aziendali, e dall'altro il
controllo completo sugli eventi del sistema, grazie ad azioni automatiche attivabili in caso
di eventi specifici.
I trigger file-based “innescano” l'esecuzione di un'attività in base alla presenza o a
specifiche caratteristiche di un file in un sistema. Si tratta di trigger particolarmente utili
per gestire tutto il ciclo di elaborazione o modifica dei dati contenuti in un file, soprattutto
in contesti distribuiti, in cui è necessario avviare fasi di esecuzione immediata al
verificarsi di un cambiamento ed evitare ritardi nelle elaborazioni.
Requisito 6: Supporto dei trigger basati su messaggi
I trigger message-based consentono invece di orchestrare le attività di tutte le
applicazioni e piattaforme anche a livello basso, offrendo agli sviluppatori un quadro
semplice dove la segnalazione degli eventi è centralizzata.
Trigger basati su messaggi sono simili a quelli basati su file, nel senso che migliorano
l'esecuzione di prestazioni di lavoro mediante l'esecuzione di azioni nel momento in cui
queste sono necessarie. La soluzione scelta dovrebbe essere integrata con eventuali
sistemi di messaggistica già in uso all'interno dell’infrastruttura informatica, in modo da
includere in un'unica soluzione i vari sistemi di segnalazione presenti nell'ambiente
aziendale distribuito.
Requisito 7: Supporto dei trigger basati su eventi
La soluzione giusta per la vostra azienda deve supportare anche i trigger event-based,
per orchestrare gli eventi e consentire un controllo più completo sul sistema.
Deve inoltre garantire la possibilità di personalizzare gli eventi, in modo da innescare
azioni automatiche al verificarsi di condizioni che possono essere definite per rispondere
a specifiche esigenze del business.
Requisito 8: Supporto dei trigger basati sulle tempistiche
Anche se abbiamo sostenuto che il solo parametro temporale non è adeguato per gestire
in modo ottimale la maggior parte dei sistemi aziendali, dobbiamo però riconoscere che il
fattore tempo è un elemento che entra a definire l'organizzazione delle attività aziendali.
Occorre perciò che la schedulazione in base alla data o all'orario garantisca affidabilità ed
elasticità.
© ORSYP 2012 ▪
33 / 40
Una soluzione di automazione di job scheduling che non includa il supporto per
pianificazioni ad orario o non sia altamente personalizzabile, probabilmente non si
rivelerà adeguata a soddisfare le esigenze aziendali, soprattutto nel contesto lavorativo di
oggi, che può essere ampiamente distribuito in geografie differenti, ove le elaborazioni
vengono eseguite in diversi fusi orari.
Requisito 9: Supporto di variabili e dati dinamici per il riutilizzo
della soluzione
Abbiamo introdotto sopra il concetto di parametrizzazione dei job e delle schedulazioni.
La parametrizzazione astrae ogni tipo di informazione in variabili che possono essere
utilizzate e richiamate ovunque. Le variabili e altri tipi di dati dinamici sono fondamentali
per il riutilizzo di una soluzione di pianificazione dei processi IT. La soluzione aziendale
che si sceglie dovrebbe includere variabili di supporto all'interno dei job e delle
schedulazioni.
Spesso, il riutilizzo di variabili ed altri dati dinamici attraverso gli oggetti si riferisce alla
"profilazione" dei dati stessi, che costituisce un modo semplice per richiamare specifiche
informazioni indipendentemente dalla loro posizione nei sistemi aziendali.
Requisito 10: Garantire la comunicazione all’interno del flusso di
lavoro
Una volta che il nuovo sistema è stato scelto e installato, sarà possibile velocizzare
l'esecuzione dei job e implementare progetti per automatizzare l'infrastruttura. Come si è
visto nel capitolo 3, i job e le schedulazioni sono azioni che si collegano per creare un
flusso di lavoro. Una soluzione efficiente di job scheduling permetterà di riutilizzare le
variabili all’interno dei flussi di lavoro, in modo che altre automazioni possano essere
realizzate in futuro molto più facilmente.
Abbiamo visto alcuni esempi circa l'utilità della comunicazione all'interno e tra i workflow.
Uno dei compiti del job scheduling consiste proprio nella semplificazione dei processi per
coordinare meglio le attività di elaborazione dei dati aziendali, con il fine ultimo di
migliorare le prestazioni contenendo i costi.
Requisito 11: Pianificare i job attraverso i calendari aziendali
Si potrebbe pensare che una soluzione, il cui obiettivo sia l'esecuzione dei processi,
dovrebbe essere svincolata dal calendario aziendale. Al contrario, è opportuno tenere in
considerazione la concentrazione delle attività nel corso della giornata o in periodi di
tempo più estesi, al fine di individuare eventuali momenti di scarso utilizzo delle risorse
del sistema. Questi possono rivelarsi difficile da rilevare, particolarmente se vi sono utenti
aziendali che lavorano con fusi orari diversi.
© ORSYP 2012 ▪
34 / 40
La complessità derivante da una gestione ottimale del sistema può quindi rendere
necessario un tipo di pianificazione basato sui calendari delle attività. Grazie alla
definizione di un calendario aziendale, è possibile pianificare l'esecuzione di tutta la serie
dei job in modo da utilizzare nel modo più vantaggioso la potenza computazionale
disponibile. I calendari aziendali vengono naturalmente utilizzati anche per programmare
il lavoro in base alla disponibilità dei dati. Sapendo che un insieme di dati sarà disponibile
alla fine di ogni giornata, con questi strumenti è possibile orchestrarne la raccolta anche
attraverso fusi orari diversi e nel pieno rispetto delle norme aziendali.
Requisito 12: Visualizzare le dipendenze e redigere report
Il riutilizzo dei job crea una rete di interdipendenze tra gli oggetti. La soluzione che si
adotta dev'essere in grado di gestire tali oggetti, offrendo anche strumenti di
visualizzazione delle dipendenze tra essi. In questo modo verrà reso più semplice agli
amministratori di sistema l'intervento o la manipolazione dei processi, avendo un quadro
preciso degli effetti che si producono sul resto del sistema.
In ambienti complessi, caratterizzati dalla presenza di numerosi job e flussi di lavoro,
gestire correttamente i processi comporta solitamente la redazione di report per
raccogliere e presentare informazioni essenziali come le dipendenze di un job, la sua
classe di appartenenza, il nome ed altri dati. I report rappresentano un potente strumento
per ottenere il massimo in termini di servizio da sistemi complessi, e per organizzare le
attività in base alle risorse disponibili garantendo le migliori prestazioni.
Requisito 13: Supporto di browser e interfacce per vari dispositivi
È facile prevedere che i team IT si troveranno a gestire sempre più in futuro un numero di
attività informatiche in aumento, data la tendenza in ogni campo del business a fare un
uso sempre maggiore di sistemi computerizzati. È chiaro quindi che una stessa soluzione
dev'essere in grado di supportare più interfacce per gestire e amministrare i job. Gli ultimi
trend che si stanno affermando ora nel mondo dell'informatica favoriscono la diffusione di
browser e interfacce web per i mobile device, i quali abilitano l'utente ad accedere ai dati
anche quando si trova all'esterno del perimetro aziendale.
Per questo motivo, sarebbe bene optare per una soluzione di job scheduling che includa
diverse possibili interfacce, in modo da garantire l'elasticità di accesso alle informazioni,
necessaria a operare negli ambienti dinamici e distribuiti di oggi, insieme alla qualità
dell'esperienza utente, ugualmente essenziale.
Requisito 14: Concatenazione e bilanciamento del carico di job
Abbiamo parlato sopra del tema della modularizzazione degli elementi in un flusso di
lavoro. Ognuno degli elementi che compone un workflow va incluso nel piano di
schedulazione e armonizzato con gli altri. Ad esempio, è possibile strutturare una
© ORSYP 2012 ▪
35 / 40
pianificazione dei lavori in modo estensibile attraverso il meccanismo della nidificazione,
in cui una procedura o una funzione è contenuta in un'altra. Il concatenamento di input e
output rappresenta una delle proposte di valore di base in una soluzione di pianificazione
dei processi IT.
Grazie al bilanciamento del carico di lavoro, anche in base alle regolazioni legate ai
calendari aziendali già visti al Requisito 11, è poi possibile utilizzare sistemi che
consentono di modificare o aggiornare in modo più semplice molti componenti del
sistema, applicando i cambiamenti una volta sola in tutto l'ambiente elaborativo invece di
modificare di volta in volta i singoli job. Il risultato di un flusso di lavoro strutturato in
questo modo è la semplificazione dei processi, che producono maggior valore per
l'azienda e sono gestibili con minori risorse.
Requisito 15: Supporto di un'interfaccia di gestion e object-oriented
La soluzione migliore per la vostra azienda dovrà realizzare un'automazione completa,
che sia al tempo stesso semplice e funzionale. Per ottenere questo occorre un sistema
adeguato di visualizzazione dei job e delle dipendenze tra essi, che purtroppo manca in
molte applicazioni e piattaforme. Invece, una buona soluzione di job scheduling deve
comprendere un'interfaccia per monitorare l'esecuzione delle elaborazioni ed esplorare o
modificare la connessione dei job.
L'approccio visivo per creare e gestire i job assume tanta più rilevanza all'aumentare
della complessità dei progetti o dei flussi di lavoro. Finché il numero di job è limitato, non
ci sono problemi. Ma quando aumenta, e occorre creare legami di sincronia o definire
vincoli sui singoli job, allora diventa fondamentale poter contare sulla visualizzazione
grafica per meglio progettare le attività. Un'interfaccia di gestione orientata agli oggetti e
che comprende tool grafici comporta vantaggi per il business, anche grazie alla riduzione
della probabilità che si verifichino imprevisti, con perdite di tempo e risorse.
Requisito 16:
l'automazione
Predisposizione
di
una
libreria
di
script
per
Gli script sono la colonna portante di qualsiasi soluzione di job scheduling, e in un
ambiente IT sono molte le azioni che si ripetono con regolarità o che possono essere
comprese in un oggetto riutilizzabile. All'inizio di questo capitolo abbiamo sostenuto che
una soluzione di job scheduling è paragonabile ad una cornice, del cui contenuto è
responsabile chi si occupa dei processi informatici aziendali.
In realtà, è possibile popolare il quadro in modo automatico, inserendovi azioni
immediatamente utilizzabili. Disporre di una collezione di job già pronti offre ovvi
vantaggi, ma può anche accelerare la creazione di nuove automazioni o facilitare il
collegamento tra job differenti a seconda delle necessità. Per esempio, se c'è bisogno di
inviare un documento, basterà includere il passaggio nel job del progetto. Vi sono inoltre
numerose attività comuni che si estendono sulle piattaforme di datacenter e applicazioni.
© ORSYP 2012 ▪
36 / 40
Anche se questo metodo da solo non può garantire il soddisfacimento di tutte le vostre
esigenze, una soluzione efficace deve prevedere l'utilizzo di variabili e altri dati dinamici
per personalizzare le fasi di lavoro e le esigenze dell'automazione. Ancora più
importante, i passaggi di processo sono garantiti e testati dal venditore, cosa che riduce il
rischio di errori e le difficoltà in fase di test.
Requisito 17: Supporto ai messag gi di notifica dell’output
Una delle attività più difficili nella creazione di automazioni è costituita dal riconoscimento
dell'output, che si tratti di dati, notifiche o altri tipi di messaggi.
La maggior parte delle automazioni non viene infatti eseguita in modalità interattiva, ma
piuttosto come processi in background, che operano su piattaforme ed applicazioni senza
esporre all'utente connesso le attività in corso. Questo rende difficile rilevare i risultati di
un processo utilizzando unicamente gli strumenti nativi di applicazioni e piattaforme.
Una soluzione di job scheduling efficace esegue gli script nel suo ambiente di runtime, o
all'interno di un ambiente in cui i messaggi di output o relativi ad eventuali errori possono
essere rilevati immediatamente. La stessa soluzione deve inoltre rendere disponibili le
informazioni nella console di un amministratore, per la revisione e l'analisi.
Requisito 18: Realizzazione di un modello centralizzato di sicurezza
L'uso improprio degli script, sia accidentale che intenzionale, è una delle criticità principali
che le aziende si trovano a fronteggiare. È quindi necessario scegliere una soluzione di
job scheduling che comprenda un sistema in grado di bloccare job, schedulazioni e
attività non autorizzate, e che consenta solo a specifici profili di utenti la modifica delle
variabili di elaborazione.
Dotarsi di un modello centralizzato di sicurezza riduce molto il rischio di esecuzioni o usi
impropri degli script. Fornisce inoltre un unico punto di controllo per la gestione e il
monitoraggio delle attività. Centralizzare la struttura delle autorizzazioni è particolarmente
utile quando i datacenter sotto soggetti a specifiche regolamentazioni o a rigidi controlli di
sicurezza.
Requisito 19: Gestione e controllo unico dei cambiamenti
Tra i requisiti fondamentali di una soluzione di job scheduling vi è anche il controllo delle
modifiche apportate al sistema, unitamente allo storico delle automazioni – e relative
revisioni – che sono state implementate. Anche per motivi legati di nuovo alla sicurezza,
quando vengono effettuate modiche è necessario sapere chi ha cambiato cosa, e in che
circostanze questo è avvenuto.
© ORSYP 2012 ▪
37 / 40
La giusta soluzione di job scheduling deve quindi tenere traccia di eventuali revisioni
degli script e automatizzare i processi di controllo.
Una soluzione ottimale dovrà inoltre fornire sistemi per analizzare ogni modifica o
revisione, consentendo di risalire a chi l'ha effettuata.
Requisito 20: Database centralizzato che includa metriche e avvisi
L'ultimo requisito è la presenza di un database centralizzato per il monitoraggio del
sistema e i meccanismi di alert. Abbiamo evidenziato più volte in questo lavoro
l'importanza del concetto stesso di centralizzazione, per garantire un'esecuzione più
rapida ed efficiente delle elaborazioni.
Monitorare lo stato del sistema attraverso una soluzione di job scheduling significa tra
l'altro essere in grado di sincronizzare la comunicazione tra i componenti e gestire
l'elaborazione dei dati tra piattaforme o applicazioni diverse.
I sistemi di allarme possono invece essere attivati anche tramite la posta elettronica, i
programmi di messaggistica istantanea o piattaforme di social media, in modo da
notificare agli utenti se si verificano specifiche condizioni d'interesse.
© ORSYP 2012 ▪
38 / 40
Vincere nel mercato globale: il job scheduling alla base del
successo
Abbiamo illustrato 20 requisiti di alto livello per definire le principali funzionalità richieste
ad una soluzione di pianificazione dei processi informatici aziendali. Questi requisiti
mettono in luce gli elementi critici che tipicamente si trovano in ogni sistema distribuito, e
a cui gli amministratori dovrebbero prestare particolare attenzione. L'obiettivo è il
miglioramento dei flussi di lavoro, pur mantenendo la coerenza tra gli elementi che
compongono il sistema.
Al tempo stesso, esponendo questi principi vi ho raccontato la mia storia. Il progetto di cui
ho parlato all'inizio è stato infatti portato a termine seguendo il metodo sviluppato in
queste pagine. Creare e collegare tra loro le automazioni ha richiesto tempo, lo ammetto,
ma i risultati hanno dato ragione delle risorse impiegate. Un unico sistema centralizzato e
automatizzato si è dimostrato la risposta migliore alle esigenze dell'azienda per cui
lavoravo. Ci ha permesso di “fare di più, con meno”: abbiamo ottenuto grandi vantaggi in
termini di qualità del lavoro, soddisfazione delle persone e riduzione degli errori.
Se dovessi fare di nuovo un lavoro simile, seguirei gli stessi principi cui mi sono ispirato
quella prima volta. Mi auguro che quanto ho appreso possa essere utile anche a voi, per
proseguire sulla strada dell'eccellenza aziendale e perseguire il miglioramento continuo,
che ritengo essere la base del successo nell'era della competizione globale.
© ORSYP 2012 ▪
39 / 40
EMEA Headquarters
Tour Franklin
92042 Paris La Défense
Cedex
France
+33 [0]1 47 73 12 12
www.orsyp.com
–––
Americas Headquarters
300 TradeCenter 128
Suite 5690
Woburn, MA 01801
USA
+1 781 569 5730
–––
APAC Headquarters
Honest Motors Building
9-11 Leighton Road
Causeway Bay
Hong Kong, China
+852 2575 5966
© Copyright 2012. All rights reserved. ORSYP and its logo are trademarks of ORSYP S.A.S. All other trademarks in this
document are the property of their respective owners. Specifications are subject to change without notice.