Ho questo post di Bart De Smet nella lista delle "Review" da qualche giorno, ci avevo dato una scorsa veloce e stasera sono riuscito ad effettuare una lettura un po' più approfondita.
Molto interessante, a mio giudizio, perchè dà un'eccellente dimostrazione dell'uso congiunto di alcune più-o-meno-nuove tecnologie.
In particolare, ad esempio, mi è piaciuto l'utilizzo degli extension methods, molto razionale e, credo, anche piuttosto didattico.
Gli e.m. sono (pure loro) un po' di sintassi e un bel lavorone del compilatore, sia in fase di generazione che in fase di risoluzione delle chiamate.
Se non possiamo sfruttarne i servizi, è comunque sempre possibile "sporcarsi le mani", andare ad interrogare i metadati via Reflection (con una query LINQ ovviamente) e fornire al consumer le funzionalità che, con le sua API, questo richiede.
Yep :-P
Sulla collaborazione, sulla condivisione della conoscenza, sull'approccio che per raggiungere tali obiettivi si adotta, sui side-effect di ciasucno di questi punti, professionalmente e personalmente (scusate sono un po' oscuro ma le riflessioni devono ancora trovare una loro collocazione fra i pochi neuroncini rimasti svegli) ... ecco su questo è stata incentrata per diverse ragioni la mia giornata odierna.
In parte perché ho preparato il materiale per un corso level100 (prima volta che mi capita) su SharePoint per un cliente, nel quale l'obiettivo é di fornire una panoramica sul prodotto e, non ultimo, di stimolare una discussione alltoghether sulle sue potenzialità e sulla sua applicabilità. Sempre ammesso che per SharePoint di "prodotto" si possa parlare (tema per altro post).
In parte, e soprattutto, perchè alla sera gli stessi argomenti (alcuni) sono stati riaffrontati davanti ad una birra (o ad un amaro) con una persona davvero in gamba, che ringrazio davvero tanto per la chiacchierata, per la sinerità e per gli spunti che ne sono derivati (e che probabilmente ritarderanno un po' il mio sonno).
E comunque, pensare pensare pensare. E alla fine pensare :-)
E condividere il tutto ... ma magari domani o dopo ... ora sono in catalessi :-)
C'era una volta un giovane ed inesperto ragazzo che per raccogliere quei pochi spiccioli che gli avrebbero garantito una vita decorosa decise di buttarsi nell'esperienza lavorativa e si fece asssumere ad un help desk.
L'assistenza era un'area che, in fin dei conti, lo aveva sempre interessato. Probabilmente ci trovava quel gusto pseudo-altruistico che si assapora nel momento in cui si aiutano gli altri.
Fatto sta che si impegnava per fare bene il proprio lavoro.
Al'inizio, obiettivamente, non era necessaria una particolare organizzazione. Le richieste erano poche. Perchè i servizi erano pochi. E per buona parte della giornata il ragazzo stava in ozio meditando sul modo per incrementare il profitto del proprio lavoro.
E non ci volle molto perchè ne emergesse una spiccata necessità.
Aumentarono i servizi proposti, aumentarono i problemi, aumentarono le telefonate.
Il ragazzo passava sempre più tempo con la cornetta nella mano, spesso cercando vie strane per risolvere problemi strani. Si sa, erano strani pure i clienti.
Eppure ci furono enormi lamentele durante quel periodo.
Molti inviarono lettere minacciose, denunciando che la linea era perennemente occupata e che non era stato possibile avere risposta alle proprie domande.
Il ragazzo non si stupì della cosa. Insomma ... era da solo e doveva gestire le chiamate di un numero sempre maggiore di clienti. E per di più la complessità degli argomenti aumentava in maniera esponenziale.
Non gli ci volle molto a far presente ai propri datori di lavoro un evidente sottodimensionamento del personale addetto al supporto di primo livello. Cioè all'helpdesk. Cioè lui.
Nulla. Non ci sono risorse, dicevano. Senza capire che senza risorse si perdono i clienti.
Eppure era giudizioso e volenteroso. E provò ad arrangiarsi.
Il problema sembrava insormontabile. Lavoro per 2, a disposizione 1 solo.
Non potendo risolvere la cosa, decise di barare.
Rispose alla prima telefonata come sempre, in maniera gentile e con dedizione massima.
Ma, dopo alcuni istanti, disse all'interlocutore che doveva controllare alcuni dati nell'archivio e che l'avrebbe richiamato a breve.
E mise giù il telefono. Che squillò, ovviamente, nel giro di un attimo.
Rispose così alla seconda telefonata, altro cliente e altro problema. Ma l'approccio fu il medesimo. Archivio da controllare, telefonata a seguire.
Il ragazzo, peraltro, non era sprovveduto. Si era organizzato con un foglio di carta sul quale memorizzava i nomi dei clienti in attesa, uno sotto l'altro in ordine di ricezione della prima chiamata. E a turno li ricontattava, dopo un finto giro in archivio, pronto a riprendere il problema da capo, come niente fosse successo.
E il sistema funzionò. Anche se ci volle qualche aggiustamento.
Una mattina, ad esempio, ricevette una strigliata dal capo perchè un cliente si era lamentato dei tempi di attesa, un po' troppo lunghi a sentire lui. Dopo diversi minuti durante i quali provò a spiegare al capo la situazione, si rese conto che doveva pensarci da solo.
Chiese solamente al capo di indicargli quai fossero i clienti più importanti. E modificò il foglio sul quale prendeva nota delle chiamate in corso, marcando con un asterisco quelle più ... critiche.
E il sistema funzionò.
Finalmente, dopo alcuni mesi di rodaggio, il ragazzo si recò dal capo e gli presentò il resoconto della situazione.
"All'inizio - disse - era tutto molto più facile. Rimanevo al telefono con i clienti finchè il loro problema non era risolto. Un sacco di tempi morti, sa, perchè molto spesso aspettavo un fax che mi sarebbe servito a portare avanti la soluzione del problema. Ed erano tempi di attesa snervanti, per me e per il cliente."
"Tra l'altro le devo dire che i clienti hanno la pessima abitudine di tenerti a telefono per delle ore. Capisco come mai molti trovavano occupato !"
"Una volta mi ricordo, pensi, che un cliente addirittura mise male la cornetta dopo una chiamata. Ha presente quel pomeriggio che non funzionava più il telefono ?"
"Ora, devo dire, va molto meglio. I clienti sopportano bene il fatto di essere messi in attesa - quando ovviamente gliene si dà una ragione sensata - e obiettivamente si riesce a rispondere a tante persone tutte insieme"
"Poi con l'ultima trovata del marchio per i clienti vip diciamo che ... beh ... quelli importanti hanno risposte prima degli altri ... ma questo è voluto, no ?"
"Ora, ascolti me. Io l'organizzazione gliela ho preparata. Il mio foglio chiamate funziona bene secondo me. Non potrebbe trovare un'altra persona che mi dia una mano ?"
"Perchè ... sa com'è, va bene che quando aspetto un fax e metto un cliente in attesa in effetti ottimizzo i tempi, ma ci sono volte che un cliente sta in attesa solo perchè devo parlare con un altro ... "
Il capo comprese la situazione. E si rese conto che l'organizzazione che il ragazzo aveva dato all'help desk non era per nulla male.
Gli affiancò un collega.
Non fu semplicissimo all'inizio. Spesso capitava che i due si pestassero i piedi. Ma dopo un po' di tempo, con un po' di esercizio e di esperienza, effettivamente la produttività migliorò.
Il capo ci pensò su una volta.
All'inizio il ragazzo era in completa balia delle chiamate. Ne seguiva una alla volta ed era il cliente a comandare.
Non fu una brutta idea la sua. Prese il controllo della situazione, si mise a gestire le telefonate, interrompendole e riprendendole, addirittura dando un ordine di priorità.
Non poteva più succedere che un cliente lo tenesse al telefono per troppo tempo a raccontargli i fatti propri.
Il ragazzo era riuscito in un'impresa ardua.
Aveva parallelizzato il lavoro.
Era da solo. Ma ragionava come fosse in mille.
E, vuoi l'impressione, vuoi una effettiva riduzione di alcuni tempi di attesa, i clienti erano realmente contenti.
E ... cliente contento, cliente paga, soldi per prendere risorse nuove.
Però grazie a quel ragazzo il sistema era già pronto per essere gestito da più di una persona.
Con un po' di aggiustamenti, ma era pronto.
Sì sì, quel ragazzo si merita un bell'aumento di stipendio !
E ovviamente visse felice e contento.
Ora rileggete la storia dando un nome alle cose.
Il ragazzo, il nostro sistema operativo, si è evoluto nel tempo.
All'inizio i clienti (i thread) lo occupavano al 100% e ne avevano quasi il controllo. E se non mettevano giù il telefono (o si dimenticavano la cornetta staccata) mandavano in palla l'help desk. Cooperative multithreading, uhhmmm ?
Fu quando il sistema operativo prese il controllo che le cose cambiarono. Un po' per uno (round-robin), anche in base al tipo di cliente (thread priority), il ragazzo li faceva girare tutti. Aveva il suo foglio e il suo modo di gestirlo (scheduling).
Non andava realmente più veloce (come avrebbe potuto ?). Ma ad esempio mentre era in attesa di un fax (IO bound call) poteva porre in attesa anche il cliente. E riduceva i tempi morti.
Le cose furono realmente più veloci quando ottenne un collega (sistemi multiprocessore ?).
Ma in fondo era tutto dovuto alla sua organizzazione.
Giusto per citare il buon ragionier UgoF, "dicesi" single point of failure "a component in a device, or a point in a network, that, if it were to fail would cause the entire device or network to fail; normally eliminated by adding redundancy" (wikipedia).
Concetto estremamente semplice che si illustra bene con un esempio.
Perchè un server (tipicamente) ha l'alimentatore ridondato ?
Perchè se l'alimentatore principale si guasta quello secondario subentra senza causare interruzioni del servizio.
Un servizio che va down anche per pochi minuti può violare qualche SLA firmato col cliente (al quale è stato garantito un uptime del 99,99% ...).
Un servizio che va down può far perdere un sacco di soldi (che succede se va in tilt il sistema di gestione dei telepass e non si apre più la sbarra ? beh ... che le autostrade sono costrette ad aprire tutte le sbarre senza far pagare il pedaggio).
Credo ci siano pochi dubbi sul fatto che (vedi definizione sopra) i sistemi vadano ridondati per eliminare la eventualità di un fallimento.
Ho sottolineato eventualità perchè non sempre la cosa è percepita come probabilità. Ma questo è un altro discorso.
Il mio pensiero della mattina invece è un altro.
E parte dalla domanda che segue: siamo sicuri che un sistema sia costituito solamente da device, software e via dicendo ?
Dire che un componente di un sistema è la persona è così sbagliato ?
Me lo chiedo perchè un sacco di ambienti che ho visto hanno server ultraridondati, switch ultraridondati, dischi ultraridondati, backup di tutti i tipi ...
Ed è un bene !
Ma mai che nessuno pensi a ridondare le persone !
Giacchè si dà il caso che gli alimentatori si fondano e che le persone si ammalino.
E di sicuro gli alimentatori non si licenziano !
E altrettanto di sicuro (e questo è il punto chiave) se un alimentatore non ridondato si rompe, si subisce un'interruzione del servizio (molto male) ma in seguito lo si sostituisce (almeno il servizio riprende).
E' altrettanto facile sostituire le persone ?
Basta fare un ordine al proprio rivenditore col numero di serie del componente che si è rotto ?