Ciao,

oggi inauguro il mio nuovo url per il blog :

blog.luigimolinaro.it

I miei pochi post li scrivero’ li da oggi in poi.

Espreria è diventato decisamente anacronistico!

Il Service Level Agreement (Sla) è un documento che assume la connotazione di un contratto e che ha come obiettivo, la definizione di una serie di vincoli inerenti l’erogazione di servizi (qualità del servizio offerto, parametri di valutazione dei risultati, verifica dei risultati, ecc.) e di pattuirne i relativi prezzi richiesti dal fornitore.
Questo contratto rappresenta, pertanto, uno strumento di definizione e valutazione delle esigenze dell’organizzazione in termini di servizi It richiesti (service customer) e conseguentemente di valorizzazione degli stessi dAa parte del fornitore che li offre (service provider). Senza alcun dubbio, negli ultimi anni la continua evoluzione delle esigenze del settore “business” delle Pmi ha determinato una trasformazione delle metodologie e delle tipologie dei processi e conseguentemente dei servizi It presenti nelle organizzazioni. Ogni servizio erogato da una struttura It deve necessariamente essere valutato in funzione della sua continuità, dell’efficacia e dell’efficienza.Uno dei punti salienti su cui si basa l’efficienza e l’efficacia dei servizi It è costituito dai tempi di risposta che rappresentano il primo riferimento del servizio It percepito dal cliente e contestualmente il più difficile da garantire. Ciò può determinare l’insoddisfazione del cliente e conseguentemente anche l’insuccesso della fruizione dei servizi offerti. In uno scenario come questo è indispensabile poter disporre di strumenti in grado di monitorare costantemente i livelli di servizio offerti. Il Service Level Management (SLM) è il processo attraverso il quale viene strutturata, negoziata, misurata, gestita, e migliorata la qualità dei servizi It. Esso rappresenta, pertanto, il giusto bilanciamento tra l’offerta e la richiesta di servizi It in un contesto aziendale caratterizzato da continui e alle volte troppo rapidi cambiamenti sia tecnologici che del settore business. Il Service Level Management, per poter organizzare e gestire i vari livelli di servizio, è strutturato su di una serie di documenti ben distinti: Service Level Agreement (Sla); Operating Level Agreement (Ola); Underpinning Contracts (Uc); Quality Services Plan (Qsp).
Pur essendo molteplici e diversi tra loro, i documenti sopra descritti si integrano tra loro in funzione dello stesso obiettivo da perseguire: identificare, strutturare, erogare livelli di servizio garantendone, nel tempo, continuità, qualità e miglioramento degli stessi.

Sla: redazione del document
Essendo il “contratto” di riferimento per l’erogazione dei servizi It, lo Sla deve rappresentare il punto nevralgico per l’identificazione e pianificazione dei servizi richiesti dall’organizzazione. Pertanto la struttura di uno Sla dipende da una serie di variabili, quali: gli aspetti fisici dell’organizzazione (dimensioni, complessità, distribuzione geografica, organizzazione interna, ecc.); gli aspetti culturali dell’organizzazione (il linguaggio utilizzato, le relazioni tra l’organizzazione It e il cliente, le policy di addebIto, le attivItà di business, ecc.); la natura delle attivItà di business (termini generali e condizioni, orari e metodologie di svolgimento delle attivItà di business, ecc.)
In funzione del mutato orientamento delle Pmi in Europa, soprattutto negli ultimi anni, che ha visto un sostanziale aumento dell’affidamento della gestione dei servizi It a strutture esterne (outsourcing), si comprende lo sviluppo e la promozione di Sla come mezzo insostItuibile per la definizione esatta dei servizi richiesti e dei costi ad essi riconducibili
Naturalmente la definizione di uno Sla presuppone una prima fase che preveda un’analisi analitica sulle infrastrutture It esistenti nell’organizzazione, delle persone coinvolte, delle esigenze del settore business, e delle risorse interne disponibili (umane e materiali). Uno Sla ben strutturato può consentire: che l’offerta dei servizi It venga maggiormente focalizzata sul cliente e sugli accordi relativi alla qualItà dei servizi erogati, migliorando, nel complesso, i rapporti tra cliente/fornitore; che i servizi It siano analiticamente descritti in un linguaggio chiaro e comprensibile per facilItare al massimo gli intendimenti delle parti e le modalItà d erogazione degli stessi; che la qualità, la disponibilità, l’affidabilItà e il costo dei servizi vengano sottoposti ad un miglioramento continuo; che il contratto di fornitura dei servizi stipulato dalle parti, se redatto con il massimo livello di dettaglio consentito, migliori la comunicazione tra l’organizzazione e gestore dei servizi It.

Architettura di un Service Level Agreement - Fonte: l’autore per ZeroUno

Architettura di uno Sla
Lo Sla deve assumere la connotazione di un documento flessibile e personalizzabile in funzione delle diverse esigenze riscontrate all’interno dell’organizzazione. Tuttavia è possibile identificare un framework di riferimento che possa consentire l’identificazione delle fasi fondamentali della stesura del contratto. Le fasi fondamentali di un Sla possono essere riassunte in:
1. Negoziazione dello Sla: è la fase attraverso la quale un fornitore e il cliente definiscono un accordo sulla tipologia e la qualItà dei servizi erogabili determinandone, nel contempo, il relativo costo. Vengono quindi identificati i bisogni del cliente e le metodologie di fruizione dei servizi offerti dal fornitore. La fase si conclude con la firma dell’accordo da entrambe le parti.
2. Sviluppo dello Sla: in questa fase l’accordo viene validato e distribuIto alle parti coinvolte. Ad esse vengono fornite tutte le informazioni sui ruoli dei firmatari dell’accordo. Inoltre le parti coinvolte vengono informate sulle rispettive competenze e obblighi da assumere per una corretta gestione dei servizi erogati.
3. Misurazione e valutazione dello Sla: sono delle metodologie di analisi che devono consentire la raccolta delle misurazioni provenienti dalle risorse impiegate per la verifica del rispetto degli accordi definiti nello Sla. Il servizio di misurazione tiene traccia della configurazione generale dei sistemi utilizzati, delle risorse impiegate, dei tempi di erogazione e di espletamento dei servizi, delle informazioni di run-time sulle metriche coinvolte nello Sla, ecc.
4. Azioni correttive: vengono attivate nel momento in cui vengono rilevate delle violazioni sui servizi erogati che pregiudicano il perseguimento degli obiettivi prefissati. Tali azioni vengono notificate al servizio di management che applicherà le eventuali azioni correttive che comporteranno un aggiornamento sullo Sla. Tutte le azioni correttive devono essere descritte in un apposito documento ove saranno identificate.
5. Eventuale riformulazione delle condizioni dello Sla: i report, prodotti in seguito alle azioni correttive apportate, costituiscono la base su cui riflettere per un eventuale adeguamento dello Sla. Dopo un’attenta analisi della reportistica viene esaminata l’ipotesi di una “upgrade” dello Sla, esaminando, nel contempo, tutte le variabili e le conseguenze che tali modificazioni comporterebbero. Vengono esaminati attentamente i costi che potrebbero essere oggetto di variazioni, anche in termini sostanziali. Le modifiche possono comportare anche l’integrazione di nuovi servizi o l’eliminazione di alcuni di essi. Le integrazioni/modificazioni, integrate nella nuova release dello Sla, dovranno essere formalmente accettate da tutte le parti coinvolte.
6. Terminazione dello Sla: è possibile che si verifichino delle condizioni che possano provocare la terminazione di uno Sla. Molteplici possono essere le cause come ad esempio il mancato rispetto di una clausola da parte di uno degli “attori” coinvolti o la conclusione del rapporto di collaborazione.

Come stilare in maniera corretta uno Sla?
Ogni organizzazione, in funzione delle proprie attività svolte e degli obiettivi che intende perseguire, potrà realizzare uno Sla personalizzato identificando i servizi It e le modalità di erogazione più indicati. Tuttavia è raccomandabile osservare alcune indicazioni:
1. identificare i bisogni e le esigenze dell’organizzazione e i relativi servizi It ad essi riconducibili;
2. identificare chiare metodologie di misurazione, per tutte le parti coinvolte, della qualità e dell’efficienza dei servizi;
3. è fondamentale stabilire riunioni e meeting periodici per la consegna reciproca di relazioni. Il fine è quello di avere sempre un atteggiamento critico sul problema e un atteggiamento di apertura verso i cambiamenti di mercato che possono comportare modifiche allo Sla;
4. solitamente lo Sla include sia dei livelli minimi che dei livelli target. Il fornitore deve raggiungere i livelli minimi e l’inadempimento giustifica l’immediata risoluzione del contratto. I livelli target, invece, pur venendo ovviamente misurati, non comportano la risoluzione del contratto ma solo (nella misura indicata) il sorgere di crediti (che possono comportare una rivisitazione dello Sla);
5. occorre evitare che il livello di servizio venga concordato successivamente o che, come spesso accade, il fornitore proponga di fissare i livelli di servizio sulla base di quanto raggiunto in una prima fase di prova;
6. è fondamentale appoggiarsi a professionisti esperti che abbiano maturato una esperienza specifica di settore per poter redigere un documento corretto, sensato ed equo.
7. è bene ricordare che la gestione degli Sla è un processo continuo. In tale senso è consigliabile prevedere nel contratto delle revisioni periodiche delle clausole dello Sla per meglio adattarsi al mercato che cambia.
8. lo Sla non è uno strumento punitivo e neanche un mezzo che consente al cliente di arricchirsi a discapito del fornitore: alla sua redazione lavorano a stretto contatto i clienti e i fornitori. Uno Sla ben strutturato consentirà una perfetta gestione dei livelli di servizio, una riduzione dei costi oltre ad un continuo controllo degli stessi, una efficienza complessiva dei servizi erogati e di conseguenza un miglioramento dell’intera organizzazione.

Conclusioni
Nell’attuale scenario economico mondiale, le organizzazioni non possono più prescindere dall’esigenza di modellare e razionalizzare i servizi It impiegati nei processi interni a qualsiasi livello. Livelli di servizio scadenti possono determinare una crisi dei processi interni che possono avere, come conseguenza diretta, il crollo della funzionalItà e dell’efficienza dell’azienda. Anche se gestiti da entità esterne (outsourcing), i servizi devono rappresentare lo strumento di riferimento per una corretto sviluppo dell’azienda. Nel testo “Logistica & Strategia 2” di C.Ferrozzi- Janice Hammond-Roy D.Shapiro, si legge: “l’outsourcing resta in molti casi ancora un sogno, una specie di illusione in cui ci si culla nella speranza che un giorno compaia un’impresa in grado di offrire, in concreto, un servizio ottimo, costi accettabili, nessuna contestazione, né litigi…Il segreto è riposto nel totale controllo delle prestazioni, esattamente come se la logistica fosse nostra…  Occorrerebbe poter esibire all’impresa esterna le nostre conoscenze sulla qualità del suo operare. Occorrerebbe esibirle in maniera diretta, precisa, rapida. Sarà necessario contattare quasi ogni giorno i clienti più importanti, sentire il loro parere sul servizio. Se si arriva a situazioni di forte conflitto, queste si risolvono solo rescindendo il contratto. Invece chi presta un servizio logistico dovrebbe migliorare le proprie prestazioni proprio aiutato dai clienti. Tale aiuto lo si manifesta lavorando insieme e facendo capire al terzista come sta andando il servizio, come si alzano i costi, di quanta flessibilità c’è bisogno”.

Che dire a proposito di questo :

http://www.gazzetta.it/Calcio/SerieA/Squadre/Catania/Primo_Piano/2008/09/15/lomonaco.shtml

Si possono avere opinioni diverse, sicuramente su tali idee puo’ incidere la fede calcistica, anzi forse è determinante, da juventino non commento perchè già sapete dovrei andrei a parare, dico solo che Mourinho è perfetto per l’inter.

La cosa che mi lascia perplesso è l’inervento di Maroni a tal proposito :

“Sono francamente stupito delle dichiarazioni di alcuni dirigenti di società di calcio di serie A che sembrano proprio una istigazione alla violenza. Non ho titolo per intervenire ma quando un dirigente dice dell’allenatore della squadra avversaria che “bisognerebbe bastonarlo sui denti”, è un’istigazione alla violenza. Mi aspetto che il giudice sportivo, la Lega Calcio o la Figc prendano immediate decisioni in merito. Comportamenti di questo tipo sono la cosa peggiore che si può fare, perché l’esempio viene dall’alto. Se un dirigente di una squadra incita alla violenza, anche solo metaforicamente, poi non mi stupisco se qualche tifoso esagitato mette in atto comportamenti violenti. Bisogna evitare queste espressioni.”

Il signor Maroni, nostro ministro per l’interno, secondo me ha cosa piu’ importanti a cui pensare, prego perchè non abbia dato  fiato alle trombe solo perchè in mezzo c’è un dirigente di una squdra del sud… non ci voglio nemmeno pesare. Ma a parte tutto, e se proprio deve occuparsi di qualcosa si occupi semmai del delirio del capogruppo del suo parito Bossi, che  parla di 300mila fucili padani (!?!?!? non si sa pronti per cosa ??? ) e saluta l’inno nazionale con il dito medio… questa si che è istigazione di un certo livello, lasci perdere due dirigenti che fanno a pugni verbalmente, c’è la federcalcio e la figc per questo, lei si occupi di altro, magari parta da molto vicino.

Questo partito di depressi sfigati razzisti risponde alla volontà di tantissimi italidioti che non avendo una cultura personale e una mente abbastanza aperta tendono a predicar razzismo e odio verso le minoranze etniche.
Per fortuna l’italia sta diventando sempre più una società multietnica (solo il tasso di stranieri nelle scuole sale anno dopo anno).. ergo gruppetti come la lega nord o quelli neo fascisti verranno sempre più ignorati. Deo Gratias

#!/bin/sh
username=“helpdesk@esperia.com”;
password=“123″;
MAX_MESS=$1
[ $# -eq 0 ] && exit 1 || :
sleep 2
echo USER $username
sleep 1
echo PASS $password
sleep 2
for (( j = 1 ; j <= $MAX_MESS; j++ ))
do
echo DELE $j
sleep 1
done
echo QUIT

Lo salvate con un nome (es cancellaemail.sh) e gli date i permessi di esecuzione : 

chmod 777 cancellaemail.sh

Ho scritto un piccolo scripettino per cancellare le email via pop3. l’ho scritto
per cancellare le email di helpdesk@esperia.com 62.000 !!!!
Penso che vi possa essere utile va usato cosi

Prima si entra via telnet e si vedono il numero delle email :

lmolinaro@castaway:~$ telnet pop.inet.it  110

Trying 213.92.5.60…
Connected to pop.inet.it.
Escape character is ‘^]’.
+OK ifm-pop (version 5.0.0) at fe-2c starting.
user helpdesk@esperia.com
+OK Password required for helpdesk@esperia.com.
pass 123
+OK helpdesk@esperia.com has 61331 messages in 146598418 octets.

quit
+OK Pop server at fe-2c signing off.
Connection closed by foreign host.

Dopo che sappiamo il numero delle email (in questo caso 61331 
lanciamo lo script

./cancellaemail.sh 61331 | telnet pop.inet.it 

Ce le canceller? tutte senza ne scarcarle suk proprio client ne tantomeno facendolo a mano.
Ve piace ?

Ciao
Luigi

Mi ricordo quando ero piccolo… la nostra era una specie di setta, ci incontravamo in un negozio che vendeva computer. Povero, faceva fatica ad arrivare a fine mese, il gioco piu’ bello aveva 4 colori.

Incontrare qualcuno che usava un pc era una festa, si condiveva la passione ci si scambiavano opinioni e si diventava in qualche caso amici.

Da quando negli anni 2000 l’informatica è diventa di massa noto con sempre piu’ rammarico che l’atteggiamento tipico delle persone che magari utilizzano il computer da poco è di una strafottenza disumana. “Studiate gente, studiate.” “Non capite un cazzo” “IO IO che le cose le so veramente” sono le frasi piu’ usate… Ma perchè ??? Io non me lo riesco a spiegare… tra l’altro è una cosa che noto che succede spesso nell’ambiente informatico, in altre professioni  non noto un attegiamento del genere…

Le mie riflessioni prendono spunto da questo ariticolo di punto informatico (ci vado poco perchè pieno di questi pompati)

http://punto-informatico.it/b.aspx?i=2317710&m=2319675#p2319675

Si parla di Windows Vista, che obbiettivamente (dati alla mano) non ha avuto il successo che ci si aspettava nel mondo enterprise (beh… i consumer sono stati obbligati… shhhh zitto!!!!) e subito ci si inasprisce sul prefetch della RAM di WIndows… giu’ mareee di espertoni che sanno bene come utilizzare la ram… giu0 commenti su commenti su quanto sia meglio Linux… (???) .

Potrebbe essere una discussione costruttiva ma no, ecco che mi ritrovo quegli attegiamenti deleteri, presupponenti ed arroganti che tanto odio… mi fanno paura le persone con solo certezze ed amo chi ha il dono del dubbio…

Ne sei proprio sicuro Luigi ?
Non ho nessun dubbio.

Messaggio di errore: La password deve essere lunga almeno 18770 caratteri e non può essere uguale a nessuna delle 30689 password precedenti.

http://support.microsoft.com/kb/276304

Ovvero High Availability, o meglio ancora la differenza tra fare il sistemista SBS o Enterprise :

Ecco alcuni concetti (in ingelese):

Availability

Fault tolerance

Mean time between failures (MTBF)

Mean time to repair (MTTR)

Messaging Dial Tone

Network Load Balancing (NLB)

Network-attached storage

Planned downtime

Redundant array of independent disks (RAID)

Reliability

Scalability

Server clustering

Service level agreement (SLA)

Storage Area Network (SAN)

Unplanned downtime

In merito al recovery model SIMPLE spesso girano dubbi e spesso capita di sentirsi chiedere cosa logga e se le sue dimensioni crescono  e perche’ crescono  e quando si “sgonfia” etc etc. Sperando di fare cosa utile in questo post provero’ a fare un po’ di chiarezza in merito…Innazitutto chiariamo che una modalita’ di logging SIMPLE non significa che non loggo … Tutt’altro: SIMPLE significa solo che il transaction log non potra’ essere utilizzato in fase di restore (infatti in questa modalita’ non e’ concesso il backup del log), ma che comunque viene assicurata tutta l’attivita’ relativa alla gestione delle transazioni … e ci mancherebbe che non lo facesse !!!! 

Pertanto, anche in questa modalita’, il transaction log conterra’ tutte le informazioni necessarie a Sql per poter gestire un eventuale roll back. Questo comporta che il file di log avra’ una dimensione tale da memorizzare tutte le transazioni non ancora committate o, piu’ precisamente, conterra’ “almeno” tutte le transazioni avvenute a partire dalla piu’ vecchia presente ancora non committata.

Per questa ragione, in presenza di transazioni ricche di dati, anche in modalita’ SIMPLE il file di log crescera’ e potrebbe assumere dimensioni anche elevate.

La differenza con le altre due modalita di recovery (FULL e BULK_INSERT) risiede nel fatto che, man mano che le transazioni vengono committate lo spazio a loro associato viene riutilizzato per memorizzare nuove transazioni.[per dirla piu' correttamente viene riutilizzato lo spazio associato alle transazioni antecedenti alla piu' vecchia non committata]. Questo in FULL e BULK_INSERT avviene dopo il backup del log.

Nella modalita’ SIMPLE periodicamente e con una frequenza legata alle dimensioni del file di log e al suo grado di riempimento, viene verificata la posizione della transazione attiva piu’ vecchia e viene marcato come riutilizzabile lo spazio del log allocato a tutte le transazioni antecedenti a questa. Tale attivita’ prende il nome di Troncamento (truncation) del log.

Il Log truncation e’ un attivita’ di tipo logico: ad essa non e’ associata una riduzione fisica del log.

La diminuzione del file di log e’ legata all’attivita’ di Shrink che, se non e’ abilitata tramite l’opzione AUTO_SHRINK ON (cosa da non fare MAI ), avverra’ solo dietro un preciso comando (ad esempio un DBCC SHRINKDATABASE).

Detto cio’ bisogna ricordare che il recovery model SIMPLE, visto che non consente il recovery tramite log, andrebbe usato raramente: di fatto solo con DB in read only o di test… Averlo in produzione significa sapere che, in caso di failure, verranno perse tutte le transazioni intercorse dall’ultimo backup (full o differenziale) cosa che ritengo sia accettabile in ben poche situazioni….

Entro la prossima settimana gli utenti di MySQL dovrebbero essere in grado di mettere le mani su un corposo aggiornamento del noto DBMS libero; l’occasione per il rilascio sarà la MySQL Conference 2008, la prima da quando Sun Microsystems ha acquisito MySQL AB.

Sebbene il numero di versione indichi l’appartenenza al ramo di sviluppo 5.x, la quantità di funzionalità introdotte e la mole di lavoro necessaria per implementarle farebbero pensare a qualcosa che avrebbe avuto più senso chiamare MySQL 6.0.

Tra i miglioramenti di questa nuova versione troviamo il partizionamento ( partitioning ), la programmazione di eventi ( events scheduling ), la replicazione di righe ( row-based replication ) ed il clustering su disco ( disk-based clustering ); trattandosi di caratteristiche già offerte da rivali del calibro di IBM, Oracle e Microsoft queste novità dovrebbero aiutare MySQL ad inserirsi in ambienti dove, fino ad ora, non sarebbe riuscito a competere.

In aggiunta alla nuove funzionalità, Sun ha anche sistemato parecchi bug presenti nella versione 5.0 e lavorato duro sulle prestazioni: oltre ad essere più solido, MySQL 5.1 offrirà quindi miglioramenti dal punto di vista delle performance ( in alcuni casi si potrebbe arrivare anche ad incrementi del 20% ).

via: ossblog