Solutions for Automating

IT Job Scheduling

Soluzioni per l'automazione

del job scheduling

ORSYP Italia

© ORSYP 2012 ▪ 2 / 40

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 ▪ 3 / 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 ▪ 4 / 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, HP-

UX, 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 ▪ 5 / 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 ▪ 6 / 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 ▪ 7 / 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 ▪ 8 / 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 ▪ 9 / 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 avete perso per completare i processi

manualmente?

© ORSYP 2012 ▪ 10 / 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 ▪ 11 / 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 ▪ 12 / 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 ▪ 13 / 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 ▪ 14 / 40

IX. Come si possono collegare i risultati 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 verif icarsi

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 ▪ 15 / 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 ▪ 16 / 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 amministratori di sistema - cinque gestioni

differenziate

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 ▪ 17 / 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-of-

Business, 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 ▪ 18 / 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 ▪ 19 / 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 ▪ 20 / 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 ▪ 21 / 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 ▪ 22 / 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 ▪ 23 / 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 ▪ 24 / 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 ▪ 25 / 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 ▪ 26 / 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-and-

drop 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 ▪ 27 / 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 ▪ 28 / 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 ne lla 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 ▪ 29 / 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 ▪ 30 / 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 ▪ 31 / 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 ▪ 32 / 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 ▪ 33 / 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 ▪ 34 / 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 ▪ 35 / 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 ▪ 36 / 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 gestione 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: Predisposizione di una libreria di script per

l'automazione

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 ▪ 37 / 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 messaggi 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 ▪ 38 / 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 ▪ 39 / 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.

© 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.

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